From dk at hostmaster.ua  Thu Aug  2 11:23:23 2012
From: dk at hostmaster.ua (Dmitry Kohmanyuk)
Date: Thu, 2 Aug 2012 14:23:23 +0300
Subject: [Dnssec-trigger] DNSSEC trigger on OS X Mountain Lion seems to
	work ok
In-Reply-To: <20120725160118.GC1432@macbook.bluepipe.net>
References: <20120725160118.GC1432@macbook.bluepipe.net>
Message-ID: <B447B333-EDB3-4C86-9C51-CC49CBA93C99@hostmaster.ua>


On Jul 25, 2012, at 7:01 PM, Phil Regnauld <regnauld at nsrc.org> wrote:

> Quick testing shows that it works fine - have tried both in
> hotspot signon, and on a "normal" network. Everything seems
> to function (for those hesitating to upgrade).
> 

well, how this would work for those who have "allow applications from Mac Store and identified developers" set? (default on OS X ML)
dialog suggests control-clicking application icon to give it approval - but there is no icon for dnssec-trigger binaries? 


From paul at nohats.ca  Mon Aug 27 22:30:59 2012
From: paul at nohats.ca (Paul Wouters)
Date: Mon, 27 Aug 2012 18:30:59 -0400 (EDT)
Subject: [Dnssec-trigger] dnssec-trigger let opendns sneak in and cause
	failure
In-Reply-To: <55DDA365-3D1F-4B60-85EA-6C02A096BF0E@NLnetLabs.nl>
References: <20120725160118.GC1432@macbook.bluepipe.net>
 <55DDA365-3D1F-4B60-85EA-6C02A096BF0E@NLnetLabs.nl>
Message-ID: <alpine.LFD.2.02.1208271827110.9526@bofh.nohats.ca>


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


From ogud at ogud.com  Tue Aug 28 00:13:31 2012
From: ogud at ogud.com (Olafur Gudmundsson)
Date: Mon, 27 Aug 2012 20:13:31 -0400
Subject: [Dnssec-trigger] dnssec-trigger let opendns sneak in and cause
 failure
In-Reply-To: <alpine.LFD.2.02.1208271827110.9526@bofh.nohats.ca>
References: <20120725160118.GC1432@macbook.bluepipe.net>
 <55DDA365-3D1F-4B60-85EA-6C02A096BF0E@NLnetLabs.nl>
 <alpine.LFD.2.02.1208271827110.9526@bofh.nohats.ca>
Message-ID: <503C0D2B.6090309@ogud.com>

On 27/08/2012 18:30, Paul Wouters wrote:
>
> 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

I think that Unbound should try in general to keep a TCP connection to 
an forwarder.  I have a different issue that I think is related to port 
exhaustion on gateway device.

	Olafur