Re: [Gen-art] Genart last call review of draft-ietf-homenet-dot-12

[Ted Lemon <[e-mail]>]

El Aug 24, 2017, a les 7:20 AM, Dale Worley <[e-mail]> va escriure:
> 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".

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

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

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.

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

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