Subject: [homenet] Genart last call review of draft-ietf-homenet-dot-12

From: Dale Worley <[email-masked]>
Date: Thu, 24 Aug 2017 04:20:09 -0700

Reviewer: Dale Worley
Review result: Ready

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<https://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>.

Document:  draft-ietf-homenet-dot-12
Reviewer:  Dale R. Worley
Review Date:  2017-08-24
IETF LC End Date:  2017-08-25
IESG Telechat date:  2017-08-31

Summary:

This draft is ready for publication as a Standards Track RFC.  It has
some nits that should be considered before publication.

4.  Domain Name Reservation Considerations

   3.  Name resolution APIs MUST send queries for such
       names to a recursive DNS server that is configured to be
       authoritative for the 'home.arpa.' zone appropriate to the
       homenet.

If I understand the terminology correctly, this rules out sending the
query to a DNS server that recursively sends the query to a server
that is authoritative for home.arpa.  If that is intended and there
are technical reasons for making this prescription, that's OK, but I
want to check that that is intended, as this rule is stricter than the
similar rule in the second paragraph of item 4, which is qualified
"Unless configured otherwise".

4.  Domain Name Reservation Considerations

There are 5 paragraphs under item 4.  It might be worth giving them
separate numbers, or if they truly form a unified topic, giving them
sub-numbers 4a, 4b, etc.

6.  Security Considerations

   Therefore, the only delegation that will allow
   names under 'home.arpa.' to be resolved is an insecure delegation, as
   in [RFC6303] section 7.

In context what this means is clear, but its literal meaning is
sufficiently incorrect that I think it could be clarified, perhaps to

   Therefore, the only delegation that will allow names under
   'home.arpa.' to be resolved by a validating resolver that is not
   aware of the local meaning is an insecure delegation, as in
   [RFC6303] section 7.

[EOF]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Aug 2017 19:25:44 -0400

> "Unless configured otherwise".

Wow.   The text here is just flat wrong: recursive name servers aren't authoritative.   You can of course combine them, but this text doesn't agree with some other text later in the document.   What the text is supposed to be saying is that the stub resolver has to use the recursive resolver that was provided by the network; if it uses a manually configured resolver, it may get the wrong answer.   I will have to rework this text—thanks so much for calling this to my attention, even though what you noticed isn't exactly what's wrong!   :)

As for the discrepancy itself, the reason for this is that recursive resolvers are supposed to stop home.arpa queries leaking to the root, whereas stub resolvers can (must!) fob that responsibility off on the recursive resolver.   If they are configured to send these queries to, e.g., 8.8.8.8, we just have to hope that google doesn't forward them to the root (as would be consistent with the text in item 4).

> separate numbers, or if they truly form a unified topic, giving them

I've updated the document to separate this out into three lettered subheads.   We can't change the numbering, because that's required by RFC 6761, but I agree that it's clearer if the three separate topics are split out.

>   aware of the local meaning is an insecure delegation, as in

I like the new text, and have copied it into the document.   Thanks!

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 Aug 2017 16:56:13 +1000

In message <[email-masked]>, Ted Lemon writes:
> Wow.   The text here is just flat wrong: recursive name servers aren't
> authoritative.   You can of course combine them, but this text doesn't
> agree with some other text later in the document.   What the text is
> supposed to be saying is that the stub resolver has to use the recursive
> resolver that was provided by the network; if it uses a manually
> configured resolver, it may get the wrong answer.   I will have to rework
> this text—thanks so much for calling this to my attention, even though
> what you noticed isn't exactly what's wrong!   :)
>
> As for the discrepancy itself, the reason for this is that recursive
> resolvers are supposed to stop home.arpa queries leaking to the root,
> whereas stub resolvers can (must!) fob that responsibility off on the
> recursive resolver.   If they are configured to send these queries to,
> e.g., 8.8.8.8, we just have to hope that google doesn't forward them to
> the root (as would be consistent with the text in item 4).

Or the recursive server has learnt that 8.8.8.8 is "special" and
is the equivalent of the root servers in terms of keeping local
traffic local.  Maintaining the list of don't leak too recursive
servers is a "interesting" problem.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 30 Aug 2017 22:34:56 -0400

Ted Lemon <[email-masked]> writes:
> I've updated the document to separate this out into three lettered
> subheads.   We can't change the numbering, because that's required by
> RFC 6761, but I agree that it's clearer if the three separate topics
> are split out.

I hadn't realized from the draft that the items in section 4 are meant
to parallel the items in section 5 of RFC 6761, since the connecting
text is only "(as per [RFC 6761])".  Perhaps it would help to amplify
that to "(per the template in [RFC 6761] section 5)".

Dale

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Aug 2017 22:41:35 -0400

Yup, Adam Roach caught that as well and the document will be updated with
some new text:

	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.