[Yeti DNS Discuss] 答复: One funny naming scheme for root name servers, to test
shane at biigroup.cn
Thu Apr 7 14:26:59 UTC 2016
tl;dr Failing a name based on a single IP address failing seems crazy.
Crazy enough that we should test it! :)
Thanks for adding more background!
On 2016-04-07 10:04:21-0300 (Thursday)
John Bond <yeti at johnbond.org> wrote:
> I'm loathe to comment on a document still in draft however I feel that
> the quoted text misrepresents the current work party thinking. The
> current draft recently went through a mostly editorial revision by a new
> member to the work party. This member added the section quoted by Davey,
> for consideration, without the foreknowledge of previous discussions.
> We have since met and informed the new work party member of these
> discussions, specifically the issues Paul Vixie mentioned; that a
> SERVFAIL or REFUSED from one address would cause the whole delegation to
> be marked as lame. This will of course be reflected in the future edits
> of this document and the final draft.
1. Is it true that a failure from one address will mark all addresses
for a given NS RR as unavailable?
2. Does this match the specifications?
I guess the idea is that some resolvers will track ownernames
(ns.example.com) of name servers instead of IP addresses? Perhaps I am a
lazy programmer but it seems like this would require extra programming
work in order to make your system more brittle.
The assumption that all of the IP addresses listed for a server in an
NS RR are on a single host seems so old-fashioned that it is quaint. I
mean, was this ever true, even 30 years ago? Certainly by 20 years ago
this was no longer true.
IIRC Stephane mentioned that Microsoft's resolvers work this way, and
if so then that is a concern. Maybe BIND 4 also worked this way? ;)
I'm not sure which RFC recommends this behavior, but if someone can
point me to it I'd love to try to get it updated.
Anyway, to me this all implies "research needed!" rather than "OMFG
don't do it!", so a Yeti experiment seems quite reasonable (with a lab
test first as usual).
More information about the discuss