Subject: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT)

From: Warren Kumari <[email-masked]>
Date: Wed, 30 Aug 2017 12:10:49 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-homenet-dot-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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).

----------------------------------------------------------------------
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.

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.")

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Aug 2017 15:54:44 -0400

> 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.

> don't know what this means, so I don't know if it applies to me / what I should

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.

> (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.'"?

> 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.

> ), and not implemented. I'm assuming there is a reason, but I haven't found the

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.

> 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.

> 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.

> 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.

> servers? The document also seems

I think you left that sentence unfinished, but perhaps the new text I propose above for this bit helps?

> 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.

> root" -- I think this would be better as "No such process is *currently*

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.

> clarifying that this is not what you mean here.

The text in terminology-bis gives exactly the intended meaning.

>   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.

> 'home.arpa.'" are things like foo.bar.home.arpa -- do you just mean "names in

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.

> return " -- missing "is" after the closing parens?

Changed "when" to "with".

> 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."

> suspect it would need more text, like "DNSSEC records proving authenticated

.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."

---

From: Warren Kumari <[email-masked]>
Date: Wed, 30 Aug 2017 17:08:40 -0400

Ok, I'm surprised - I spent much time with this review, and felt bad
submitting a number of DISCUSS points close to the telechat. I thought
that addressing them might end up in this going back to the WG -- but,
your (really quick) responses more than adequately addresses my
DISCUSS (and major concerns).

Thank you, I'm clearing my discuss position -- more inline, but I'm a
happy camper.

>                 handling for DS records for the 'home.arpa.' delegation is still required.

Much better, thanks.

>                 validating stub resolvers from successfully validating answers.

WFM.

> Yes, the other text had the same problem.   How about "queries for 'home.arpa.' and subdomains of 'home.arpa.'"?

WFM. Thanks.

> 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 "cachin…

Also WFM.

> Because I was being lazy and didn't actually chase down what Dale had said to see that indeed it was necessary.

Hey, at least y'er honest :-)

>  I've added this to IANA Considerations:
>

Again, WFM.

> 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…

Will do. These are only comments, so not blocking anyway -- if the
plan is to sometime flesh out in another document, also, WFM.

> 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; t…

Okey dokey. Didn't know the "specifically asked" bit, I'll trust
$whoever_asked has a reason.

> I think you left that sentence unfinished, but perhaps the new text I propose above for this bit helps?

Hey, it is! (I copied and pasted from an earlier draft of comments...)
-- your text above solves much of these issues.

>         limited to each individual homenet.

Poifect!

> 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 suc…

Ok. I predict that there will be a process at some point, but I'll
just reserve the right to say "I told you so!!!!" then :-)

> The text in terminology-bis gives exactly the intended meaning.

I disagree! <Warren goes off in a huff and reads the definition>
<Warren blushes and sidles back>
Ok. You are 100% correct. I'd always viewed "locally-served zone" as
"those things in RFC6303 / which recursives serve an empty zone for",
but I new see the definition.
To save others from equal embarrassment is may be worth pointing at
this definition (or not).

>         found in <xref target="RFC6761"/>, Section 5.

WFM.

> I try to avoid using "in" to mean "subdomain of" because it feels imprecise.

Ok.

> Changed "when" to "with".

Oh! That's better.

> 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."

WFM.

> .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 del…

WFM.

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf