[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNSOP] Fw: New Version Notification fordraft-bellis-dns-recursive-discovery-00
> 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