corner cases and interoperability
carl at byington.org
Mon Feb 29 19:42:00 UTC 2016
-----BEGIN PGP SIGNED MESSAGE-----
I am working on a simple script to test various scenarios, including key
and algorithm rollovers, against (bind, unbound, ultradns, verisign,
google) resolvers using 510sg.com as a testing domain. A very simple
scenario is a bad ksk key rollover, where we:
1) generate ksk,zsk and wait until everyone agrees we have a valid
dnssec zone. Get the DS and DNSKEY records cached into the resolver with
a reasonably long ttl.
2) generate new keys, throw away the old keys, upload the new DS records
to the parent.
3) ask the resolver for test30m.510sg.com, which has a short 1800 second
ttl, and should not be in the cache.
I would expect that to fail validation, since the old DS/DNSKEY records
are cached, but the new RRSIG for test30m.510sg.com has a signature from
the new keys. That does fail using bind, unbound, ultradns, and
verisign. However, google (22.214.171.124) consistently says that it passes
After claiming that test30m.510sg.com passes validation, with the new
rrsig, google (126.96.36.199) still returns the old DS and DNSKEY records. My
guess is that this inconsistency is caused by load balancing, where the
DS and DNSKEY queries are hitting a different backend server than the
one that is used for the test30m A query.
Would such inconsistencies cause problems for a bind installation that
is doing dnssec validation but forwarding to 188.8.131.52 ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the bind-users