Special-Use Domain 'home.arpa.'
draft-ietf-homenet-dot-14

This was originally a DISCUSS, but Ted nicely (and quickly!) addressed my concerns - clearing.


Major issues:

1: I think that this document could benefit from additional review in the DNSOP WG - it got some (https://www.ietf.org/mail-archive/web/dnsop/current/msg19620.html), but that was a: while it was still homenet. b: primarily focused in terms of RFC6761 and not on the whole systems / interaction with existing behaviors, c: largely devolved into "does this do go in the root zone or not"?, d: 9 revisions back.
The document feels vague about much of the details / expected behavior from all of the different players, and I think more focused review from more DNS people would help.


2: What is a "caching resolver"? It is the same as a "recursive resolver"? Or is it a "full-service resolver"? The fact that the answer to RFC6761 Q4 uses both terms makes me think that they are different, but I don't know how.  


3: The document says: "Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3).", but I do not see this being added to the locally served zones registry. This was raised in a previous review (Jon Mitchell, OpsDir (for v03) https://datatracker.ietf.org/doc/review-ietf-homenet-dot-03-opsdir-early-mitchell-2017-03-18/ ), and not implemented. I'm assuming there is a reason, but I haven't found the discussion.


4: The document describes what recursive servers should do with queries for things in home.arpa, but seems to gloss over some detail -- I think that the document would benefit from an overview showing the stub (and / or validating stub), an internal recursive / proxy, an external recursive, the local authoritative for home.arpa, and the .arpa servers, and clearly explain what the expected behavior / role for each one under various scenarios is.


5: Even with the above answered, I remain confused by the "what does a recursive resolver do" bit -- this discusses what a recursive server should do with a DS query for home.arpa - this (obviously) exists to prevent DNSSEC validating stubs from believing that foo.home.arpa is bogus. It also means that it is expected that queries from stubs will sometimes arrive at these recursive resolvers (and they "MUST behave as described in Locally Served Zones" is not simply to prevent pollution). If a query for printer.bedroom.home.arpa does arrive at a recursive, and it is configured as a locally served zone, it will return NXDOMAIN. This (obviously) breaks the lookup for printer.bedroom.home.arpa, but RFC8020 (" NXDOMAIN: There Really Is Nothing Underneath ") also says that this means that nothing exists in bedroom.home.arpa - I think that there needs to be some more text describing the deployment, and which set of queries go where.


6: Section 7.  Delegation of ’home.arpa.’
This delegation MUST NOT include a DS record, and MUST point to one or more black hole servers, for example ’blackhole-1.iana.org.’ and ’blackhole- 2.iana.org.’. 
I fully agree with the DS bit, but the "blackhole" bit feels VERY hand-wavey. Currently a lookup for home.arpa to these returns REFUSED instead of NXDOMAIN:
$ dig +nostat +nocmd home.arpa @blackhole-2.iana.org
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 7826
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;home.arpa.			IN	A

The document just delegates this to ’blackhole-1.iana.org.’ and ’blackhole- 2.iana.org.’ - they're are not authoritative for home.arpa (and nothing in the doc makes them so), and so this does not return NXDOMAIN and instead amplifies the query load. Delegating them to RFC7535 servers *may* help, but I'm not sure.


 7: "In addition to the behavior specified above, recursive resolvers that can be used in a homenet MUST be configurable with a delegation to an authoritative server for that particular homenet’s instance of the domain ’home.arpa.’."  -- Ok, but how does this interact with the requirements on local-zones? I'm *guessing* it overrides it, and if I get a query for printer.livingroom.home.arpa I should "forward" it to the authoritative servers? The document also seems 

 



Minor issues / nits:
1: Section 1.  Introduction.
"A default name with a scope limited to each individual homenet needs to be used." -- I don't understand the "needs to be used" - perhaps "needs to be defined"? Otherwise it sounds like, if the ISP delegates a name, implementations must ignore it. Adding "In these cases," to the beginning of this sentence may clarify. 

2: "No such process is available for requesting a similar delegation in the root" -- I think this would be better as "No such process is *currently* available...."

3: Section 3.  General Guidance
" Names ending with ’.home.arpa.’ reference a locally-served zone," -- the term "locally-served zone" has specific meaning in the DNS context - see https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-05. I'd suggest clarifying that this is not what you mean here.

4: Section 4.  Domain Name Reservation Considerations
It seems that a number of readers didn't get that this next bit is to answer the questions from 6761 - I'd suggest  something like:
   "This section contains answers to the questions posed in Section 5 of RFC6761 and define the behavior of systems involved in domain name
   resolution when resolving queries for names ending with ’.home.arpa.’.

5: " ... zone,  the client may be unable to resolve, or may receive incorrect results for, names in sub domains of ’home.arpa.’." -- "names in sub domains of 'home.arpa.'" are things like foo.bar.home.arpa -- do you just mean "names in 'home.arpa'" ?


6: "a query for a DS record when the DO bit ([RFC4035] section 3.2.1) set MUST return " -- missing "is" after the closing parens? 

7: Section 6 - Security Considerations
"To prevent this from happening, it may be useful for the resolver to identify different homenets on which it has resolved names, but this is out of scope for this document." -- is this a stub resolver? recursive? both?

8: "An alternative would be to install a authenticated denial of existence ([RFC4033] Section 3.2)." -- 1: *an* authenticated and 2: "authenticated denial of existence *record*" (I think. I'm not quite sure on the wording here, and suspect it would need more text, like "DNSSEC records proving authenticated denial of existence.")


-- Original DISCUSS for posterity --
1: Section 4.  Domain Name Reservation Considerations, Subsection 4
If I'm a recursive server and I am configured "with a delegation to an authoritative server for that particular homenet’s instance of the domain ’home.arpa.’." then I have a local zone containing "home.arpa   IN   NS   <local auth-servers for home.arpa>". Unless I'm really confused, this means that I have to make myself authoritative for .arpa, which will a: break everything else in .arpa, and b: will (correctly!) be DNSSEC bogus to validating stubs. (See also #5).
Perhaps you mean that there should be something like (BINDism):
zone "home.arpa" {
	type forward;
	forwarders { 192.0.2.1; 192.0.2.2; };
};
This possibility only came to me after much thought, and I do not think that it could be described as "a delegation". I also do not think that this is a standard / well defined behavior.


2: Section 4.  Domain Name Reservation Considerations, Subsection 4
"Caching resolvers conforming to this specification MUST support DNSSEC queries." This is a MUST, so it's important to understand, but I don't understand what it actually means.  What is a "DNSSEC query"? It is just one with the DO bit? It is one looking for a DS / RRSIG / similar as the qtype? I don't know what this means, so I don't know if it applies to me / what I should do.


3: "Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3).  That is, queries for domains that are subdomains of ’home.arpa.’ MUST NOT be forwarded, with one important exception: ..." 
This says that I must not forward for *domains* that are *subdomains* of home.arpa. The example shows a lookup for NS for 'home.arpa', so presumably this is actually talking about subdomains of home.arpa.  So, I have no idea what to do for lookups within home.arpa itself -- what do I do with query for the A record for printer.home.arpa? It is simply a name within home.arpa; I have no way of knowing if it is a subdomain of home.arpa but it certainly isn't a domain that is a subdomain of home.arpa (because there are only three label, not four).

Section 4 contains a list that it describes as defining "the behavior of [DNS] systems". Item number 7 seems to be something else: I don't know what code or configuration would result from this statement. Maybe move this item to section 3?

I'm having a hard time reconciling the normative requirement in section 4:

       Name resolution APIs and libraries MUST NOT recognize names that
       end in '.home.arpa.' as special and MUST NOT treat them
       differently.

With the explanation in section 6:

   it may be useful for the resolver to identify different
   homenets on which it has resolved names

Doesn't this mitigation in the security section require name resolution libraries to recognize names that end in ".home.arpa." as special so that it can treat them differently?

I am curious if any requirements should be made on Certification Authorities for .home.arpa. Possibly an action for CAB Forum.

"As a result, the use of '.home' is deprecated."
I had to double-checked that .home was NOT in https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml
.home was specified/requested in RFC7788 but never requested to IANA according to RFC6761.
If mentioned in the draft, this info might help others...

I still think this requirement belongs somewhere else, but Ted convinced me that it's in charter, so clearing.

Thanks for queuing up changes from the SecDir review and adding mention of privacy implications into the security considerations section.  I read through the responses on the SecDir list and agree with the statements and changes made.

https://mailarchive.ietf.org/arch/msg/secdir/E7fjRdo94abFW5nqjVBbLspvkww

Thank you folks for putting this together. I know it's important.