[dns-operations] Please contribute data to OARC!

[bert hubert]

On Tue, Feb 02, 2010 at 02:50:39PM +0100, Phil Regnauld wrote:
> 	The possibility that non-availability of an anycast server "somewhere"
> 	could trigger such a backlash of repeated queries, and take down a
> 	recursive instance is disturbing, and not something I've heard of before.

Well.. Of course a resolver should not 'go down' under any circumstances.

With better programming, the PowerDNS Recursor would not have crashed in
those three places.  I note that it kept on running for all other users as
far as we know.

To judge the scale, it is estimated that around 100 million residential
connections are served by the PowerDNS Recursor (extrapolating somewhat
beyond the known deployments - this being open source, we often have no clue
who is running our software).

And of all these places, only three reported a problem.

In addition, even if a server does not go down, from observed packet volumes,
it is doubtful that many end users would have received decent service during
the spike.

> 	It would be great to be able to confirm this, and we could all learn
> 	from the results here, without having to know anything about the
> 	specifics of the submitted data.

Stephane posted a link to a highly similar development noted by China
Telecom.

It appears there exists an interaction between authoritative, resolving and
typical end-user stub resolvers, in case of a sudden failure of all
authoritative servers of low TTL domain names.

Because this is a three-body problem, this makes for interesting analysis.

> > So please consider sharing your interesting DNS operational data with
> > OARC!

Part of the analysis may be outside the scope of many server-oriented
analyses. For example, how do popular stub resolvers (as found in Windows
XP, Vista, Windows 7, but also and more specifically within IE7, IE8,
Firefox, Chrome) react to SERVFAILs or timeouts?

And perhaps just as important, do any of the SOHO DNS procies do something
interesting?

Also, I've never gotten a clear picture on what popular stubs think of the
two or three IP addresses they are given as resolvers. Is the first one more
important? It sure appears to be the case.

Finally, given typical access provider investment patterns, a 2-fold
increase in DNS traffic will often suffice to snuff out decent DNS resolver
performance for all users.

This makes knowing all about client behaviour on receiving timeouts or
SERVFAILs of the utmost importance.

	Bert