Re: [DNSOP] Fw: New Version Notification fordraft-bellis-dns-recursive-discovery-00

[[e-mail]]

> I have read the draft, found no problems other than the missing 
> security considerations ( I don't see any particular security
> considerations ), and fully support it.

Thanks - and that's why the Security Considerations is "TODO" - we're not 
sure what they are yet.  The only significant risk we can think of is 
someone spoofing that initial seeding query, and thereafter intercepting 
all DNS requests. 

> Did you consider a "referral" model using NS records?
> 
> LOCAL.ARPA.    9000    NS    A.LOCAL.ARPA.
> LOCAL.ARPA.    9000    NS    B.LOCAL.ARPA.
> 
> A.LOCAL.ARPA.    9000    A    1.2.3.4
> B.LOCAL.ARPA.    9000    A    2.3.4.5
> 
> I think this may be cleaner, it allows multi-homed servers to be 
> properly distinguished ( you shouldn't try an alternate address
> until other servers have been tried ), and seems closer to the
> normal DNS representation of name servers.

Resolvers require a list of A (or AAAA) records to send queries to.  Hence 
we use the RR type which represents just such a list.

> A simplistic client can still just save all the A records, and 
> ignore the names.

That would be harder to implement than simply asking for A records in the 
first place.

> This may be significant if the glue types are extended in future
> to supply other link-local parameters, for example the DNS transport
> protocols supported...

At this point any other transports are (with all due respect) entirely 
hypothetical so they are not considered here.
 
> I also note that using LOCALHOST, or a sub-domain of LOCALHOST,
> would avoid non-local queries being sent by servers that are not
> aware of LOCAL.ARPA

See RFC 2606:

      The ".localhost" TLD has traditionally been statically defined in
      host DNS implementations as having an A record pointing to the
      loop back IP address and is reserved for such use.  Any other use
      would conflict with widely deployed code which assumes this use.

Ray