Re: [homenet] WGLC on draft-ietf-homenet-dot-05

[Suzanne Woolf <[e-mail]>]

Ray,


> On Apr 27, 2017, at 9:15 AM, Ray Bellis <[e-mail]> wrote:
> 
> This email starts a two week WGLC on draft-ietf-homenet-dot-05.
> 
> Ted has updated this following Terry's ruling on ".homenet" to request
> ".home.arpa" instead.  He has also incorporated other comments that came
> in after the last WGLC.
> 


I think it’s time for this document to be finished, and this version is close to ready. I support advancing it with the changes I’m suggesting; the most substantive are:

* some cleanup of lingering references to .home;
* clarification of the authority for .home.arpa (citation of RFC 3172);
* clarification of the rationale for an unsigned delegation in the global DNS for a domain that’s not supposed to be resolvable in the global context (Introduction and/or Security Considerations)— this will matter to DNS admins;
* slight reworking of the rationale in the Introduction (dropping the speculation on legal concerns and adding a couple of technical details)

It’s also hard for me at this point to see the need for draft-ietf-homenet-redact. Since this document is standards track and updates RFC 7788, I’m not sure what’s actually added to the protocol or to understanding of it by having a second update to it. The necessary content of draft-ietf-homenet-redact seems to be mostly to reinforce that “.home” as the default domain for homenet names was specified only in error and that results from using it are neither interoperable nor predictable. This could be covered in a couple of sentences in homenet-dot.

I’m including my full comments below— the changes I’m suggesting look larger than they are because I’ve tried to include context for each.


Suzanne

===============
Sec. 1, Introduction

1. Existing text: "The '.home.arpa' domain replaces '.home' as the default domain used by the Home Networking Control Protocol (HNCP)"

There's an accepted erratum on this, since the "reservation" of .home occurred without reference to the relevant registry, so it would be helpful for anyone trying to understand why this document exists to point that out.

Suggested new text: "The '.home.arpa' domain corrects an error in  RFC7788, replacing  '.home' as the default domain used by the Home Networking Control Protocol (HNCP)."

2. "Also, ICANN has about a dozen applicants for the '.home' top-level domain name, which creates a significant risk of litigation if it were claimed by the IETF outside of that process."

I don't think it's either necessary or useful to speculate in an IETF standards-track technical document about either ICANN policy or associated litigation risk. The technical reason (the risk of name collision within the homenet or ISP environment) and the standards process reason (the fact that RFC 7788 entirely sidestepped IETF discussion of .home as a special use name for this purpose) are probably adequate justification here.

In addition, this text doesn't touch at all on the fact a delegation in the global DNS is considered necessary for the default zone in order to properly support DNSSEC, or the rationale for it, or the potential difficulty of obtaining it in the root zone.

Finally, it's unclear why a separate document is needed to support redaction of ".home" from RFC 7788, when this document replaces it with ".home.arpa." anyway. This document is standards track and already updates RFC 7788.

The sentence about existing applicants for .home could be simply removed. Brief additional explanation about why a name in .arpa is preferable to one in the root might also be helpful.

Old text: "The '.home.arpa' domain replaces '.home' which was specified in
   [RFC7788] as the default domain-name for home networks. '.home' had
   been selected as the most user-friendly option.  However, there are
   existing uses of '.home' that may be in conflict with this use:
   evidence indicates that '.home' queries frequently leak out and reach
   the root name servers [ICANN1] [ICANN2].  Also, ICANN has about a
   dozen applicants for the '.home' top-level domain name, which creates
   a significant risk of litigation if it were claimed by the IETF
   outside of that process.  As a result, the use of '.home' has been
   deprecated; this document updates [RFC7788] to replace '.home' with
   '.home.arpa', while another document, [I-D.ietf-homenet-redact]
   deprecates the use of the '.home' TLD.

New text:   "The '.home.arpa' domain replaces '.home' which was specified in
   [RFC7788] as the default domain-name for home networks. Initially, '.home' had
   been selected as the most user-friendly option.  However, there are
   existing uses of '.home' that may be in conflict with this use:
   evidence indicates that '.home' queries frequently leak out and reach
   the root name servers [ICANN1] [ICANN2].  In addtion, it's desirable that there
   should be a delegation for the homenet default domain name in the global DNS,
   for compatibility with DNSSEC. There is an existing process, under control of
   the IETF and the IAB, for creating such a delegation under .arpa [RFC3172].
   However, there is no such process for creating a name under the root zone, which
   is not administered by the IETF, so creating such a process would involve
   unknown costs in time and effort.  As a result, the use of '.home' has been
   deprecated.
   
   This document updates [RFC7788] to replace '.home' with '.home.arpa', while
   another document, [I-D.ietf-homenet-redact] deprecates the use of
   the '.home' TLD."

3. Existing text: "....DNS queries for names whose rightmost non-terminal label is 'homenet'."

Suggested new text: "....DNS queries for names whose rightmost non-terminal labels are '.home.arpa'."


Sec. 2, General Guidance

