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

[Casey Deccio]

On Wed, Aug 6, 2014 at 11:33 AM, Casey Deccio <casey at deccio.net> wrote:

> 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
>
>
I neglected to provide examples from other resolver implementations.
Here's BIND:

casey at rome:~$ dig +dnssec @localhost nohats.ca any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
nohats.ca. 0 IN RRSIG
nohats.ca. 0 IN NSEC3PARAM
nohats.ca. 3600 IN RRSIG
nohats.ca. 3600 IN SOA
casey at rome:~$ dig +dnssec @localhost nohats.ca any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
nohats.ca. 3598 IN RRSIG
nohats.ca. 3598 IN SOA
casey at rome:~$ dig +dnssec @localhost nohats.ca any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
nohats.ca. 3597 IN RRSIG
nohats.ca. 3597 IN SOA

Note that the cache started empty, and because it was empty it was
populated with all records having name nohats.ca after the first ANY
query.  BIND responded to subsequent query with whatever was still in
cache.  The zero-TTL items had already expired, and BIND did not re-fetch
them.

unbound has yet a third behavior.  It seems to cache on a per-ANY basis but
maintain TTL on a per-record basis:

casey at rome:~$ dig +dnssec @localhost nohats.ca any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
nohats.ca. 3600 IN SOA
nohats.ca. 3600 IN RRSIG
nohats.ca. 0 IN NSEC3PARAM
nohats.ca. 0 IN RRSIG
casey at rome:~$ dig +dnssec @localhost nohats.ca any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
nohats.ca. 3598 IN SOA
nohats.ca. 3598 IN RRSIG
nohats.ca. 0 IN NSEC3PARAM
nohats.ca. 0 IN RRSIG
casey at rome:~$ dig +dnssec @localhost nohats.ca any | grep NSEC3PARAM\\\|SOA
| awk '{ print $1,$2,$3,$4 }'
nohats.ca. 3596 IN SOA
nohats.ca. 3596 IN RRSIG
nohats.ca. 0 IN NSEC3PARAM
nohats.ca. 0 IN RRSIG

It's inconclusive from this quick test whether the existing records are
being updated or not from the results of the ANY query (it appears that
they are not, but I would need to check content), but at least the TTLs are
not affected.

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