From psimerda at redhat.com Fri Apr 4 09:50:03 2014 From: psimerda at redhat.com (Pavel Simerda) Date: Fri, 4 Apr 2014 05:50:03 -0400 (EDT) Subject: [Dnssec-trigger] patch: dnssec-trigger-script: support --async In-Reply-To: <1830028353.1390563.1396604947816.JavaMail.zimbra@redhat.com> Message-ID: <2071050144.1390836.1396605003849.JavaMail.zimbra@redhat.com> Hi, this simple patch adds a possibility to fork dnssec-trigger-script and work asynchronously. Cheers, Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-dnssec-trigger-script-support-async.patch Type: text/x-patch Size: 1604 bytes Desc: not available URL: From wouter at nlnetlabs.nl Tue Apr 8 11:03:45 2014 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Tue, 08 Apr 2014 13:03:45 +0200 Subject: [Dnssec-trigger] patch: dnssec-trigger-script: support --async In-Reply-To: <2071050144.1390836.1396605003849.JavaMail.zimbra@redhat.com> References: <2071050144.1390836.1396605003849.JavaMail.zimbra@redhat.com> Message-ID: <5343D791.6040201@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Pavel, On 04/04/2014 11:50 AM, Pavel Simerda wrote: > Hi, > > this simple patch adds a possibility to fork dnssec-trigger-script > and work asynchronously. Thanks. I have applied the patch to svn trunk :-) Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTQ9eRAAoJEJ9vHC1+BF+NeW4P/1niHFpxsBd2JyMlEOgKuNZU tMJ8DiR+3pRoU861mFM1pOCMDMP9U8DNKpWyrpBWolZysFLye8DMpiqFMdmxH2T5 BMymvkWamW3s4+KAjBl6MWgxoVAE7lhCI455Cpwww/kO994lH87KyAJAOlkCqAnq sj4IHTubHbQipXNGxOeDYWxlQdnyjCm0B8wG4qPXWLXGzrlv645L/QB6bys6GgEL 1R3pbOheArPYul/U6De9Lf/cMAYTWzPMIPAMTAy0GODfo+t/PNd4bLiz+TAUxeTj nTb9xrIj3scgbifYmjJCdf06vqJ8C/MRdI3pHiNi44ertGTVoU0XcKMYQ5GiS1/k gITgF/vvAgr5H7wXxLBXAmuJqaCm3VSNSy4dfvYUN4wMV9p2te/JQNl5V38oprPO 86k2oUyvzbQiEmDQPatVnX/Z+2qi9abilmLKt1gf6CWfLhNiq48ubssMzZEE0rAz nh4E5oPWOBfySrxydcf/bNuq8oj5MJSe24I+H1o3iDnKfz53JV/8zhMrh2XOk0p7 jqaLhOA9fGd11pW5g2PcVUvVb4NMiTS2yUDSy0dW5giGJJ2x4VD3Fbs5118T7pwO KZeSwPIe/innSR+XLNnb5h6z16+ev5dSXmX4ONlZNIU3MnO/gswtjnUH8Qyf1Kdk AVL39+8DmNe/4K9KXjZY =sJ7q -----END PGP SIGNATURE----- From cra at WPI.EDU Mon Apr 14 23:49:21 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 14 Apr 2014 19:49:21 -0400 Subject: [Dnssec-trigger] dhclient-exit-hooks support Message-ID: <20140414234920.GT24434@angus.ind.WPI.EDU> Has anyone created /etc/dhclient-exit-hooks support for dnssec-trigger? One of my desktops isn't using NetworkManager because it is doing bridging, bonding, VLANs, and all sorts of other fancy stuff via the Fedora network scripts that NetworkManager didn't support until recently. I don't need VPN support, just a way to inject DHCP provided DNS forwarders (and maybe domain as well). From cra at WPI.EDU Tue Apr 15 02:45:52 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 14 Apr 2014 22:45:52 -0400 Subject: [Dnssec-trigger] dhclient-exit-hooks support In-Reply-To: <20140414220756.e841cb3b2674b512e2c8739e@belanger.fr> References: <20140414234920.GT24434@angus.ind.WPI.EDU> <20140414220756.e841cb3b2674b512e2c8739e@belanger.fr> Message-ID: <20140415024551.GU16334@angus.ind.WPI.EDU> On Mon, Apr 14, 2014 at 10:07:56PM -0400, Xavier Belanger wrote: > > Has anyone created /etc/dhclient-exit-hooks support for > > dnssec-trigger? One of my desktops isn't using NetworkManager because > > it is doing bridging, bonding, VLANs, and all sorts of other fancy > > stuff via the Fedora network scripts that NetworkManager didn't > > support until recently. I don't need VPN support, just a way to > > inject DHCP provided DNS forwarders (and maybe domain as well). > > Sort of. Long time ago I have wrote a couple of scripts to use > unbound and dnssec-trigger on Slackware (before NetworkManager get > included in that distro). I did find this: http://www.incenp.org/notes/2013/dnssec-trigger-on-slackware.html but Fedora is using ISC dhclient rather than dhcpcd. I was hoping someone has done this already for dhclient and Fedora's network scripts. If not, I'll probably end up doing it myself. > Files are here: > http://www.ellendhel.net/fichiers/dnssec-slackware.zip The most > useful to you should be '25-dnssec-trigger'. Thanks, I'll take a look and see if they can be adapted. From nlnetlabs at belanger.fr Tue Apr 15 02:07:56 2014 From: nlnetlabs at belanger.fr (Xavier Belanger) Date: Mon, 14 Apr 2014 22:07:56 -0400 Subject: [Dnssec-trigger] dhclient-exit-hooks support In-Reply-To: <20140414234920.GT24434@angus.ind.WPI.EDU> References: <20140414234920.GT24434@angus.ind.WPI.EDU> Message-ID: <20140414220756.e841cb3b2674b512e2c8739e@belanger.fr> Hi, > Has anyone created /etc/dhclient-exit-hooks support for > dnssec-trigger? One of my desktops isn't using NetworkManager because > it is doing bridging, bonding, VLANs, and all sorts of other fancy > stuff via the Fedora network scripts that NetworkManager didn't > support until recently. I don't need VPN support, just a way to > inject DHCP provided DNS forwarders (and maybe domain as well). Sort of. Long time ago I have wrote a couple of scripts to use unbound and dnssec-trigger on Slackware (before NetworkManager get included in that distro). Here are the steps: - modify dhcpcd.conf to add the option 'resolv.conf' to the 'nohook' command. That way dhcpcd will not try to change /etc/resolv.conf. - add a dhcpcd hook script to send the DNS servers provided by the local DHCP server to Unbound or (especially during the system boot) store the DNS servers into a temporary file. - in the dnssec-trigger startup script look for the temporary file and load the DNS servers into the Unbound configuration. It's far from perfect or even reliable, not heavily tested, but it works. Files are here: http://www.ellendhel.net/fichiers/dnssec-slackware.zip The most useful to you should be '25-dnssec-trigger'. And there is a more detailled blog post, but in French: [ http://www.ellendhel.net/article.php?ref=2011+12+24-0 ] I don't have any experience with Fedora so you will probably need to adjust the files locations. Sincerely. -- Xavier Belanger From schnouki at schnouki.net Tue Apr 15 07:15:51 2014 From: schnouki at schnouki.net (Thomas Jost) Date: Tue, 15 Apr 2014 09:15:51 +0200 Subject: [Dnssec-trigger] dhclient-exit-hooks support In-Reply-To: <20140414220756.e841cb3b2674b512e2c8739e@belanger.fr> References: <20140414234920.GT24434@angus.ind.WPI.EDU> <20140414220756.e841cb3b2674b512e2c8739e@belanger.fr> Message-ID: <8738hfqd08.fsf@schnouki.net> Le 15 avril 2014 ? 04:07 CEST, Xavier Belanger a ?crit : > Hi, > >> Has anyone created /etc/dhclient-exit-hooks support for >> dnssec-trigger? One of my desktops isn't using NetworkManager because >> it is doing bridging, bonding, VLANs, and all sorts of other fancy >> stuff via the Fedora network scripts that NetworkManager didn't >> support until recently. I don't need VPN support, just a way to >> inject DHCP provided DNS forwarders (and maybe domain as well). > > Sort of. Long time ago I have wrote a couple of scripts to use > unbound and dnssec-trigger on Slackware (before NetworkManager get > included in that distro). > > Here are the steps: > > - modify dhcpcd.conf to add the option 'resolv.conf' to the 'nohook' > command. That way dhcpcd will not try to change /etc/resolv.conf. > > - add a dhcpcd hook script to send the DNS servers provided > by the local DHCP server to Unbound or (especially during the system boot) > store the DNS servers into a temporary file. > > - in the dnssec-trigger startup script look for the temporary > file and load the DNS servers into the Unbound configuration. > > It's far from perfect or even reliable, not heavily tested, but it works. > > Files are here: http://www.ellendhel.net/fichiers/dnssec-slackware.zip > The most useful to you should be '25-dnssec-trigger'. > > And there is a more detailled blog post, but in French: > > [ http://www.ellendhel.net/article.php?ref=2011+12+24-0 ] > > I don't have any experience with Fedora so you will probably need > to adjust the files locations. > > Sincerely. > -- > Xavier Belanger > _______________________________________________ > dnssec-trigger mailing list > dnssec-trigger at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger Hi there, If it can be of any use, I have a similar setup on Arch Linux. After installing unbound and dnssec-trigger, I just added a hook in /usr/lib/dhcpcd/dhcpcd-hooks, and changed the dnssec-triggerdd.service file (for systemd). This setup is described here: http://schnouki.net/posts/2014/03/30/dnssec-trigger-on-arch-linux-without-network-manager/ Hope this helps. Cheers, -- Thomas/Schnouki -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 489 bytes Desc: not available URL: From wouter at nlnetlabs.nl Tue Apr 15 08:00:03 2014 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Tue, 15 Apr 2014 10:00:03 +0200 Subject: [Dnssec-trigger] dhclient-exit-hooks support In-Reply-To: <8738hfqd08.fsf@schnouki.net> References: <20140414234920.GT24434@angus.ind.WPI.EDU> <20140414220756.e841cb3b2674b512e2c8739e@belanger.fr> <8738hfqd08.fsf@schnouki.net> Message-ID: <534CE703.8020102@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, While you create your new dnssec-trigger set up, it would probably be nice to know that we are planning to release a new version of dnssec-trigger very soon. The reason is that our ip-address block is changing, and this needs to be reflected in the dnssec-trigger.conf file. Our server (fallback to tcp80 and ssl443) changes. Without that server dnssec-trigger will still work but has less fallback options that work. So prepare to get an update soon after you set this up. Perhaps just fixing up the tcp80 and ssl443 statements in the dnssec-trigger.conf is enough to get up to speed. Best regards, Wouter On 04/15/2014 09:15 AM, Thomas Jost wrote: > Le 15 avril 2014 ? 04:07 CEST, Xavier Belanger > a ?crit : >> Hi, >> >>> Has anyone created /etc/dhclient-exit-hooks support for >>> dnssec-trigger? One of my desktops isn't using NetworkManager >>> because it is doing bridging, bonding, VLANs, and all sorts of >>> other fancy stuff via the Fedora network scripts that >>> NetworkManager didn't support until recently. I don't need VPN >>> support, just a way to inject DHCP provided DNS forwarders (and >>> maybe domain as well). >> >> Sort of. Long time ago I have wrote a couple of scripts to use >> unbound and dnssec-trigger on Slackware (before NetworkManager >> get included in that distro). >> >> Here are the steps: >> >> - modify dhcpcd.conf to add the option 'resolv.conf' to the >> 'nohook' command. That way dhcpcd will not try to change >> /etc/resolv.conf. >> >> - add a dhcpcd hook script to send the DNS servers provided by >> the local DHCP server to Unbound or (especially during the system >> boot) store the DNS servers into a temporary file. >> >> - in the dnssec-trigger startup script look for the temporary >> file and load the DNS servers into the Unbound configuration. >> >> It's far from perfect or even reliable, not heavily tested, but >> it works. >> >> Files are here: >> http://www.ellendhel.net/fichiers/dnssec-slackware.zip The most >> useful to you should be '25-dnssec-trigger'. >> >> And there is a more detailled blog post, but in French: >> >> [ http://www.ellendhel.net/article.php?ref=2011+12+24-0 ] >> >> I don't have any experience with Fedora so you will probably >> need to adjust the files locations. >> >> Sincerely. -- Xavier Belanger >> _______________________________________________ dnssec-trigger >> mailing list dnssec-trigger at NLnetLabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger > > Hi there, > > If it can be of any use, I have a similar setup on Arch Linux. > After installing unbound and dnssec-trigger, I just added a hook > in /usr/lib/dhcpcd/dhcpcd-hooks, and changed the > dnssec-triggerdd.service file (for systemd). > > This setup is described here: > http://schnouki.net/posts/2014/03/30/dnssec-trigger-on-arch-linux-without-network-manager/ > > Hope this helps. > > Cheers, > > > > _______________________________________________ dnssec-trigger > mailing list dnssec-trigger at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTTOcDAAoJEJ9vHC1+BF+NKsEP/RpwSKPQxazIAZf5FOAQY5io lq0Ggz0jhSgafOUThw2Tc7pd1Yw/bySSD6OINdZ6FnFEQqwNiHaFZAt0DmUSYU+f KlXY+PE3Z7T76/fKzHJpZcQ7Apxmu4wMEWscKpRCIJKDok1fBuspE491cJxQv2V7 opik0WyaaQiFKdz8y+v+3hpLnxZsO5FJvd9l/tDSF+zpJERd1dDDtmq16kfpDOS9 PBdXYk32bGzWzJGPNAa9Sr+JW9TaiIWxcNrjU0uDjyh5zxMYaQKeWE7OslUeRPXx G7QGwMMavTdVhjsfpeiex8yBhXaa4P0F7eFMpLY2g9B++ug1kOU/ZWGdrLsA522v 4AFJXtA2Yq5U4fC7sXOYNCO4leaq2/SSG8M4CVN9R+jvL+1Oij1ni6qjNbxyHVZJ j62USrTkiIOZPxcAA2jDhiE8vZMDqGExwjB2npyl67ZJVnIfWx5WW8raSMtb9HnK ImhUhDOMqkBpY2Q3IPFg51YYPA6yD0tPVSbjhG6usUk/KGa9xAtiza3TfjMFJL+v DCklPwwq0eqQa+ZdA4RYM2E64pCA16OURLYc9D2bBseaLBF5JWbxt8pF8ucWjFjM 3FK5oo3Z4aRU6HL61brEG5KSUjazSK0SF3nuHhUoxArC6fDt3T9/F0QiLAIA3Tun hYgdIyzxvUzL23WyChDn =+9H4 -----END PGP SIGNATURE----- From psimerda at redhat.com Tue Apr 15 09:49:28 2014 From: psimerda at redhat.com (Pavel Simerda) Date: Tue, 15 Apr 2014 05:49:28 -0400 (EDT) Subject: [Dnssec-trigger] next version of dnssec trigger In-Reply-To: <534CE703.8020102@nlnetlabs.nl> References: <20140414234920.GT24434@angus.ind.WPI.EDU> <20140414220756.e841cb3b2674b512e2c8739e@belanger.fr> <8738hfqd08.fsf@schnouki.net> <534CE703.8020102@nlnetlabs.nl> Message-ID: <238802728.2604895.1397555368526.JavaMail.zimbra@redhat.com> > it would probably be > nice to know that we are planning to release a new version of > dnssec-trigger very soon. Hi, could we coordinate a little bit? I have some important changes to the integration with NetworkManager and would like to deliver them in time for the next release. Cheers, Pavel From wouter at nlnetlabs.nl Tue Apr 15 09:57:12 2014 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Tue, 15 Apr 2014 11:57:12 +0200 Subject: [Dnssec-trigger] next version of dnssec trigger In-Reply-To: <238802728.2604895.1397555368526.JavaMail.zimbra@redhat.com> References: <20140414234920.GT24434@angus.ind.WPI.EDU> <20140414220756.e841cb3b2674b512e2c8739e@belanger.fr> <8738hfqd08.fsf@schnouki.net> <534CE703.8020102@nlnetlabs.nl> <238802728.2604895.1397555368526.JavaMail.zimbra@redhat.com> Message-ID: <534D0278.9020805@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Pavel, On 04/15/2014 11:49 AM, Pavel Simerda wrote: >> it would probably be nice to know that we are planning to release >> a new version of dnssec-trigger very soon. > > Hi, > > could we coordinate a little bit? I have some important changes to > the integration with NetworkManager and would like to deliver them > in time for the next release. Absolutely. Just mail me when you have it. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTTQJ4AAoJEJ9vHC1+BF+N19AQAKoDEQLnZ1ysRgBX4AEJru6w HhaTtnuyLkd5TQaYFiKBb9RQUeY4wKkzHyo9/bAALxK/mXF8+x4v2A/Mcp1roF0v Nsty5iskzuX8yriAhTQiDnC0Y61Ks5wCDpjWhlB5M3ArY7we06MYhYU3j+G/L51s APcj0cUa4IxHwb/7O/Elorcqzy4Xxn008iUIx4hRGVZYwT9GiDACAqfXlnIv+E+Y v6Aw8ikfQW3mwIzIER+Nys1vpJyopQ4ST3p07fR9WhiTsLP4XtpXIVvaoduCJBeF 7XzWrx7MrDw5x3TsoKVLji02tm0hxXwBwJ2Gm/hN5V4upw5FyepTZ3htJUqR9Res QvITgF+kLscciPK9Ed2R1jsgGFnBmu4Ebv6KkDjkxwFAajyC4vNG1ASOQwWjZ7Zp esQAyN46cxhOoWshCpf5Y1msCOSJ/NHkROx/9heLLmb0zGKAcukpM9oVxDVvbBJc JH43h8t2njLZMes3TjvnQNZFpHG/DpSQho1ZiFpmN42OSb/MNNf0XW6/yOU8i0mX Gc/ZppOP9TQY7NiWZ+kcTEB1MiCcIQJHT4WcfSN4aWuUkmW7R6tYjHeS9gB7R3L9 k9DLnXmBKQdSq+wKjW9Y+nEf723GZg7bqtN5iTqsr4JNsJ+v2dVmVJSQptfBD84F b4lhafbQhiDs3R9eEJpI =5Vl5 -----END PGP SIGNATURE----- From cra at WPI.EDU Tue Apr 15 12:39:26 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 15 Apr 2014 08:39:26 -0400 Subject: [Dnssec-trigger] next version of dnssec trigger In-Reply-To: <238802728.2604895.1397555368526.JavaMail.zimbra@redhat.com> References: <20140414234920.GT24434@angus.ind.WPI.EDU> <20140414220756.e841cb3b2674b512e2c8739e@belanger.fr> <8738hfqd08.fsf@schnouki.net> <534CE703.8020102@nlnetlabs.nl> <238802728.2604895.1397555368526.JavaMail.zimbra@redhat.com> Message-ID: <20140415123925.GV16334@angus.ind.WPI.EDU> On Tue, Apr 15, 2014 at 05:49:28AM -0400, Pavel Simerda wrote: > > it would probably be > > nice to know that we are planning to release a new version of > > dnssec-trigger very soon. > > Hi, > > could we coordinate a little bit? I have some important changes to the integration with NetworkManager and would like to deliver them in time for the next release. Having just installed dnssec-trigger on Fedora 20, I'm having trouble with it noticing when I change wireless networks with NetworkManager. The forwarders aren't being changed, so it still shows the old DNS server addresses as cache in "dnssec-trigger-control status". Is this a known issue that will be addressed? I don't think the dispatcher scripts are running because I don't see any of the messages showing up in the journal. NetworkManager-0.9.9.0-34.git20131003.fc20.x86_64 From thozza at redhat.com Tue Apr 15 13:05:47 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 15 Apr 2014 09:05:47 -0400 (EDT) Subject: [Dnssec-trigger] next version of dnssec trigger In-Reply-To: <20140415123925.GV16334@angus.ind.WPI.EDU> References: <20140414234920.GT24434@angus.ind.WPI.EDU> <20140414220756.e841cb3b2674b512e2c8739e@belanger.fr> <8738hfqd08.fsf@schnouki.net> <534CE703.8020102@nlnetlabs.nl> <238802728.2604895.1397555368526.JavaMail.zimbra@redhat.com> <20140415123925.GV16334@angus.ind.WPI.EDU> Message-ID: <827825048.2636074.1397567147022.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On Tue, Apr 15, 2014 at 05:49:28AM -0400, Pavel Simerda wrote: > > > it would probably be > > > nice to know that we are planning to release a new version of > > > dnssec-trigger very soon. > > > > Hi, > > > > could we coordinate a little bit? I have some important changes to the > > integration with NetworkManager and would like to deliver them in time for > > the next release. > > Having just installed dnssec-trigger on Fedora 20, I'm having trouble > with it noticing when I change wireless networks with NetworkManager. > The forwarders aren't being changed, so it still shows the old DNS > server addresses as cache in "dnssec-trigger-control status". Is this > a known issue that will be addressed? I don't think the dispatcher > scripts are running because I don't see any of the messages showing up > in the journal. > > NetworkManager-0.9.9.0-34.git20131003.fc20.x86_64 Hi. This is not a known issue AFAIK. I'm running dnssec-trigger with NM on Fedora 20 and it works OK and seamless most of the time. Can you please do some more debugging? Please make sure the dispatcher script is where it should be and it's executable. If you are connected to a wired network at the same time when you are changing wireless networks, the dispatcher script will use the DNS servers from NM default connection (which is most of the time the wired connection). You can check all your active connections using 'nmcli c s' and see which one is default. Then just use the same command with the UUID of the connection in the end to see DNS servers provided with it. It may bring some light on why is this happening. The dispatcher script also logs actions it does, but if there no change it will do nothing. However the global forwarders are configured on any network change. Feel free to post some more information so we can resolve it somehow. You can also create a Bug in Red Hat Bugzilla and we can discuss it there. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From cra at WPI.EDU Tue Apr 15 15:22:55 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 15 Apr 2014 11:22:55 -0400 Subject: [Dnssec-trigger] next version of dnssec trigger In-Reply-To: <827825048.2636074.1397567147022.JavaMail.zimbra@redhat.com> References: <20140414234920.GT24434@angus.ind.WPI.EDU> <20140414220756.e841cb3b2674b512e2c8739e@belanger.fr> <8738hfqd08.fsf@schnouki.net> <534CE703.8020102@nlnetlabs.nl> <238802728.2604895.1397555368526.JavaMail.zimbra@redhat.com> <20140415123925.GV16334@angus.ind.WPI.EDU> <827825048.2636074.1397567147022.JavaMail.zimbra@redhat.com> Message-ID: <20140415152254.GW16334@angus.ind.WPI.EDU> On Tue, Apr 15, 2014 at 09:05:47AM -0400, Tomas Hozza wrote: > ----- Original Message ----- > > On Tue, Apr 15, 2014 at 05:49:28AM -0400, Pavel Simerda wrote: > > > > it would probably be > > > > nice to know that we are planning to release a new version of > > > > dnssec-trigger very soon. > > > > > > Hi, > > > > > > could we coordinate a little bit? I have some important changes to the > > > integration with NetworkManager and would like to deliver them in time for > > > the next release. > > > > Having just installed dnssec-trigger on Fedora 20, I'm having trouble > > with it noticing when I change wireless networks with NetworkManager. > > The forwarders aren't being changed, so it still shows the old DNS > > server addresses as cache in "dnssec-trigger-control status". Is this > > a known issue that will be addressed? I don't think the dispatcher > > scripts are running because I don't see any of the messages showing up > > in the journal. > > > > NetworkManager-0.9.9.0-34.git20131003.fc20.x86_64 > > Hi. > > This is not a known issue AFAIK. I'm running dnssec-trigger with NM > on Fedora 20 and it works OK and seamless most of the time. > > Can you please do some more debugging? Please make sure the dispatcher > script is where it should be and it's executable. > > If you are connected to a wired network at the same time when you are > changing wireless networks, the dispatcher script will use the DNS > servers from NM default connection (which is most of the time the > wired connection). You can check all your active connections using > 'nmcli c s' and see which one is default. Then just use the same > command with the UUID of the connection in the end to see DNS > servers provided with it. It may bring some light on why is this > happening. > > The dispatcher script also logs actions it does, but if there no change > it will do nothing. However the global forwarders are configured on > any network change. > > Feel free to post some more information so we can resolve it somehow. > You can also create a Bug in Red Hat Bugzilla and we can discuss it > there. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1087883 From paul at nohats.ca Tue Apr 15 17:21:32 2014 From: paul at nohats.ca (Paul Wouters) Date: Tue, 15 Apr 2014 13:21:32 -0400 (EDT) Subject: [Dnssec-trigger] dhclient-exit-hooks support In-Reply-To: <534CE703.8020102@nlnetlabs.nl> References: <20140414234920.GT24434@angus.ind.WPI.EDU> <20140414220756.e841cb3b2674b512e2c8739e@belanger.fr> <8738hfqd08.fsf@schnouki.net> <534CE703.8020102@nlnetlabs.nl> Message-ID: On Tue, 15 Apr 2014, W.C.A. Wijngaards wrote: > While you create your new dnssec-trigger set up, it would probably be > nice to know that we are planning to release a new version of > dnssec-trigger very soon. The reason is that our ip-address block is > changing, and this needs to be reflected in the dnssec-trigger.conf > file. Our server (fallback to tcp80 and ssl443) changes. Without > that server dnssec-trigger will still work but has less fallback > options that work. > > So prepare to get an update soon after you set this up. Perhaps just > fixing up the tcp80 and ssl443 statements in the dnssec-trigger.conf > is enough to get up to speed. Note that Fedora runs its own tcp80 / ssl443 setup and has configured dnssec-triggerd.conf to use the fedora servers for this. The NLnetlabs entries are in there as comments only. Paul From gtwilliams at gmail.com Sat Apr 19 23:22:53 2014 From: gtwilliams at gmail.com (Garry T. Williams) Date: Sat, 19 Apr 2014 19:22:53 -0400 Subject: [Dnssec-trigger] Why Does unbound Fail on So Many Requests? Message-ID: <199708661.mtTXYkQJGP@vfr> I recently installed dnssec-triggerd in Fedora 20 after following a long thread about default local DNS caching servers. Well, it mostly just works as advertised, but I see a lot of these in the system log: unbound[773]: [773:1] info: validation failure t6021.network-dns-unbound-user.dnstalk.us.dlv.isc.org. DLV IN unbound[773]: [773:0] info: validation failure natenom.name.dlv.isc.org. DLV IN unbound[773]: [773:0] info: validation failure platform.twitter.com.dlv.isc.org. DLV IN Sometimes the error later disappears. Sometimes it persists. For example, I just did this one where the error persists: garry at vfr$ dnssec-trigger-control status at 2014-04-19 18:31:30 http fedoraproject.org (209.132.181.16): OK cache 65.68.49.50: OK cache 205.152.150.23: OK cache 205.152.37.23: OK state: cache secure garry at vfr$ dig +dnssec t6021.network-dns-unbound-user.dnstalk.us @127.0.0.1 ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> +dnssec t6021.network-dns-unbound-user.dnstalk.us @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56300 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;t6021.network-dns-unbound-user.dnstalk.us. IN A ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Apr 19 19:09:04 EDT 2014 ;; MSG SIZE rcvd: 70 garry at vfr$ dig +dnssec t6021.network-dns-unbound-user.dnstalk.us @65.68.49.50 ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> +dnssec t6021.network-dns-unbound-user.dnstalk.us @65.68.49.50 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33503 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 15 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;t6021.network-dns-unbound-user.dnstalk.us. IN A ;; ANSWER SECTION: t6021.network-dns-unbound-user.dnstalk.us. 60 IN A 144.76.84.155 ;; AUTHORITY SECTION: dnstalk.us. 6304 IN NS DNS4.REGISTRAR-SERVERS.COM. dnstalk.us. 6304 IN NS DNS2.REGISTRAR-SERVERS.COM. dnstalk.us. 6304 IN NS DNS3.REGISTRAR-SERVERS.COM. dnstalk.us. 6304 IN NS DNS5.REGISTRAR-SERVERS.COM. dnstalk.us. 6304 IN NS DNS1.REGISTRAR-SERVERS.COM. ;; ADDITIONAL SECTION: DNS1.REGISTRAR-SERVERS.COM. 169361 IN A 173.245.59.40 DNS1.REGISTRAR-SERVERS.COM. 169361 IN A 173.245.58.17 DNS1.REGISTRAR-SERVERS.COM. 169361 IN A 173.245.58.45 DNS1.REGISTRAR-SERVERS.COM. 169361 IN A 173.245.59.16 DNS2.REGISTRAR-SERVERS.COM. 169361 IN A 208.64.122.242 DNS2.REGISTRAR-SERVERS.COM. 169361 IN A 208.64.122.244 DNS3.REGISTRAR-SERVERS.COM. 169361 IN A 69.197.21.28 DNS3.REGISTRAR-SERVERS.COM. 169361 IN A 69.197.21.29 DNS4.REGISTRAR-SERVERS.COM. 274 IN A 173.245.58.45 DNS4.REGISTRAR-SERVERS.COM. 274 IN A 173.245.59.16 DNS4.REGISTRAR-SERVERS.COM. 274 IN A 173.245.59.40 DNS4.REGISTRAR-SERVERS.COM. 274 IN A 173.245.58.17 DNS5.REGISTRAR-SERVERS.COM. 274 IN A 208.64.122.242 DNS5.REGISTRAR-SERVERS.COM. 274 IN A 208.64.122.244 ;; Query time: 84 msec ;; SERVER: 65.68.49.50#53(65.68.49.50) ;; WHEN: Sat Apr 19 19:09:35 EDT 2014 ;; MSG SIZE rcvd: 426 garry at vfr$ >From a user point of view, I see that part of the Internet is broken after installing this setup. What is going on here? -- Garry T. Williams From paul at nohats.ca Sun Apr 20 00:16:58 2014 From: paul at nohats.ca (Paul Wouters) Date: Sat, 19 Apr 2014 20:16:58 -0400 (EDT) Subject: [Dnssec-trigger] Why Does unbound Fail on So Many Requests? In-Reply-To: <199708661.mtTXYkQJGP@vfr> References: <199708661.mtTXYkQJGP@vfr> Message-ID: On Sat, 19 Apr 2014, Garry T. Williams wrote: > unbound[773]: [773:1] info: validation failure t6021.network-dns-unbound-user.dnstalk.us.dlv.isc.org. DLV IN > unbound[773]: [773:0] info: validation failure natenom.name.dlv.isc.org. DLV IN > unbound[773]: [773:0] info: validation failure platform.twitter.com.dlv.isc.org. DLV IN > garry at vfr$ dig +dnssec t6021.network-dns-unbound-user.dnstalk.us @127.0.0.1 > > ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> +dnssec t6021.network-dns-unbound-user.dnstalk.us @127.0.0.1 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56300 That should not happen. I've seen at times that there are timing failures when it takes long to get to the hotspot. To test that, you can try to restart unbound but load it with the same forwarders after you have authenticated with the hotspot: sudo unbound-control list_forwards systemctl restart unbound.service sudo unbound-control forward_add and try again. I think dnssec-trigger/unbound should have a combination to make negative-ttl much much shorter on "enduser systems" to avoid these kind of timing errors. Paul From gtwilliams at gmail.com Sun Apr 20 00:57:30 2014 From: gtwilliams at gmail.com (Garry T. Williams) Date: Sat, 19 Apr 2014 20:57:30 -0400 Subject: [Dnssec-trigger] Why Does unbound Fail on So Many Requests? In-Reply-To: References: <199708661.mtTXYkQJGP@vfr> Message-ID: <31067227.fIEdmTnAms@vfr> On 4-19-14 20:16:58 Paul Wouters wrote: > On Sat, 19 Apr 2014, Garry T. Williams wrote: > > > unbound[773]: [773:1] info: validation failure t6021.network-dns-unbound-user.dnstalk.us.dlv.isc.org. DLV IN > > unbound[773]: [773:0] info: validation failure natenom.name.dlv.isc.org. DLV IN > > unbound[773]: [773:0] info: validation failure platform.twitter.com.dlv.isc.org. DLV IN > > > garry at vfr$ dig +dnssec t6021.network-dns-unbound-user.dnstalk.us @127.0.0.1 > > > > ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> +dnssec t6021.network-dns-unbound-user.dnstalk.us @127.0.0.1 > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56300 > > That should not happen. I've seen at times that there are timing > failures when it takes long to get to the hotspot. To test that, you > can try to restart unbound but load it with the same forwarders > after you have authenticated with the hotspot: Thanks for the reply. I should have mentioned that my first trial with this stuff is on a desktop system at home. No hotspot here. I'm just doing some browsing and my Web browser reports errors occasionally for various domains. While trying a broken domain name, I noticed that one of my ISP's servers was not responding at all and dig timed out waiting for it. The other two responded with A and RRSIG records. My local unbound gives back SERVFAIL after a shorter wait. garry at vfr$ dig +dnssec test.dnssec-or-not.com @65.68.49.50 ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> +dnssec test.dnssec-or-not.com @65.68.49.50 ;; global options: +cmd ;; connection timed out; no servers could be reached garry at vfr$ dig +dnssec test.dnssec-or-not.com @127.0.0.1 ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> +dnssec test.dnssec-or-not.com @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37221 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;test.dnssec-or-not.com. IN A ;; Query time: 1075 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Apr 19 20:28:42 EDT 2014 ;; MSG SIZE rcvd: 51 garry at vfr$ fc -Dl ... 10843 0:15 dig +dnssec test.dnssec-or-not.com @65.68.49.50 10844 0:06 dig +dnssec test.dnssec-or-not.com @127.0.0.1 garry at vfr$ Here, BellSouth (now AT&T) doesn't respond in 15 seconds. Unbound calls it an error after six seconds. Queries on the other two BellSouth servers are returned normally in under one second. garry at vfr$ dig +dnssec test.dnssec-or-not.com @205.152.37.23 ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43577 ... ;; Query time: 719 msec ;; SERVER: 205.152.37.23#53(205.152.37.23) ;; WHEN: Sat Apr 19 20:31:44 EDT 2014 ;; MSG SIZE rcvd: 910 garry at vfr$ fc -Dl ... 10846 0:01 dig +dnssec test.dnssec-or-not.com @205.152.37.23 My conclusion is that unbound doesn't manage to go around the unresponsive server in my ISP's network. > I think dnssec-trigger/unbound should have a combination to make > negative-ttl much much shorter on "enduser systems" to avoid these > kind of timing errors. Perhaps. My observation on this /one case/ tells me this stuff needs to avoid forwarders that have become unresponsive and not cache the non- response as an answer returned to clients. But I don't know how to accomplish that. I don't remember seeing so many failures when I was running dnsmasq instead of unbound. Of course that may be because nothing was ever logged by dnsmasq -- unbound is very noisy in my system journal. Anyway, I think you have given me something to go on. Thank you. -- Garry T. Williams