In message <[email protected]>, Paul Wouters wri tes: > On Tue, 10 Jul 2012, Mark Andrews wrote: > > > BIND bug, the "NOQNAME" NSEC/NSEC3 proof extraction is a side effect > > of validation. > > Do you have a tracking/reference number for me? > > > That said if you are talking through a recursive server that server > > should be validating as there are situations that are not recoverable > > without it. > > So are you saying that even if the bug is fixed, bind does not support: > > options { > dnssec-enable yes; > dnssec-validation no; > [...] > }
I'm saying the DNSSEC protocol does not support recovery from operational errors / attacks unless the intermediate server has a super set of the trust anchors used by the clients. The clients have no control over which upstream server the recursive server talks to and without validation being enabled it will cache and pass bad answers through to the client. These will then be returned until the cache entry clears due to TTL expiry. Addionally you see a similar error condition if the client always sets CD=1 even when the recursive server is validating. The client has no control over which upstream server the recusive server talks to so it can't force the recursive server to move on from bad authoritative servers. This is why I objected to the always set CD=1 in Section 5.9 of draft-ietf-dnsext-dnssec-bis-updates. Making CD=0 queries forces the recursive server to try multiple authoritative servers until it gets a answer which validates or it exhausts the available authoritative servers and retries. > If so, should those options not be merged into one option? Or should > named-checkconf return a failure for such a configuration? > > Does anyone know how prevalent these configurations are? > > I'm CC:ing the dnssec-trigger list, as it might need to come up with a > new probe to detect this. > > Paul -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
