On Wed, Aug 6, 2014 at 11:33 AM, Casey Deccio <ca...@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@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@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@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@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@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@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@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@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@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@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
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Reply via email to