Ray,
> On Apr 27, 2017, at 9:15 AM, Ray Bellis <r...@bellis.me.uk> 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.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
