[Yeti DNS Discuss] 答复: One funny naming scheme for root name servers, to test

[Paul Vixie]

Shane Kerr wrote:
> John,
>
> tl;dr Failing a name based on a single IP address failing seems crazy.
>        Crazy enough that we should test it! :)

i think testing this is outside yeti's mission.

more below.

> Some questions:
>
> 1. Is it true that a failure from one address will mark all addresses
>     for a given NS RR as unavailable?

for some initiators, yes.

>
> 2. Does this match the specifications?

the specs do not contraindicate this behaviour.

>
> 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.

failing fast is not brittle. we are rebuilding an airplane in flight, 
while carrying two billion passengers. we must be cautious as to how 
other implementers might reasonably interpret the standards.

>
> 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.

this is still true 99% or more of the time.

>
> 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? ;)

as long as the specs remain compatible with this behaviour, it won't 
matter which implementations behave this way and which do not. that's 
why i say, there's no reason to test this.

>
> 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.

it is nowhere recommended. but had it been recommended, the author would 
have been me, and i would be ready to explain my reasons.

>
> 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).

we disagree.

-- 
P Vixie