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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Ted Lemon writes:
> 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).

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: [phone]                 INTERNET: [e-mail]