On Aug 30, 2017, at 3:10 PM, Warren Kumari <war...@kumari.net> wrote:
> 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.
Yup, that's bogus. Is this better?
In addition to the behavior specified above, recursive
resolvers that can be used in
a homenet MUST be configurable to forward queries for
'home.arpa.' and subdomains of
'home.arpa.' to an authoritative server for 'home.arpa.'.
This server will provide
authoritative data for 'home.arpa.' within a particular
homenet. The special
handling for DS records for the 'home.arpa.' delegation is
still required.
> 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.
I think this is clarified in the -13 version of the document. Is this review
based on that version, or on -12? Here is the new text:
Recursive resolvers at sites using 'home.arpa.' MUST
transparently support
DNSSEC queries: queries for DNSSEC records and queries with the
DO bit set
(<xref target="RFC4035"/> section 3.2.1). While validation is
not required, it
is strongly encouraged: a caching recursive resolver that does
not validate
answers that can be validated may cache invalid data. This in
turn will prevent
validating stub resolvers from successfully validating answers.
> 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).
Yes, the other text had the same problem. How about "queries for 'home.arpa.'
and subdomains of 'home.arpa.'"?
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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.
I disagree. The document has had substantial review from DNSOP people,
including recently. They are mentioned in the acknowledgments. I think that
I've fixed a couple of the things in -13 that triggered this reaction. In
particular:
> 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.
The term "caching resolver" was carried over from 6761. What is meant here is
"recursive resolver" or "full service resolver," which I think are synonyms.
I updated the text to take out "caching", since "resolver" clearly has an
antecedent of "recursive resolver" and I don't think needs to be qualified in
this way twice in the same paragraph.
> 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.
Because I was being lazy and didn't actually chase down what Dale had said to
see that indeed it was necessary. I've added this to IANA Considerations:
IANA is further requested to create a new subregistry within the
"Locally-Served DNS
Zones" registry <xref target="LSDZ"/>, titled "Transport-Independent
Locally-Served DNS
Zones", with the same format as the other subregistries. IANA is
requested to add an
entry in this new registry for 'home.arpa.' with the description
"Homenet Special-Use
Domain", listing this document as the reference.
> 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.
Could you look at the -13 version of the document, with the changes I provided
for your DISCUSS, and see if you still think this is necessary? The bulk of
what you are requesting is really out of scope for the original intended
purpose of this document. I agree that more detail is needed, but the plan
was to document that in a document that was under less time pressure.
> 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.
All of the relevant DNS protocol agents are expected to behave as normal, with
the stated exceptions. As the document says, stubs are expected to send
queries to whatever recursive resolvers are configured by the network. On a
normal network, the resolver would indeed respond with NXDOMAIN, and this would
be correct. This is the specified, and intended, behavior.
If the local recursive resolver is a homenet resolver, it's expected to divert
queries for home.arpa, except the DS record, to the local server authoritative
for home.arpa. That server will provide answers which will validate, because
the DS record provably doesn't exist.
> 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.
We were specifically asked to trust that IAB/IANA would deal with this, and to
not put explicit operator instructions in the document. I agree that those
two servers need configuration changes; this is up to the IAB and IANA (as
their operator) to make happen.
> 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
I think you left that sentence unfinished, but perhaps the new text I propose
above for this bit helps?
> 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.
How about:
Users and devices within a home network (hereafter "homenet") require
devices and
services to be identified by names that are unique within the
boundaries of the homenet
<xref target="RFC7368"/>. The naming mechanism needs to function
without configuration
from the user. While it may be possible for a name to be delegated by
an ISP, homenets
must also function in the absence of such a delegation. This document
reserves the
name 'home.arpa.' to serve as the default name for this purpose, with
with a scope
limited to each individual homenet.
> 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...."
The IAB has made it pretty clear that they do not intend for such a process to
ever be available, in the sense that they do not wish to open a discussion with
ICANN with the purpose of creating such a process. I can leave the door open
here anyway if you want, but that's why the text reads the way it does. I
think an early version actually said "currently," but I may be mistaken.
> 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.
The text in terminology-bis gives exactly the intended meaning.
> 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.’.
I've proposed the following text in response to Adam's comment:
This section specifies considerations for systems involved in domain
name resolution
when resolving queries for names ending with '.home.arpa.'. Each item
in this section
addresses some aspect of the DNS or the process of resolving domain
names that would be
affected by this special use allocation. Detailed explanations of
these items can be
found in <xref target="RFC6761"/>, Section 5.
> 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'" ?
How about:
A host that is configured to use a resolver other than one that has
been provided by
the local network may be unable to resolve, or may receive
incorrect results for,
subdomains of 'home.arpa.'.
I try to avoid using "in" to mean "subdomain of" because it feels imprecise.
> 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?
Changed "when" to "with".
> 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?
Good point. The resolver on the host. I hesitate to say "stub resolver"
because it might not be a stub resolver. I changed it to "the resolver on the
host."
> 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.")
.arpa doesn't use NSEC3. So there is no record specific to
'home.arpa.'—there's just an NXT record pointing past 'home.arpa.' The text
in -13 says "This would be done simply by not having a delegation from the
'arpa.' zone."
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
