From carsten at strotmann.de Sun Jul 1 10:15:10 2012 From: carsten at strotmann.de (Carsten Strotmann) Date: Sun, 01 Jul 2012 12:15:10 +0200 Subject: [Dnssec-trigger] Feature request: Restart unbound In-Reply-To: <4FEDEE20.1090209@ogud.com> References: <4FEDE6E3.6090801@ogud.com> <4FEDEE20.1090209@ogud.com> Message-ID: <4FF0232E.1010500@strotmann.de> On 6/29/12 8:04 PM, Olafur Gudmundsson wrote: > In my case: Win-7, DD-WRT, Open-WRT For Win7: DNSSEC-Trigger currently does not set any recovery options when installing Unbound as a Windows service. But you can set a recovery option manually for the Unbound service using "Administrative Tools -> Services -> Unbound -> Recovery" and set "Restart the Service" as the action on the 1st and 2nd failure. It is also possible to start an external program on failure. This external program could restart Unbound and inform dnssec-trigger about the Unbound restart so that dnssec-trigger does a re-probe of the network and reconfigures the new Unbound process. -- Carsten From paul at cypherpunks.ca Mon Jul 2 00:34:59 2012 From: paul at cypherpunks.ca (Paul Wouters) Date: Sun, 1 Jul 2012 20:34:59 -0400 (EDT) Subject: [Dnssec-trigger] Feature request: Restart unbound In-Reply-To: <4FEDEE20.1090209@ogud.com> References: <4FEDE6E3.6090801@ogud.com> <4FEDEE20.1090209@ogud.com> Message-ID: On Fri, 29 Jun 2012, Olafur Gudmundsson wrote: >>> For some reason unbound crashes upon occasion (looking for the source >>> of that problem by reading logs). >>> >>> It would be nice if DNSSEC-trigger detects that unbound has >>> crashed/gone unresponsive and attempts to restart it. >> >> On what OS? On Fedora 16/17, systemd should restart it, though it will >> have lost the dnssec-trigger configuration, and I'm not sure the trigger >> can detect unbound restarted easilly/cheaply/continiously. >> >> Paul >> >> >> > > In my case: Win-7, DD-WRT, Open-WRT My bet is that on the WRTs, unbound is crashing because it is running out of memory. You could change the init script to be something like: while true do unbound -d -c /etc/unbound.conf done I'd login and run this in a shell to confirm: while true; do cat /proc/meminfo; sleep 30; done Paul From wouter at nlnetlabs.nl Mon Jul 2 08:26:56 2012 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Mon, 02 Jul 2012 10:26:56 +0200 Subject: [Dnssec-trigger] 0.11 uses wrong nmcli parameters on NM > 0.9.[34] In-Reply-To: References: Message-ID: <4FF15B50.7020206@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, On 06/29/2012 07:12 PM, Paul Wouters wrote: > > It seems the nmcl syntax has changed. > > For Fedora 16 and 17, I needed: > > ips="`$nmcli -f IP4,IP6 dev list | fgrep 'DNS' | awk '{print > $2;}'`" > > instead of: > > ips="`$nmcli -f IP4-DNS,IP6-DNS dev list | awk '{print $2;}'`" > > It seems this change was made in NetworkManager 0.9.3 or 0.9.4. > (0.9.3 never shipped in Fedora) > > I've fired of builds with this change for F16 anf F17, but perhaps > dnssec-trigger should check using nmcli -v ? > > something like: Committed this to the svn (but moved to comment to the other part of the if-else, if the IP-DNS syntax that is the old one?) :-) Thanks for the patch! Best regards, Wouter > > $nmcli -f IP4-DNS dev list > /dev/null 2>/dev/null RETVAL=$? if [ > $RETVAL = 0 ] ; then ips="`$nmcli -f IP4-DNS,IP6-DNS dev list | awk > '{print $2;}'`" else # NM < 0.9.4 ips="`$nmcli -f IP4,IP6 dev list > | fgrep 'DNS' | awk '{print $2;}'`" fi > > Paul > > > _______________________________________________ dnssec-trigger > mailing list dnssec-trigger at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP8VtQAAoJEJ9vHC1+BF+NfdkP/jeCXqfA/FTTlby+KQXg0m2B gmCm3hZ9Jnhs7f6J0gqFMWmLp04oo2FWEE65FHbO9OJAJq25q8yOTcYIZTkTAgay nl4PZ6++YJ8yWcVkIWsxEM2at9dNvolm2ZuSZiEhw674aafAj6c9axKiMJlml7Hs ElZK7nMvR8/OCc+DlTTBALmNdsC8krnthyfsfYuQiRudqa66e956RkLVw6n7936a k30stUh/dwnugsbTawlw6pvLGyXxHme8+8xXEpY3J/o89prdJb6HvwBDz9cbBUuE Fsu27Dkh0++5uZhG5D/wjKoEnloPuT6np36Q1dl0DBQn0jPbVUiLk14vVlYGqoM8 fespIwC6tiifDIt4+ii14BqOzxH35hvGKth9mkultJ9rHjsUnwmWE7Hp7wj7cMza scfMuWIJnhvPLogNhaGz8I0aXVlZ+EbwhvSM0Vw3lJTpMwqPFFHG5/F42AGOs84A VSPcPsU0CKVTM4d2N3shkPjFOvKFgzcand3mdOBtT8s/l/lscIHsQfv61bIAJJOT OC27IKZemxGnIveefTGD4vkORR4eQoAWhObs87BYEDd8cLpd91ah+BxWYAN5TXp/ qZberKtMHA/a+ZnOtDM33HhuwVTjANHHZzFTnm6RrekxAM4SyN8bL2NVLS4umdPP otXcwdlMew5/6A1EV8f0 =X6DN -----END PGP SIGNATURE----- From paul at cypherpunks.ca Mon Jul 9 23:49:17 2012 From: paul at cypherpunks.ca (Paul Wouters) Date: Mon, 9 Jul 2012 19:49:17 -0400 (EDT) Subject: [Dnssec-trigger] [dns-operations] unbound-bind chain causing validation failures on synthesized records In-Reply-To: <20120709224038.2A4122246877@drugs.dv.isc.org> References: <20120709224038.2A4122246877@drugs.dv.isc.org> Message-ID: 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; [...] } 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 From marka at isc.org Tue Jul 10 00:21:59 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 10 Jul 2012 10:21:59 +1000 Subject: [Dnssec-trigger] [dns-operations] unbound-bind chain causing validation failures on synthesized records In-Reply-To: Your message of "Mon, 09 Jul 2012 19:49:17 -0400." References: <20120709224038.2A4122246877@drugs.dv.isc.org> Message-ID: <20120710002200.26DF322471F6@drugs.dv.isc.org> In message , 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 From ondrej at caletka.cz Mon Jul 16 08:33:59 2012 From: ondrej at caletka.cz (=?UTF-8?B?T25kxZllaiBDYWxldGth?=) Date: Mon, 16 Jul 2012 10:33:59 +0200 Subject: [Dnssec-trigger] [dns-operations] unbound-bind chain causing validation failures on synthesized records In-Reply-To: References: <20120709224038.2A4122246877@drugs.dv.isc.org> Message-ID: <5003D1F7.6060301@caletka.cz> Hi, Dne 10.7.2012 01:49, Paul Wouters napsal(a): > I'm CC:ing the dnssec-trigger list, as it might need to come up with a > new probe to detect this. I would also vote for this kind of detection. I already ran into the same issue when testing DNSSEC-trigger. The chaining problem seems fixed in BIND 9.9.0 and newer. But since there are still so many BINDs 9.7 running out there, it is not safe to forward your unbound to the DHCP-assigned DNS server. And current DNSSEC-trigger does not find out that something is wrong. I created some testing page to test your ability to reach synthetised names. Feel free to try it: http://0skar.cz/dns/en/ Cheers, Ond?ej Caletka From paul at cypherpunks.ca Mon Jul 16 14:11:07 2012 From: paul at cypherpunks.ca (Paul Wouters) Date: Mon, 16 Jul 2012 10:11:07 -0400 (EDT) Subject: [Dnssec-trigger] [dns-operations] unbound-bind chain causing validation failures on synthesized records In-Reply-To: <5003D1F7.6060301@caletka.cz> References: <20120709224038.2A4122246877@drugs.dv.isc.org> <5003D1F7.6060301@caletka.cz> Message-ID: On Mon, 16 Jul 2012, Ond?ej Caletka wrote: > Dne 10.7.2012 01:49, Paul Wouters napsal(a): >> I'm CC:ing the dnssec-trigger list, as it might need to come up with a >> new probe to detect this. > > I would also vote for this kind of detection. I already ran into the > same issue when testing DNSSEC-trigger. The chaining problem seems fixed > in BIND 9.9.0 and newer. I've still seen issues with bind and 9.9.1 when configured with dnssec but without validation. > But since there are still so many BINDs 9.7 > running out there, it is not safe to forward your unbound to the > DHCP-assigned DNS server. And current DNSSEC-trigger does not find out > that something is wrong. Though at some point the question would be, what's best? DNSSEC protected resolving of most domains, or an insecure fallback? > I created some testing page to test your ability to reach synthetised > names. Feel free to try it: > http://0skar.cz/dns/en/ Thanks, those are really useful! Paul From regnauld at nsrc.org Wed Jul 25 16:01:19 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 25 Jul 2012 18:01:19 +0200 Subject: [Dnssec-trigger] DNSSEC trigger on OS X Mountain Lion seems to work ok Message-ID: <20120725160118.GC1432@macbook.bluepipe.net> 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). Cheers, Phil From olaf at NLnetLabs.nl Fri Jul 27 07:09:02 2012 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Fri, 27 Jul 2012 09:09:02 +0200 Subject: [Dnssec-trigger] Beware when upgrading to Mountain Lion (was: 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: <55DDA365-3D1F-4B60-85EA-6C02A096BF0E@NLnetLabs.nl> On Jul 25, 2012, at 6:01 PM, Phil Regnauld 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). I have noticed that unbound failed to start after I upgraded [*] If you find yourself in that situation, set dnssec-trigger to hot-spot-signon mode in order to connect to the Internet. This is because the installation script does not create a UniqueID and PrimaryGroupID for the unbound user. It seems that mountain lion does need these IDs in order to be recognized as a unix user, in contrast to previous versions of OS X. If the command $ id unbound returns "no such user", you know that you have been bitten by this problem. To fix: Allocate yourself a free id. You can see the allocated ids using the following: dscl localhost -list /Local/Default/Groups PrimaryGroupID dscl localhost -list /Local/Default/Users UniqueID Then assign the ids to the unbound user. sudo dscl localhost -create /Local/Default/Users/unbound PrimaryGroupID sudo dscl localhost -create /Local/Default/Users/unbound UniqueID (I have toyed around with the user creation script below; use at your own risk.) Finally, we will be fixing the dnssec-trigger package in the order of weeks (rather than days). --Olaf [*] It might be that Phil did not encounter this problem because unbound had been released earlier, e.g. through a port. #!/bin/bash USERNAME=unbound REALNAME="unbound daemon" NFSHomeDirectory="/etc/unbound/" MAXID=1000 if [[ $UID -ne 0 ]]; then echo "Please run $0 as root." && exit 1; fi # We prefer to use the same GID and UID so need to test that. # Start with the the first slot after the highes allocated number in the 200-300 range. id=$(dscl localhost -list /Local/Default/Users UniqueID | awk '{ if ( $2 > max && $2 <300 ) max = $2 } END { print max+1 }' ) while [ $id -le $MAXID ] # Really we are exagerating here... surely there will be one ID free below 1000. do gid="" uid="" gid=$(dscl localhost -search /Local/Default/Groups PrimaryGroupID $id) uid=$(dscl localhost -search /Local/Default/Users UniqueID $id) if [ -z "$gid$uid" ] then break fi id=$(($id+1)) done echo $id $MAXID if [ $id -eq $((MAXID+1)) ] ; then echo "NO FREE IDs" exit else dscl localhost -create /Local/Default/Users/${USERNAME} dscl localhost -create /Local/Default/Users/${USERNAME} UserShell /usr/bin/false dscl localhost -create /Local/Default/Users/${USERNAME} PrimaryGroupID ${id} dscl localhost -create /Local/Default/Users/${USERNAME} UniqueID ${id} dscl localhost -create /Local/Default/Users/${USERNAME} RealName ${REALNAME} dscl localhost -create /Local/Default/Users/${USERNAME} NFSHomeDirectory ${NSFHomeDirectory} fi NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf at NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2262 bytes Desc: not available URL: From regnauld at nsrc.org Fri Jul 27 08:56:57 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Fri, 27 Jul 2012 10:56:57 +0200 Subject: [Dnssec-trigger] Beware when upgrading to Mountain Lion (was: DNSSEC trigger on OS X Mountain Lion seems to work ok) 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: <20120727085657.GM1531@macbook.bluepipe.net> Olaf Kolkman (olaf) writes: > > [*] It might be that Phil did not encounter this problem because unbound had been released earlier, e.g. through a port. I effectively did an upgrade, so all existing users were preserved. I did not think of testing with a reinstall. Thanks for the update! Cheers, Phil