[dns-operations] Storm on the DNS

Paul Vixie paul at redbarn.org
Tue Dec 1 19:06:06 UTC 2015

On Tuesday, December 01, 2015 02:52:30 PM Mark Andrews wrote:
> In message <5969BD85-0375-4727-BA8E-9C5AF5496216 at gmail.com>, "Song 
> (Dav
> ey)" writes:
> > Shocked!
> > 
> > One question. In the monitoring page the red block means unanswered
> > packets ratio >70%, right ? I wondering the root server instance in that
> > red region is up or down? if it is still up, the queries can not be
> > routed to other server where the the probes shows green. In that case the
> > merit of anycast dose not work.
> > 
> > Davey
> No.  It isolates the attack.  Taking overwhelmed servers down will
> resulting in cascading failures.

that depends on the type of attack. if the attacker is sending queries to a lot of open RDNS 
servers who happen to not have anything cached about the qname's tld, then the 
recursives will pass those queries on to the root name servers. but that cacheless state 
does not last very long, so this isn't a good nor is it a commonly used attack method, 
unless the root's answer is negative and the open RDNS servers don't do negative caching. 
in that corner case, congestion will result in timeouts which will result in other servers 
being tried in succession. at high enough volumes this could result in something we'd all 
agree to call "cascade failure".

if the attack is directed at the root name server address and that server is anycasted, then 
all the packets will go to the topologically closest (by BGP path selection criteria) anycast 
instance, and only if the attack is so strong that it congests the BGP path from the anycast 
node to its peers and transits, thus causing the effect of a route withdrawal event, will any 
other servers be affected. that would be something we'd all agree to call "cascade failure".

but these attack methods are not what we typically see at the root servers.

P Vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20151201/c6dd576e/attachment-0001.html>

More information about the dns-operations mailing list