[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