From billy.glynn at iedr.ie Wed Sep 3 15:33:40 2014 From: billy.glynn at iedr.ie (Billy Glynn) Date: Wed, 3 Sep 2014 16:33:40 +0100 Subject: [Dnssec-trigger] resolv.conf options in dnssec-trigger.conf Message-ID: <4ED79DEC-6AEC-47FE-8091-0886D68F1279@iedr.ie> Hi, I was wondering if I could set resolv.conf options via dnssec-trigger.conf ? options timeout:1 attempts:1 rotate Thanks Billy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From paul at nohats.ca Wed Sep 3 17:49:09 2014 From: paul at nohats.ca (Paul Wouters) Date: Wed, 3 Sep 2014 13:49:09 -0400 (EDT) Subject: [Dnssec-trigger] resolv.conf options in dnssec-trigger.conf In-Reply-To: <4ED79DEC-6AEC-47FE-8091-0886D68F1279@iedr.ie> References: <4ED79DEC-6AEC-47FE-8091-0886D68F1279@iedr.ie> Message-ID: On Wed, 3 Sep 2014, Billy Glynn wrote: > I was wondering if I could set resolv.conf options via dnssec-trigger.conf ? > > options timeout:1 attempts:1 rotate I think dnssec-trigger should read resolv.conf and copy all the options found (of course not nameserver options, but arguably it should include the domain/search option) Paul From post at ralfj.de Wed Sep 3 17:32:49 2014 From: post at ralfj.de (Ralf Jung) Date: Wed, 03 Sep 2014 19:32:49 +0200 Subject: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN Message-ID: <540750C1.5010306@ralfj.de> Dear dnssec-trigger developers, I hope this is the right channel for a bugreport, please excuse me if it is not. First of all, thanks a lot for making this awesome program. It is exactly what I looked for to finally use DNSSEC on my Laptop :) I am having a problem though when using dnssec-trigger with network-mananger and VPN connections. After the connection is established, dnssec-trigger still uses the DNS servers supplied by the physical "outer" connection, instead of the ones that came from the VPN. Thus, DNS does not work if the servers are configured to serve the local network only. I can see the following in the system journal after the VPN connection is established: > Sep 01 11:12:12 r-schnelltop logger[3766]: dnssec-trigger-hook(networkmanager) vpn0 vpn-up added global DNS 134.96.7.100 134.96.7.99 134.96.7.5 However, these are the DNS servers of wlan0. The VPN returned a different set of DNS servers. Only after supplying the VPN-DNS-servers to dnssec-trigger-control, everything works as expected. I am using the packages in Debian testing, and also reported this issue downstream: The version of NM is 0.9.10.0, dnssec-trigger is at version 0.13~svn685. Kind regards Ralf From paul at nohats.ca Wed Sep 3 19:47:19 2014 From: paul at nohats.ca (Paul Wouters) Date: Wed, 3 Sep 2014 15:47:19 -0400 (EDT) Subject: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN In-Reply-To: <540750C1.5010306@ralfj.de> References: <540750C1.5010306@ralfj.de> Message-ID: On Wed, 3 Sep 2014, Ralf Jung wrote: > I hope this is the right channel for a bugreport, please excuse me if it > is not. > First of all, thanks a lot for making this awesome program. It is > exactly what I looked for to finally use DNSSEC on my Laptop :) > > I am having a problem though when using dnssec-trigger with > network-mananger and VPN connections. After the connection is > established, dnssec-trigger still uses the DNS servers supplied by the > physical "outer" connection, instead of the ones that came from the VPN. > Thus, DNS does not work if the servers are configured to serve the local > network only. > I can see the following in the system journal after the VPN connection > is established: > >> Sep 01 11:12:12 r-schnelltop logger[3766]: dnssec-trigger-hook(networkmanager) vpn0 vpn-up added global DNS 134.96.7.100 134.96.7.99 134.96.7.5 > > However, these are the DNS servers of wlan0. The VPN returned a > different set of DNS servers. > Only after supplying the VPN-DNS-servers to dnssec-trigger-control, > everything works as expected. > > I am using the packages in Debian testing, and also reported this issue > downstream: > The version of NM is 0.9.10.0, dnssec-trigger is at version 0.13~svn685. In fedora/rhel/centos, we have hooks in the vpn software that checks if unbound is running, and reconfigured unbound. We have this for libreswan IPsec and in openvpn (and I believe vpnc). What VPN software are you using? Here is an example (see around line 209): https://github.com/libreswan/libreswan/blob/master/programs/_updown.netkey/_updown.netkey.in Paul From post at ralfj.de Wed Sep 3 20:31:48 2014 From: post at ralfj.de (Ralf Jung) Date: Wed, 03 Sep 2014 22:31:48 +0200 Subject: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN In-Reply-To: References: <540750C1.5010306@ralfj.de> Message-ID: <54077AB4.7020104@ralfj.de> Hi, >> I am using the packages in Debian testing, and also reported this issue >> downstream: >> The version of NM is 0.9.10.0, dnssec-trigger is at version 0.13~svn685. > > In fedora/rhel/centos, we have hooks in the vpn software that checks if > unbound is running, and reconfigured unbound. We have this for libreswan > IPsec and in openvpn (and I believe vpnc). What VPN software are you > using? > > Here is an example (see around line 209): > > https://github.com/libreswan/libreswan/blob/master/programs/_updown.netkey/_updown.netkey.in I am using OpenConnect - it not being on your list may explain the problem ;-) . I had hoped that there would be some general solution to hook into NM, that doesn't require additional work for each VPN provider. Is there a common infrastructure, or would I have to start from scratch if I wanted to add support to OpenConnect for this? So unbound needs to be explicitly supported for this use by the VPN providers, but dnssec-trigger can hook into that properly? After all, it has to re-do the probe after the VPN connection is established. Kind regards Ralf From paul at nohats.ca Thu Sep 4 12:32:46 2014 From: paul at nohats.ca (Paul Wouters) Date: Thu, 4 Sep 2014 08:32:46 -0400 (EDT) Subject: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN In-Reply-To: <54077AB4.7020104@ralfj.de> References: <540750C1.5010306@ralfj.de> <54077AB4.7020104@ralfj.de> Message-ID: On Wed, 3 Sep 2014, Ralf Jung wrote: > I am using OpenConnect - it not being on your list may explain the > problem ;-) . I had hoped that there would be some general solution to > hook into NM, that doesn't require additional work for each VPN > provider. Is there a common infrastructure, or would I have to start > from scratch if I wanted to add support to OpenConnect for this? There is a somewhat generic method, but your VPN software gets the DNS servers via its VPN protocol, and it needs to expose this somehow to either NM or dnssec-trigger or unbound. > So unbound needs to be explicitly supported for this use by the VPN > providers, but dnssec-trigger can hook into that properly? After all, it > has to re-do the probe after the VPN connection is established. It should not need to re-probe. If you have VPN DNS servers, you are basically forced to use those. For the IPsec case, you also get a domain, so unbound can be told to only use those DNS servers for that domain. So probing it makes no sense, you need to use it anyway to get the internal DNS view at the other end of the VPN. But some VPN protocols might required you send all DNS queries to them. Paul From post at ralfj.de Thu Sep 4 12:41:50 2014 From: post at ralfj.de (Ralf Jung) Date: Thu, 04 Sep 2014 14:41:50 +0200 Subject: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN In-Reply-To: References: <540750C1.5010306@ralfj.de> <54077AB4.7020104@ralfj.de> Message-ID: <54085E0E.90100@ralfj.de> Hi, > There is a somewhat generic method, but your VPN software gets the > DNS servers via its VPN protocol, and it needs to expose this somehow > to either NM or dnssec-trigger or unbound. I see. What's the recommended way to notify? (I will soon be gone for 2 weeks, so I'll only be able to pursue this further afterwards.) > It should not need to re-probe. If you have VPN DNS servers, you are > basically forced to use those. For the IPsec case, you also get a > domain, so unbound can be told to only use those DNS servers for that > domain. So probing it makes no sense, you need to use it anyway to get > the internal DNS view at the other end of the VPN. > > But some VPN protocols might required you send all DNS queries to them. I don't understand this. What makes VPNs different here than non-VPN internet accesses? The DNS servers change, sure, but I don't see anything forcing me to actually use them - at least, not more so than anything forces me to use the DNS servers supplied via DHCP on a physical wire. Sure, in both cases the supplied DNS may do "special" things, or serve some local-only zones, or whatever - but none of this is VPN-exclusive. Also, even if the supplied servers had to be used, there's still the question of whether unbound queries them and verifies the result - or whether "insecure" mode is used. In my particular case, I extracted the DNS servers supplied by the VPN from the log, and fed them to "dnssec-trigger-control submit". Then everything worked as expected (well, almost, but that's an independent issue). Without manual intervention, the old "physical" DNS servers remained in /etc/resolv.conf (put there by dnssec-trigger after the probe failed), resulting in no name resolution being possible. Kind regards Ralf From arne at arnested.dk Fri Sep 12 05:05:53 2014 From: arne at arnested.dk (=?iso-8859-1?Q?Arne_J=F8rgensen?=) Date: Fri, 12 Sep 2014 07:05:53 +0200 Subject: [Dnssec-trigger] Help diagnose DNSSEC hostile network Message-ID: Hi, Recently something changed in the network at my work and now Dnssec-Trigger bails out with "The Network Fails to Support DNSSEC". Dnssec-Trigger still works fine on other networks so it seems obvious that something changed somewhere in the network at work or at my workplaces internet supplier. If I am to report this as a problem I would like to supply them with a more precise description of what they changed and how they could fix it (otherwise the report will most likely be shelved). What should I look for? What is the best way to diagnose such a problem? The probe results contain this info: #v+ dnssec-trigger 0.12 results from probe at 2014-09-12 06:53:04 ssl443 185.49.140.67: error TCP connection failure tcp80 185.49.140.67: error TCP connection failure authority 192.5.5.241: error timeout http fedoraproject.org (209.132.181.16): OK cache 91.143.114.64: error timeout cache 91.143.112.64: error timeout cache 91.143.114.64: error timeout cache 91.143.112.64: error timeout DNS queries are sent to INSECURE servers. Please, be careful out there. #v- Kind regards, Arne J?rgensen From post at ralfj.de Fri Sep 12 10:05:35 2014 From: post at ralfj.de (Ralf Jung) Date: Fri, 12 Sep 2014 12:05:35 +0200 Subject: [Dnssec-trigger] Help diagnose DNSSEC hostile network In-Reply-To: References: Message-ID: <5412C56F.2020809@ralfj.de> Hi, > Recently something changed in the network at my work and now > Dnssec-Trigger bails out with "The Network Fails to Support DNSSEC". > > Dnssec-Trigger still works fine on other networks so it seems obvious > that something changed somewhere in the network at work or at my > workplaces internet supplier. > > If I am to report this as a problem I would like to supply them with a > more precise description of what they changed and how they could fix it > (otherwise the report will most likely be shelved). > > What should I look for? What is the best way to diagnose such a problem? > > The probe results contain this info: [...] I am getting similar results in my university wireless network. The problem (in my case) seems to be related to the firewall (or something) dropping large UDP/DNS packets. The following two commands fail with a timeout in that network: dig @ns.ralfj.de ralfj.de A +dnssec dig @8.8.8.8 debian.org DNSKEY +dnssec The first is a direct query to an authoritative nameserver, the second uses Google's recursive resolver. Both return replies larger than 1KiB. Kind regards Ralf From thozza at redhat.com Mon Sep 15 10:46:48 2014 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 15 Sep 2014 06:46:48 -0400 (EDT) Subject: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN In-Reply-To: References: <540750C1.5010306@ralfj.de> <54077AB4.7020104@ralfj.de> Message-ID: <1124406045.23892972.1410778008602.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On Wed, 3 Sep 2014, Ralf Jung wrote: > > > I am using OpenConnect - it not being on your list may explain the > > problem ;-) . I had hoped that there would be some general solution to > > hook into NM, that doesn't require additional work for each VPN > > provider. Is there a common infrastructure, or would I have to start > > from scratch if I wanted to add support to OpenConnect for this? > > There is a somewhat generic method, but your VPN software gets the > DNS servers via its VPN protocol, and it needs to expose this somehow > to either NM or dnssec-trigger or unbound. As Paul said, there is an integration with NM if the VPN software exposes necessary information to the NM. The information is then read using libnm API from NM by dnssec-trigger hooks. I'm not a big fan of every VPN software re-configuring unbound on its own. This is really bad approach and should not be used. We should rather use solution that is able to configure unbound every time in the same way for a particular network configuration. If multiple pieces of software reconfigure unbound dynamically we may end up with strange configuration when network configuration changes. > > So unbound needs to be explicitly supported for this use by the VPN > > providers, but dnssec-trigger can hook into that properly? After all, it > > has to re-do the probe after the VPN connection is established. > > It should not need to re-probe. If you have VPN DNS servers, you are > basically forced to use those. For the IPsec case, you also get a > domain, so unbound can be told to only use those DNS servers for that > domain. So probing it makes no sense, you need to use it anyway to get > the internal DNS view at the other end of the VPN. > > But some VPN protocols might required you send all DNS queries to them. > > Paul Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From thozza at redhat.com Mon Sep 15 10:36:21 2014 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 15 Sep 2014 06:36:21 -0400 (EDT) Subject: [Dnssec-trigger] resolv.conf options in dnssec-trigger.conf In-Reply-To: References: <4ED79DEC-6AEC-47FE-8091-0886D68F1279@iedr.ie> Message-ID: <2083326952.23892491.1410777381944.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On Wed, 3 Sep 2014, Billy Glynn wrote: > > > I was wondering if I could set resolv.conf options via dnssec-trigger.conf > > ? > > > > options timeout:1 attempts:1 rotate > > I think dnssec-trigger should read resolv.conf and copy all the > options found (of course not nameserver options, but arguably it > should include the domain/search option) Would the domain/search option be copied only when dnssec-trigger is started? On network configuration change the possibly new domain/search option would not be written into the resolv.conf (dnssec-trigger would be managing its content with immutable attribute set) and therefore the domain/search option once read by dnssec-trigger will be outdated. Therefore I think the domain/search option should be reconfigured dynamically on every network configuration change, possibly by the dispatcher script. (Or combination with static configuration from the disc ~ dnssec-trigger.conf) Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From cra at WPI.EDU Thu Sep 18 16:29:19 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 18 Sep 2014 12:29:19 -0400 Subject: [Dnssec-trigger] bugs.debian.org validation failure Message-ID: <20140918162919.GV31944@angus.ind.WPI.EDU> Why is unbound showing a validation failure when dnsviz.net shows everything is good? http://dnsviz.net/d/bugs.debian.org/dnssec/ Sep 18 12:07:34 system unbound: [2399:1] info: validation failure bugs.debian.org. AAAA IN Sep 18 12:07:34 system unbound: [2399:0] info: validation failure bugs.debian.org. AAAA IN Sep 18 12:07:34 system unbound: [2399:0] info: validation failure bugs.debian.org. A IN Sep 18 12:07:34 system unbound: [2399:1] info: validation failure bugs.debian.org. A IN Sep 18 12:08:31 system unbound: [2399:1] info: validation failure bugs.debian.org. A IN Sep 18 12:08:31 system unbound: [2399:0] info: validation failure bugs.debian.org. AAAA IN Sep 18 12:08:31 system unbound: [2399:0] info: validation failure bugs.debian.org. A IN Sep 18 12:08:31 system unbound: [2399:1] info: validation failure bugs.debian.org. AAAA IN # cat /etc/resolv.conf # Generated by dnssec-trigger 0.11 nameserver 127.0.0.1 # dnssec-trigger-control status at 2014-08-12 19:50:53 http fedoraproject.org (209.132.181.16): OK cache 130.215.5.18: OK cache 130.215.39.18: OK cache 130.215.32.18: OK state: cache secure # unbound-control status version: 1.4.21 verbosity: 1 threads: 2 modules: 2 [ validator iterator ] uptime: 8969587 seconds unbound (pid 2399) is running... # unbound-control list_forwards . IN forward: 130.215.32.18 130.215.39.18 130.215.5.18 ]# unbound-control dump_cache | grep -i debian 79LQJ175EGDS2H52Q2HC62E8KML13LQH.debian.org. 2834 IN NSEC3 1 0 16 7d27a664d4 7abafflgutp9r82vovq9fdg3pogoh393 A MX AAAA RRSIG 79LQJ175EGDS2H52Q2HC62E8KML13LQH.debian.org. 2834 IN RRSIG NSEC3 8 3 3600 20141023191027 20140913181027 35679 debian.org. BoXj6Ca3Z84dSZbJNVZXRIVN5Tik59XpRHjkGKhqjYh0lux9UlJasesVwS8nM5WrnSzx0lR/mByUx7MV7Xji1ySk1DHLJCNbgiXFCa2R6vtUK1zFDPJP1dkuGokY1AmWv6Ff4a/MnjrQrE4of6gGkOU6nDm7XU8l3CANJrDXti53YABE/CJLS/TTg+DNRt8hpYDCYrwK6bQsgppxSeWgZqPcEV2ipgY6ZpCuYaMi9VLjlnXybhTa31vzFekuXSNg debian.org. 2834 IN SOA denis.debian.org. hostmaster.debian.org. 2014352350 10800 3600 1814400 3600 debian.org. 2834 IN RRSIG SOA 8 2 3600 20141028145935 20140918135935 35679 debian.org. WXGXZPULIlAz9c55CNLc2sIs7lPXE4C71L+7/kiNUL4FasDBnGs+IXxBYYYk5JdoFI7300FwK/3Kfcx3XpalJCNYXQH9YDn7XqZWRa1tnrYH+HDZ48rfPv8G62T/VBNdojLoc2oBQc+2Q8UfjJqpcO1NLqJddMuvRLkTCBjflHe/gAH3iNR6shVPKUz10lz2QiPJC4kL1TCwnpsuitRYqE/qTSV9NMPBoU1+mRDpcb1h+v/auwbzQl0yZ4zIDKRi debian.org. 85634 IN DS 15679 8 2 9772f405c41274a78d724ea33457b0ff8850570e1d1da969b7ab1133010a9a25 debian.org. 85634 IN RRSIG DS 7 2 86400 20140930155830 20140909145830 33287 org. s1GDbVTNjs18F7kSs8klkGue8OQdgQ/QE1+MJmJQgfflKUu8NNz4q/BCVl5bST8u4z/tJu0ZV8cqd2rMoD1IahsossweRIx2swpZfyNjnMk3+m9BvklintglyITVGy8NGrltb/5PL0/FaACPmm90bXCYAEp5yJIjUhZZQWRKZ0E= debian.org. 14982 IN NS sec2.rcode0.net. debian.org. 14982 IN NS dns4.easydns.info. debian.org. 14982 IN NS dns3.easydns.org. debian.org. 14982 IN NS sec1.rcode0.net. debian.org. 14982 IN NS dns1.easydns.com. debian.org. 28034 IN DNSKEY 257 3 8 AwEAAa08/KsTdCYEdb0IZ2zgjM1Rld05vJDBxDo18Nb1cNDHkI8EZubK9vO1icw/7VnwZD0yRj0Gt2ecOa+N3IQakQirsshc1Tz2y2XX2n2cb5BCMzRea5ifPcUvHT+c4CStthNAJyu98StCIUdtprua6AWyOW9yuDGgkQGdNuk7hK5lMvItYoT85PqLDA6Tne9JrlEbUrzQ9t779yxwuZZg8XqWOi9f1Vk4P7QdQqGsmLlCNpYevwJNmE5ebk4ZHgpHYWb8gJyKX69vgzs/t0aj4dEbnMRgiQWW42jfzVblcT33+A1KkKSQz7gmzsX14/Wa/6hHyxkdeLtxl7rlpvXWjeE= ;{id = 15679 (ksk), size = 2048b} debian.org. 28034 IN DNSKEY 256 3 8 AwEAAdVJpaKPTjXZnB2cHV+fVYghzysbiJsfco9jC8xrVPRCZdkLI3oh99G9544ddxmHSSqyHmSiYzez1AI9UxdYpVI0vdLuwlX9i0xeydsWDS/zj7dBz7nvSdxg2PxKpt8aViy31RdD83gE8QPyF8Rnmfb2s4PwBfKt71s55aBD/nK055918XJwqQF9kNIxKFRaeXa4dM85erDbpHAiY00QPH98mSr8fNrwSLbrSIHNqa2hUlUfk8siEQAYl/wZj0EYjQ== ;{id = 35679 (zsk), size = 1536b} debian.org. 28034 IN RRSIG DNSKEY 8 2 28800 20141017065938 20140907061457 15679 debian.org. IQklv/jb98f82khX3uAJVmKiOciG1dApku6CvBwS7Woo7sCi/9wans7U7bQ8gWG37PZPy1ZaidZSQHFz6amZJA0hYx5meRtQRz/PoYBZrrVlH3LWVEBbhSqJ+IhSTctHBTkeOWIe1FvnWrAlV8zzeaanVukiw7QZLyVTbQA53V0BdDXjGi1Kb+rogc+DhH9B64mpEtz7zUrNYUWEHqztr26RicGJJc2s5dJXFT+MzTmk0JGdMH1HThmBF1hEHOCLDWLXmHlZAnVxsgU7FWtwG4jjYZL8spokgzajkx8At+Gl2cY+9ZWFENOz+GY5FmqELhPslegGA7sNqwQu9P5cqw== debian.org. 28034 IN RRSIG DNSKEY 8 2 28800 20141017065938 20140907061457 35679 debian.org. A+pg5GMcFmQ5mdAWXZPPoEivil/MprhjybMol0U2T5zDTyBkHeGHmiygSgRdGDgiE6GgOrdNN6k/dDQwXvPEyZRw3i13Wc0eXxxK3WJMSusrE8vUuvI3KtFDJDMOAaR961KH5PIp9iSZexY3Q2fEjvilOu/vPS3eZrVjHpoROULeU878t9EY4bG3bPYWK0YGzmwgO/xfXW5YYVXyBpvcjsj0d3G3ZJ/o10It7fa82n5OGkXOQPo8sCJgh7PmzExL msg bugs.debian.org. IN DS 33152 1 2834 0 0 2 0 debian.org. IN SOA 4 79LQJ175EGDS2H52Q2HC62E8KML13LQH.debian.org. IN NSEC3 0 msg debian.org. IN DNSKEY 33152 1 28034 0 1 0 0 debian.org. IN DNSKEY 0 msg bugs.debian.org.wpi.edu. IN A 33155 1 2835 3 0 1 0 msg bugs.debian.org.wpi.edu.dlv.isc.org. IN DLV 33155 1 2835 4 0 3 0 msg bugs.debian.org.wpi.edu. IN AAAA 33155 1 2835 3 0 1 0 msg debian.org. IN DS 33152 1 85634 0 1 0 0 debian.org. IN DS 0 [root at dustpuppy cra]# unbound-control dump_cache | grep -i debian 79LQJ175EGDS2H52Q2HC62E8KML13LQH.debian.org. 2822 IN NSEC3 1 0 16 7d27a664d4 7abafflgutp9r82vovq9fdg3pogoh393 A MX AAAA RRSIG 79LQJ175EGDS2H52Q2HC62E8KML13LQH.debian.org. 2822 IN RRSIG NSEC3 8 3 3600 20141023191027 20140913181027 35679 debian.org. BoXj6Ca3Z84dSZbJNVZXRIVN5Tik59XpRHjkGKhqjYh0lux9UlJasesVwS8nM5WrnSzx0lR/mByUx7MV7Xji1ySk1DHLJCNbgiXFCa2R6vtUK1zFDPJP1dkuGokY1AmWv6Ff4a/MnjrQrE4of6gGkOU6nDm7XU8l3CANJrDXti53YABE/CJLS/TTg+DNRt8hpYDCYrwK6bQsgppxSeWgZqPcEV2ipgY6ZpCuYaMi9VLjlnXybhTa31vzFekuXSNg debian.org. 2822 IN SOA denis.debian.org. hostmaster.debian.org. 2014352350 10800 3600 1814400 3600 debian.org. 2822 IN RRSIG SOA 8 2 3600 20141028145935 20140918135935 35679 debian.org. WXGXZPULIlAz9c55CNLc2sIs7lPXE4C71L+7/kiNUL4FasDBnGs+IXxBYYYk5JdoFI7300FwK/ From paul at nohats.ca Thu Sep 18 17:32:20 2014 From: paul at nohats.ca (Paul Wouters) Date: Thu, 18 Sep 2014 13:32:20 -0400 (EDT) Subject: [Dnssec-trigger] bugs.debian.org validation failure In-Reply-To: <20140918162919.GV31944@angus.ind.WPI.EDU> References: <20140918162919.GV31944@angus.ind.WPI.EDU> Message-ID: On Thu, 18 Sep 2014, Chuck Anderson wrote: > Why is unbound showing a validation failure when dnsviz.net shows everything is good? dnsviz.net is not using the resolvers/forwarders you are using? > Sep 18 12:07:34 system unbound: [2399:1] info: validation failure bugs.debian.org. AAAA IN > # unbound-control list_forwards > . IN forward: 130.215.32.18 130.215.39.18 130.215.5.18 Try not using those forwards? eg: unbound-control reload unbound-control forward_add . 8.8.8.8 Then try again? If that works, go back to the original forwarders and see if the problem returns. If so, possibly crank up the verbosity: in unbound.conf so you get more information about why it failed validation. Paul From cra at WPI.EDU Thu Sep 18 19:35:30 2014 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 18 Sep 2014 15:35:30 -0400 Subject: [Dnssec-trigger] bugs.debian.org validation failure In-Reply-To: References: <20140918162919.GV31944@angus.ind.WPI.EDU> Message-ID: <20140918193528.GW31944@angus.ind.WPI.EDU> On Thu, Sep 18, 2014 at 01:32:20PM -0400, Paul Wouters wrote: > On Thu, 18 Sep 2014, Chuck Anderson wrote: > > >Why is unbound showing a validation failure when dnsviz.net shows everything is good? > > dnsviz.net is not using the resolvers/forwarders you are using? > > >Sep 18 12:07:34 system unbound: [2399:1] info: validation failure bugs.debian.org. AAAA IN > > ># unbound-control list_forwards > >. IN forward: 130.215.32.18 130.215.39.18 130.215.5.18 > > Try not using those forwards? eg: I'm fairly certain the forwarders aren't the problem since I run those as well. They are standard BIND 9 installs running full recursion with no firewall on the DNS traffic, but they don't have DNSSEC validation turned on yet. > unbound-control reload > unbound-control forward_add . 8.8.8.8 > > Then try again? If that works, go back to the original forwarders and > see if the problem returns. If so, possibly crank up the verbosity: in > unbound.conf so you get more information about why it failed validation. Too late to check--it is working now with the same forwards. So this was a transient issue. # host bugs.debian.org bugs.debian.org has address 140.211.166.26 bugs.debian.org has address 206.12.19.140 bugs.debian.org has IPv6 address 2607:f8f0:610:4000:6564:a62:ce0c:138c bugs.debian.org mail is handled by 10 buxtehude.debian.org. I have very few issues with unbound/DNSSEC, so I'm not sure what to do for troubleshooting when a problem does happen. What verbosity level do you suggest? I'll have to leave it cranked up so I'll have the data if/when this happens again. From wouter at nlnetlabs.nl Fri Sep 19 07:06:52 2014 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Fri, 19 Sep 2014 09:06:52 +0200 Subject: [Dnssec-trigger] bugs.debian.org validation failure In-Reply-To: <20140918193528.GW31944@angus.ind.WPI.EDU> References: <20140918162919.GV31944@angus.ind.WPI.EDU> <20140918193528.GW31944@angus.ind.WPI.EDU> Message-ID: <541BD60C.1060408@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chuck, On 09/18/2014 09:35 PM, Chuck Anderson wrote: > On Thu, Sep 18, 2014 at 01:32:20PM -0400, Paul Wouters wrote: >> On Thu, 18 Sep 2014, Chuck Anderson wrote: >> >>> Why is unbound showing a validation failure when dnsviz.net >>> shows everything is good? >> >> dnsviz.net is not using the resolvers/forwarders you are using? >> >>> Sep 18 12:07:34 system unbound: [2399:1] info: validation >>> failure bugs.debian.org. AAAA IN >> >>> # unbound-control list_forwards . IN forward: 130.215.32.18 >>> 130.215.39.18 130.215.5.18 >> >> Try not using those forwards? eg: > > I'm fairly certain the forwarders aren't the problem since I run > those as well. They are standard BIND 9 installs running full > recursion with no firewall on the DNS traffic, but they don't have > DNSSEC validation turned on yet. > >> unbound-control reload unbound-control forward_add . 8.8.8.8 >> >> Then try again? If that works, go back to the original forwarders >> and see if the problem returns. If so, possibly crank up the >> verbosity: in unbound.conf so you get more information about why >> it failed validation. > > Too late to check--it is working now with the same forwards. So > this was a transient issue. > > # host bugs.debian.org bugs.debian.org has address 140.211.166.26 > bugs.debian.org has address 206.12.19.140 bugs.debian.org has IPv6 > address 2607:f8f0:610:4000:6564:a62:ce0c:138c bugs.debian.org mail > is handled by 10 buxtehude.debian.org. > > I have very few issues with unbound/DNSSEC, so I'm not sure what to > do for troubleshooting when a problem does happen. What verbosity > level do you suggest? I'll have to leave it cranked up so I'll > have the data if/when this happens again. val-log-level: 2 this prints a descriptive string into the log file, about why the validation failure happened, ie. "validation failure name type class: no RRSIG records from server 192.0.2.1". Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUG9YMAAoJEJ9vHC1+BF+NU+wP+gMDERwt0V7ZzltKm1Dhul1y eoYR1ieOP5zfZBwmyLYv8BxauyD46CJJWo0/1Qa4lygA7oxfkFHAwImN7v6HMsiY RnnzEz/byDWCmbS1c5vEBrRBOJwnwc792tFCENwniC34UmdwDGcVdup05iw9HDi8 rf3hq5MZ7OMgeZSmKTj15GJuRbW4SrRNhI5Xmiobs8kGyRzhdOQJcunlGVC8jPXp ObtyyMNCFqSUe1vRS6D0PVkYXSGnqczSZ+sqVMz7wC8L7IHsizFPqpFHamNVYN1f BdHjiFs7TeCmWLB3J5zNULRpS1a3aUIM29jQs3CeJ/7m0gvagnlZ8gfBNmL8N1DW VuNEKLQQ4fDYVlpSR5zUTkcGAcovCpQ8sN8KMqO2BLRP9py9DDL93I6h1D1WvXRU hyq21N0Cs1XJrk8RLq/MgI/AljnRSwCkbg+PhkERlS04MwHKy+Ir4iY+6lu+CAWN 2hFQu60ffxV/qzGygS8vCRTYFSLcMfJXnCRG6Q4jNhwuVk2xSALxbZB1bwUST/vY HzINE3cj+Uwvok7VF+V4jlVXHZygFZVBn9e3/jLvHGctiFlxTre9t+R+gqt1OUdg VO0vFuXHl4VCBlVdG3JNa7b/DCDLiTntIsOekQRWxDq6g3HS1NyDGmJ7fChQsHmH EkRTiWgb3fOHPDwnTHOx =kNLd -----END PGP SIGNATURE----- From post at ralfj.de Sun Sep 21 10:06:31 2014 From: post at ralfj.de (Ralf Jung) Date: Sun, 21 Sep 2014 12:06:31 +0200 Subject: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN In-Reply-To: <1124406045.23892972.1410778008602.JavaMail.zimbra@redhat.com> References: <540750C1.5010306@ralfj.de> <54077AB4.7020104@ralfj.de> <1124406045.23892972.1410778008602.JavaMail.zimbra@redhat.com> Message-ID: <541EA327.2090401@ralfj.de> Hi, > As Paul said, there is an integration with NM if the VPN software exposes > necessary information to the NM. The information is then read using libnm > API from NM by dnssec-trigger hooks. > > I'm not a big fan of every VPN software re-configuring unbound on its > own. This is really bad approach and should not be used. Without knowing the technical details, I completely agree. It sounds like a bad hack. Do you have an example for a VPN plugin that uses the "right" way to expose information to NM? That would be a good starter to get this into OpenConnect. Kind regards Ralf From psimerda at redhat.com Sun Sep 21 12:19:29 2014 From: psimerda at redhat.com (Pavel Simerda) Date: Sun, 21 Sep 2014 08:19:29 -0400 (EDT) Subject: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN In-Reply-To: <541EA327.2090401@ralfj.de> References: <540750C1.5010306@ralfj.de> <54077AB4.7020104@ralfj.de> <1124406045.23892972.1410778008602.JavaMail.zimbra@redhat.com> <541EA327.2090401@ralfj.de> Message-ID: <1972491311.25784568.1411301969484.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Ralf Jung" > To: "Tomas Hozza" , "Paul Wouters" > Cc: dnssec-trigger at NLnetLabs.nl, "Pavel Simerda" > Sent: Sunday, September 21, 2014 12:06:31 PM > Subject: Re: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN > > Hi, > > > As Paul said, there is an integration with NM if the VPN software exposes > > necessary information to the NM. The information is then read using libnm > > API from NM by dnssec-trigger hooks. > > > > I'm not a big fan of every VPN software re-configuring unbound on its > > own. This is really bad approach and should not be used. > > Without knowing the technical details, I completely agree. It sounds > like a bad hack. > > Do you have an example for a VPN plugin that uses the "right" way to > expose information to NM? That would be a good starter to get this into > OpenConnect. There's https://git.gnome.org/browse/network-manager-openconnect/ Pavel > Kind regards > Ralf > From post at ralfj.de Sun Sep 21 12:56:08 2014 From: post at ralfj.de (Ralf Jung) Date: Sun, 21 Sep 2014 14:56:08 +0200 Subject: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN In-Reply-To: <1972491311.25784568.1411301969484.JavaMail.zimbra@redhat.com> References: <540750C1.5010306@ralfj.de> <54077AB4.7020104@ralfj.de> <1124406045.23892972.1410778008602.JavaMail.zimbra@redhat.com> <541EA327.2090401@ralfj.de> <1972491311.25784568.1411301969484.JavaMail.zimbra@redhat.com> Message-ID: <541ECAE8.1060904@ralfj.de> Hi, >> Do you have an example for a VPN plugin that uses the "right" way to >> expose information to NM? That would be a good starter to get this into >> OpenConnect. > > There's https://git.gnome.org/browse/network-manager-openconnect/ Well, yes, that's what I am using. It shows the behaviour that I described (DNS servers are not properly forwarded to dnssec-trigger). I thought you said that this plugin needs patching to fix this forwarding? Kind regards Ralf From psimerda at redhat.com Sun Sep 21 15:25:14 2014 From: psimerda at redhat.com (Pavel Simerda) Date: Sun, 21 Sep 2014 11:25:14 -0400 (EDT) Subject: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN In-Reply-To: <541ECAE8.1060904@ralfj.de> References: <540750C1.5010306@ralfj.de> <54077AB4.7020104@ralfj.de> <1124406045.23892972.1410778008602.JavaMail.zimbra@redhat.com> <541EA327.2090401@ralfj.de> <1972491311.25784568.1411301969484.JavaMail.zimbra@redhat.com> <541ECAE8.1060904@ralfj.de> Message-ID: <1032598716.25793299.1411313114481.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Ralf Jung" > To: "Pavel Simerda" > Cc: "Tomas Hozza" , "Paul Wouters" , dnssec-trigger at NLnetLabs.nl > Sent: Sunday, September 21, 2014 2:56:08 PM > Subject: Re: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN > > Hi, > > >> Do you have an example for a VPN plugin that uses the "right" way to > >> expose information to NM? That would be a good starter to get this into > >> OpenConnect. > > > > There's https://git.gnome.org/browse/network-manager-openconnect/ > > Well, yes, that's what I am using. It shows the behaviour that I > described (DNS servers are not properly forwarded to dnssec-trigger). I > thought you said that this plugin needs patching to fix this forwarding? Hi, I'm sorry, I didn't follow the discussion carefully. We (more specificaly I and Tom??) are working on the dnssec-trigger hooks for NetworkManager. You're apparently using an older/different version so the behavior may be much different from what we are already testing. Basically the VPN is expected to give away information to NetworkManager and we're getting the information from NetworkManager and setting up unbound accordingly. Depending on the configuration of NM, the VPN name servers or the physical connection name servers are used globally, and the VPN name servers are being used for known domains for the VPN. I'm not using the openconnect plugin myself. It might be better if you find me (pavlix) on IRC Freenode (for example in #nm) and we can discuss it in more detail. Cheers, Pavel > > Kind regards > Ralf > From post at ralfj.de Mon Sep 22 14:30:21 2014 From: post at ralfj.de (Ralf Jung) Date: Mon, 22 Sep 2014 16:30:21 +0200 Subject: [Dnssec-trigger] [Bug] incorrect DNS servers are used when network-manager connects to VPN In-Reply-To: <1032598716.25793299.1411313114481.JavaMail.zimbra@redhat.com> References: <540750C1.5010306@ralfj.de> <54077AB4.7020104@ralfj.de> <1124406045.23892972.1410778008602.JavaMail.zimbra@redhat.com> <541EA327.2090401@ralfj.de> <1972491311.25784568.1411301969484.JavaMail.zimbra@redhat.com> <541ECAE8.1060904@ralfj.de> <1032598716.25793299.1411313114481.JavaMail.zimbra@redhat.com> Message-ID: <5420327D.3000204@ralfj.de> Hi, > It might be better if you find me (pavlix) on IRC Freenode (for example in #nm) and we can discuss it in more detail. With the help of Pavel, we were able to track down the issue: It's essentially . The shell-based NM "fallback" hook does not to the VPN setup properly, and the newer script was not called due to a wrong path. Kind regards Ralf