4. Existing text: "The domain name '.home.arpa.' is to be used for naming within a home network.” I looked for a handy reference for describing what's a "home network”; the closest I could find was Sec. 3.7.3 of RFC 7368.

5. Existing text: "DNS queries for names ending with '.home.arpa.' are resolved using local resolvers on the homenet." It might be helpful to also note that they're not intended to be resolvable from outside the homenet (relevant for some new text I think the "Security Considerations" will need, see below).


Sec. 3, Domain Name Reservation Considerations

6. Existing text: "...when serving queries for names ending with '.home.arpa.'"

This sounds odd, as the resolution process isn't usually called "serving queries"

Suggested new text: "....when responding to queries for names ending with 'home.arpa'." 

7. Existing text "Applications SHOULD treat domain names ending with '.home.arpa.' just like any other FQDN, and MUST NOT make any assumption on the level of additional security implied by its presence."

Is the suggestion that the user or system might automatically place a higher level of trust in "home.arpa" names than other FQDNs, which might not be appropriate? If so, a sentence clarifying that would be helpful.

8. As a related observation, it would be appropriate to suggest local "home.arpa" zones should be signed and resolvers should validate them, particularly given the caution above about assuming too much about security within the homenet. As the document stands, the reference to DNSSEC as the reason for requiring a delegation in the global DNS for .home.arpa stands pretty much alone and unmotivated. (This may belong under “Security Considerations.”)

9. Existing text: "Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Locally Served Zones ([RFC6303] Section 3)."

This text is mildly confusing, because I think it says "resolvers and proxies must do this, unless they do something different." I'm guessing it's supposed to mean "This is the expected behavior unless something more useful is configured," but I'm not sure exactly how to say that.

10. Existing text: "Only a DNS server that is authoritative for the '.arpa' zone or is configured to be authoritative for '.home.arpa' or a subdomain of '.home.arpa' will ever answer a query about '.home.arpa.'"

It might be wise to note that servers for .arpa will not actually know about the local instance of .home.arpa, and a query to those servers for information about the local .home.arpa zone will not produce useful results. Thus, resolvers inside the homenet should avoid queries to .arpa for names in home.arpa. (Resolvers outside the homenet will most likely find the .arpa servers, and terminate the resolution process there, which is also as it should be.)

This isn't a special failing of .arpa or of being in an SLD; if the name were ".homenet" instead, the same problem would occur: the parent (whether it's the root or a TLD) is not in a position to know anything about the local instance of an ambiguously-named child zone from a name in the root. This is why the recursive resolver that the stub asks for resolution services should be configured to be authoritative for the home.arpa zone, including DNSSEC trust anchors.

11. Existing text: "'home.arpa' is a subdomain of the 'arpa' top-level domain, which is entirely operated by the Internet Architecture Board."

Actually, no; it's operated by IANA, under the administrative authority of the IAB, which in turn is responsible under the rules established in RFC 3172. This doesn't change the relevant policy of course, but allows for a reference on why there's no need to worry about registrars.

Suggested new text: "'home.arpa' is a subdomain of the 'arpa' top-level domain, which is operated under the authority of the Internet Architecture Board according to the rules established in RFC 3172. There are no other registrars for .arpa."


Sec. 4, Updates to Home Networking Control Protocol

12. Existing text: "Names for which the rightmost non-terminal label is 'homenet' are resolved using the DNS protocol [RFC1035]."

Suggested new text: "Names for which the rightmost two labels are 'home.arpa' are resolved using the DNS protocol [RFC1035]."


Sec. 5, Security Considerations

13. Existing text "....query ending with '.home.arpa.' is expected...." is ambiguous. Suggested new text: "....query for an FQDN in the domain '.home.arpa.' is expected...."

14. Existing text describing why the delegation needs to exist and not be signed is not clear. This is a somewhat arcane topic, but DNS administrators who have been told repeatedly for some years now that they should use DNSSEC whenever possible will be puzzled by an apparent directive that home.arpa not be signed.

I suggest the document should have an additional paragraph describing the resolution process in which it's helpful to have the global delegation exist and be unsigned.

The text that's there now ("The reason that this delegation must not be signed is that not signing the delegation breaks the DNSSEC chain of trust, which prevents a validating stub resolver from rejecting names published under 'home.arpa' on a homenet name server.") isn't adequate because it doesn't explain how this condition could possibly arise: if the stub resolver is asking the global DNS for names published under .arpa, it's because it hasn't asked a resolver that has locally configured .home.arpa. It can't reject names it has no way to get in the first place.

If a stub resolver asks a local, recursive resolver for home.arpa names and the resolver is configured to serve .home.arpa as a local zone, authoritative data for the zone (signed or not) is available to the stub. If the stub resolver asks a resolver that doesn't have .home.arpa as a locally served zone, it will ask the root, but it's not clear what happens to allow the stub to find locally relevant information in the results of that attempt to resolve and validate the name in the global context of the DNS. So it's not clear what sequence of resolution steps results in a useful answer that's an unsigned NXDOMAIN.


Sec. 9 "References"

15. RFC 3172 should be added as a reference to support the request for a delegation in .arpa for .home.arpa.