[dns-operations] unbound-bind chain causing validation failures on synthesized records

Mark Andrews marka at isc.org
Tue Jul 10 00:21:59 UTC 2012


In message <alpine.LFD.2.02.1207091944500.418 at bofh.nohats.ca>, 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: marka at isc.org



More information about the dns-operations mailing list