[Dnssec-trigger] dnssec-trigger let opendns sneak in and cause failure

Paul Wouters paul at nohats.ca
Mon Aug 27 22:30:59 UTC 2012


I just had a failure that looked like:

Aug 27 18:17:13 thinkpad NetworkManager[972]: <info> (wlan0): supplicant interface state: disconnected -> scanning
Aug 27 18:17:13 thinkpad NetworkManager[972]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Aug 27 18:17:14 thinkpad NetworkManager[972]: <info> (wlan0): supplicant interface state: authenticating -> associating
Aug 27 18:17:14 thinkpad NetworkManager[972]: <info> (wlan0): supplicant interface state: associating -> completed
Aug 27 18:19:30 thinkpad unbound: [2169:0] info: validation failure <fedoraproject.org.dlv.isc.org. DLV IN>: no NSEC3 records from 208.67.222.222 for DS fedoraproject.org.dlv.isc.org. while building chain of trust
Aug 27 18:19:53 thinkpad unbound: [2169:1] info: validation failure <fedoraproject.org.dlv.isc.org. DLV IN>: key for validation fedoraproject.org.dlv.isc.org. is marked as invalid because of a previous validation failure <fedoraproject.org.dlv.isc.org. DLV IN>: no NSEC3 records from 208.67.222.222 for DS fedoraproject.org.dlv.isc.org.  while building chain of trust
Aug 27 18:21:12 thinkpad unbound: [2169:0] info: validation failure <fedoraproject.org.dlv.isc.org. DLV IN>: no NSEC3 records from 208.67.222.222 for DS fedoraproject.org.dlv.isc.org. while building chain of trust
Aug 27 18:21:14 thinkpad NetworkManager[972]: <info> (wlan0): supplicant interface state: completed -> authenticating
Aug 27 18:21:14 thinkpad NetworkManager[972]: <info> (wlan0): supplicant interface state: authenticating -> associating
Aug 27 18:21:14 thinkpad NetworkManager[972]: <info> (wlan0): supplicant interface state: associating -> completed

It looks like a race between the network reconnect and the trigger
probe. Apparently port 53 is blocked too, so it falls back to dns over
tcp on the fedoraproject servers.

I guess dnssec-trigger really needs to configure unbound much more
aggresively for retries and negative-caching. And perhaps try and
keep the TCP session to the known good resolver open?

Paul



More information about the dnssec-trigger mailing list