<div dir="ltr">On Wed, Aug 6, 2014 at 11:10 AM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Hi,<br>
<br>
My <a href="http://nohats.ca" target="_blank">nohats.ca</a> domain has been under a couple of weeks long ANY attack. I<br>
assume spoofed IPs querying open resolvers that in have their upstream<br>
DNS send me queries.<br>
<br>
The vast majority of queries are coming from Google's many IP addresses.<br>
While I understand it must be an impressive ANYCAST network, I am still<br>
surprised to see millions of queries coming for data that has a TTL=1d<br>
It is as if Google is hardly caching anything.....<br>
<br>
The top 30 queries in the last two weeks, based on logging at most 1q/s:<br>
<br>
It seems that the nsd ratelimits to send TC=1 isn't working well either<br>
to reduce the incoming amount of UDP queries.<br>
<br>
Why does google dns seems so inefficient at caching?<br></blockquote><div><br></div><div>Google's implementation seems to recursively query for and cache ANY based on the entire set of records for the same name, rather than on a per-record basis.  <a href="http://nohats.ca">nohats.ca</a> includes an NSEC3PARAM record with TTL 0.  This results in zero caching of ANY queries.<br>
<br>For example, contrast the following (looking at the TTLs in the answer):<br><br>casey@rome:~$ dig +dnssec @<a href="http://8.8.8.8">8.8.8.8</a> <a href="http://sandia.gov">sandia.gov</a> soa | grep SOA | awk '{ print $1,$2,$3,$4 }'<br>
;<a href="http://sandia.gov">sandia.gov</a>. IN SOA <br><a href="http://sandia.gov">sandia.gov</a>. 20502 IN SOA<br><a href="http://sandia.gov">sandia.gov</a>. 20502 IN RRSIG<br>casey@rome:~$ dig +dnssec @<a href="http://8.8.8.8">8.8.8.8</a> <a href="http://sandia.gov">sandia.gov</a> soa | grep SOA | awk '{ print $1,$2,$3,$4 }'<br>
;<a href="http://sandia.gov">sandia.gov</a>. IN SOA <br><a href="http://sandia.gov">sandia.gov</a>. 20497 IN SOA<br><a href="http://sandia.gov">sandia.gov</a>. 20497 IN RRSIG<br><br></div><div>with this:<br></div><div><br>
casey@rome:~$ dig +dnssec @<a href="http://8.8.8.8">8.8.8.8</a> <a href="http://sandia.gov">sandia.gov</a> any | grep NSEC3PARAM\\\|SOA | awk '{ print $1,$2,$3,$4 }'<br><a href="http://sandia.gov">sandia.gov</a>. 21599 IN SOA<br>
<a href="http://sandia.gov">sandia.gov</a>. 21599 IN RRSIG<br><a href="http://sandia.gov">sandia.gov</a>. 0 IN RRSIG<br><a href="http://sandia.gov">sandia.gov</a>. 0 IN NSEC3PARAM<br>casey@rome:~$ dig +dnssec @<a href="http://8.8.8.8">8.8.8.8</a> <a href="http://sandia.gov">sandia.gov</a> any | grep NSEC3PARAM\\\|SOA | awk '{ print $1,$2,$3,$4 }'<br>
<a href="http://sandia.gov">sandia.gov</a>. 21599 IN SOA<br><a href="http://sandia.gov">sandia.gov</a>. 21599 IN RRSIG<br><a href="http://sandia.gov">sandia.gov</a>. 0 IN RRSIG<br><a href="http://sandia.gov">sandia.gov</a>. 0 IN NSEC3PARAM<br>
<br>This is a bad side effect of (at least) BIND's NSEC3 signing which 
doesn't (or at least didn't last time I checked) allow a custom, longer 
TTL for NSEC3PARAM.  But it's the combination of Google's ANY query/cache behaviaor and the zero-TTL NSEC3PARAM that cause the problem.<br><br>Cheers,<br>Casey<br></div></div></div></div>