[dns-operations] renesys blog: Identity Theft Hits the Root Name Servers
Kurt Erik Lindqvist
kurtis at kurtis.pp.se
Wed May 21 08:48:40 UTC 2008
On 21 maj 2008, at 09.43, Michael Sinatra wrote:
> Kurt Erik Lindqvist wrote:
>> On 20 maj 2008, at 21.29, David Conrad wrote:
>>> On May 20, 2008, at 12:21 PM, Randy Bush wrote:
>>>>> So why not memorialize a set of "golden" /32s and /128s in a BCP
>>>>> be done with it? No more root hints file. Yay!
>>>> moving the root hints file to pdf will help exactly how? :)/2
>>> It would be fixed in code. Think of it like the fixing in code of
>>> port number for the DNS protocol. The root server addresses,
>>> of their unique requirements due to bootstrapping, would become
>>> (should have been defined as) part of the protocol.
>> If we are fixing something in code, then one /32 anycasted would
>> be enough, no?
I'll first note that irony travels badly in email.
> Not if the nearest server or cluster suffered a failure that
> prevented it from answering queries but didn't take it out of the
> routing table. Everyone in the catchment of that server would be
> affected. If, after bootstrapping, caching resolvers were given
> multiple IP addresses for the root (and those service addresses were
> not part of the same anycast cloud), then such a failure would only
> affect a caching resolver on start-up, but if you stick with the
> single /32 after bootstrapping, then you're really asking for it.
> We should still have 2 or more addresses hardcoded so that such a
> failure could be mitigated by the client doing its own failover to
> another address, and those 2 or more addresses should be part of
> different anycast clouds.
> I am still wondering if there is enough breakage here to warrant the
> level of fix being proposed.
That statement I would agree with.
- kurtis -
More information about the dns-operations