[dns-operations] Pending Removal of 3 Negative Trust Anchors @ Comcast
marka at isc.org
Mon May 21 23:49:29 UTC 2012
In message <Prayer.22.214.171.1245212309370.30706 at hermes-2.csi.cam.ac.uk>, Chris Thompson writes:
> On May 21 2012, Livingood, Jason wrote:
> >Upcoming Removal of Three Negative Trust Anchors
> >Monday, May 21, 2012
> >Comcast plans to remove three separate Negative Trust Anchors
> > * fbo.gov
> >- Negative Trust Anchor added 4/23/12
> >- Issue appears due to expired keys in the domain
> >- DNSViz report at http://dnsviz.net/d/fbo.gov/T7YMCQ/dnssec/
> One of the three authoritative nameservers (ns04.symplicity.com) has
> expired signatures (not *keys*, damnit!), the other two are currently
> fine, although all three claim the same SOA serial for the zone.
> A validating recursive BIND doesn't seem to have any trouble with this.
> Some of the DNSSEC checking sites seem not to try all the nameservers,
> at least by default.
Checking sites have different criteria to resolvers. Checking sites
need to determine if the site is resolvable by all resolution paths.
Resolvers only care if a single path work. Checking sites need to
catch errors before resolvers can't work around them if possible.
For those of you in the IETF these sorts of issues are exactly why
section 5.9 of ietf-dnsext-dnssec-bis-updates-18 needs to be changed.
Sending CD=1 queries to a recursive resolver makes the resolution
process much more brittle than it should to be. CD=1 results in a
single resolution path not all resolution paths being tried by the
recursive server and if you get a bad one there isn't a way to
influence the recursive server to try a different one.
ietf-dnsext-dnssec-bis-updates-18 is in IETF last call. I've
been arguing for months now that it needs to be fixed.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the dns-operations