> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
