[dns-operations] Google DNS used as amplification - aren't they caching?

[Casey Deccio]

On Wed, Aug 6, 2014 at 11:10 AM, Paul Wouters <paul at nohats.ca> wrote:

>
> Hi,
>
> My nohats.ca domain has been under a couple of weeks long ANY attack. I
> assume spoofed IPs querying open resolvers that in have their upstream
> DNS send me queries.
>
> The vast majority of queries are coming from Google's many IP addresses.
> While I understand it must be an impressive ANYCAST network, I am still
> surprised to see millions of queries coming for data that has a TTL=1d
> It is as if Google is hardly caching anything.....
>
> The top 30 queries in the last two weeks, based on logging at most 1q/s:
>
> It seems that the nsd ratelimits to send TC=1 isn't working well either
> to reduce the incoming amount of UDP queries.
>
> Why does google dns seems so inefficient at caching?
>

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.  nohats.ca includes an NSEC3PARAM record with TTL 0.  This results
in zero caching of ANY queries.

For example, contrast the following (looking at the TTLs in the answer):

casey at rome:~$ dig +dnssec @8.8.8.8 sandia.gov soa | grep SOA | awk '{ print
$1,$2,$3,$4 }'
;sandia.gov. IN SOA
sandia.gov. 20502 IN SOA
sandia.gov. 20502 IN RRSIG
casey at rome:~$ dig +dnssec @8.8.8.8 sandia.gov soa | grep SOA | awk '{ print
$1,$2,$3,$4 }'
;sandia.gov. IN SOA
sandia.gov. 20497 IN SOA
sandia.gov. 20497 IN RRSIG

with this:

casey at rome:~$ dig +dnssec @8.8.8.8 sandia.gov any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
sandia.gov. 21599 IN SOA
sandia.gov. 21599 IN RRSIG
sandia.gov. 0 IN RRSIG
sandia.gov. 0 IN NSEC3PARAM
casey at rome:~$ dig +dnssec @8.8.8.8 sandia.gov any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
sandia.gov. 21599 IN SOA
sandia.gov. 21599 IN RRSIG
sandia.gov. 0 IN RRSIG
sandia.gov. 0 IN NSEC3PARAM

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.

Cheers,
Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140806/9d483a3e/attachment.html>