From wouter at NLnetLabs.nl Mon Jan 2 08:44:50 2012 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Mon, 02 Jan 2012 09:44:50 +0100 Subject: [Dnssec-trigger] DNSSEC trigger and v6 DNS servers In-Reply-To: References: <20111224114927.d742899c.nlnetlabs@belanger.fr> Message-ID: <4F016E82.8080006@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Stephan, On 12/28/2011 04:58 PM, Stephan Lagerholm wrote: > Hi, > > I can still access www.trasigdnssec.se (a deliberately DNSSEC > broken domain) with DNSSEC trigger 0.9 installed and running on my > windows 7 laptop when using v6 capable applications such as > firefox. > > ----------------------------------------------- The probe results > are: results from probe at 2011-12-28 09:26:37 > > cache 64.92.220.220: OK cache 208.67.222.222: error no RRSIGs in > reply > > DNSSEC results fetched from (DHCP) cache(s) > > --------------------------------------------- > > What appears to happen is the firefox/IE is sending queries to the > IPv6 DNS server 2001:5c0:1000:11::2 that I got provisioned via > DHCPv6. Shouldn't dnssec-trigger rewrite both the 'resolv.conf' for > IPv4 and IPv6 and start a local unbound on both ::1 and 127.0.0.1? Unbound is on ::1, but there is no resolv.conf on windows7, it writes into the registry. There must be an additional entry to overwrite with tthe DHCPv6 results. I would like you to search your registry for that DNS server (as a string), it should give you a hit in HKEY_LOCAL_MACHINE (abbrev to HKLM): SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\ [A bit of context: on 30th december 2011, the French governement published the decree mandating DNS - yes, DNS is explicitely the technque to use - filtering of online gambling sites. The problem may also happen with the US project SOPA and many others.] Today, dnssec-trigger considers the network-supplied name servers as suitable if they transmit DNSSEC information (EDNS0, RRSIG, NSEC and NSEC3, etc). It means that lying resolvers may be selected as forwarders but will raise DNSSEC validation errors for some domains (the censored ones). Currently, the only workaround is to disable dnssec-trigger and to use Unbound without forwarders. Which is bad (no more shared cache) for the vast majority of domains where the network-supplied name servers are OK. I suggest the following algorithm: if DNSSEC validation error *and* forwarders are in use, disable the forwarders for the current domain. I assume it will require cooperation from Unbound. Does it seem sensible? From owens at nysernet.org Mon Jan 2 22:55:52 2012 From: owens at nysernet.org (Bill Owens) Date: Mon, 2 Jan 2012 17:55:52 -0500 Subject: [Dnssec-trigger] Using dnssec-trigger when the forwarder lies In-Reply-To: <20120102214931.GA2782@sources.org> References: <20120102214931.GA2782@sources.org> Message-ID: <20120102225552.GC70180@nysernet.org> On Mon, Jan 02, 2012 at 10:49:31PM +0100, Stephane Bortzmeyer wrote: > [A bit of context: on 30th december 2011, the French governement > published the decree mandating DNS - yes, DNS is explicitely the > technque to use - filtering of online gambling sites. The problem may > also happen with the US project SOPA and many others.] Just curious, and I can't seem to find anything specific about this measure - does the decree have anything to say about circumvention measures? Such as, for example, software that automatically switches nameservers in order to avoid the blocking? ;) Bill. From owens at nysernet.org Mon Jan 2 23:40:42 2012 From: owens at nysernet.org (Bill Owens) Date: Mon, 2 Jan 2012 18:40:42 -0500 Subject: [Dnssec-trigger] Using dnssec-trigger when the forwarder lies In-Reply-To: <20120102225552.GC70180@nysernet.org> References: <20120102214931.GA2782@sources.org> <20120102225552.GC70180@nysernet.org> Message-ID: <20120102234042.GE70180@nysernet.org> On Mon, Jan 02, 2012 at 05:55:52PM -0500, Bill Owens wrote: > On Mon, Jan 02, 2012 at 10:49:31PM +0100, Stephane Bortzmeyer wrote: > > [A bit of context: on 30th december 2011, the French governement > > published the decree mandating DNS - yes, DNS is explicitely the > > technque to use - filtering of online gambling sites. The problem may > > also happen with the US project SOPA and many others.] > > Just curious, and I can't seem to find anything specific about this measure - does the decree have anything to say about circumvention measures? Such as, for example, software that automatically switches nameservers in order to avoid the blocking? ;) Aha, of course you'd already blogged about it and tweeted the link, but since I am very limited in my language skills I had not noticed. Google Translate to the rescue (and there's nothing about circumvention, at least in the version I found/translated). BIll. From wouter at NLnetLabs.nl Tue Jan 3 08:56:15 2012 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Tue, 03 Jan 2012 09:56:15 +0100 Subject: [Dnssec-trigger] Using dnssec-trigger when the forwarder lies In-Reply-To: <20120102234042.GE70180@nysernet.org> References: <20120102214931.GA2782@sources.org> <20120102225552.GC70180@nysernet.org> <20120102234042.GE70180@nysernet.org> Message-ID: <4F02C2AF.4020304@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The mission of dnssec-trigger is DNSSEC. Circumvention of (ill-conceived perhaps) laws is not the goal. This sort of thing goes on to require full VPN style solutions, if the conflict becomes serious, also dnssec-trigger is not a VPN by all means. The fact it can circumvent accidentally (i.e. DNSSEC support not detected in filter-device, but alternative has no filter) is a failure of the filtering party to conform to standards. As much as I dislike censorship, this tool is to provide DNSSEC, not censor-free-VPN. DNSSEC will detect and stop tampering, as you note. Such a circumvention tool is perhaps better suited as a different piece of add-on software? It would help, also with classification in software repositories, and this may help uptake of DNSSEC by distributions. Best regards, Wouter On 01/03/2012 12:40 AM, Bill Owens wrote: > On Mon, Jan 02, 2012 at 05:55:52PM -0500, Bill Owens wrote: >> On Mon, Jan 02, 2012 at 10:49:31PM +0100, Stephane Bortzmeyer >> wrote: >>> [A bit of context: on 30th december 2011, the French >>> governement published the decree mandating DNS - yes, DNS is >>> explicitely the technque to use - filtering of online gambling >>> sites. The problem may also happen with the US project SOPA and >>> many others.] >> >> Just curious, and I can't seem to find anything specific about >> this measure - does the decree have anything to say about >> circumvention measures? Such as, for example, software that >> automatically switches nameservers in order to avoid the >> blocking? ;) > > Aha, of course you'd already blogged about it and tweeted the link, > but since I am very limited in my language skills I had not > noticed. Google Translate to the rescue (and there's nothing about > circumvention, at least in the version I found/translated). > > BIll. _______________________________________________ > dnssec-trigger mailing list dnssec-trigger at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPAsKuAAoJEJ9vHC1+BF+N4f0QAJZb8CqrMQKM/sd/1pneOlj3 AwFFG7OmTNw/KihqQ0yjvz4LqKB/0goenntbjeLDFKB0MqC4RhIhZM7zqzmYvn2u a1365ImYfuDONcxbATKtDENLxm/EQW9+gF18RqVqKHnk4nzlpr3f6F8csh1tdWZP LtW9zkP0Ak1bPG/JnvJRo19I/Nr0VFPHlZ4YN6EdvOzLc6uG2bK3YiTRtYD897AG WACi/iHrhRTB6ZsDdlcsa6KECXOBPLKlp08g71crP+uq1DBlYtuPWGoiwelUItZr V2tIk/b0lXXVrG0BAaN1Kqz/mTvVjAVkAHXKo2/gLF7iHq0PmMG6l7xje800hQb+ Hz9X48hyXQb9B/E9n4KYHXekj/UAAasVXyyYZOhiEvdva1bJqm2aRR2M3RSIWEqv rDYP7HgAet/DEcpJiaMsQTJ0wXwzbAXHAdv2nt+P3sYh7L5xSHbnTnQIN0AIUgeT N1yXn0zCDkrpaCfSVR2kOErMUX8hY+2ACxm5cIBvrYBYLYZAudu+dsbOgxsakf0x AJhQ6kiEqQ8lLsq0AXXQtB/P6NL/BRalJzvRJRqHELpjBd7BlfNj30Nkwz2Hmxur mn0ACOqAAniYS+ibEELOlwNboBuNLM26EcNN9cPDB1lKeUmot0ia75uyRb/ksfhB XoZ6EloghMHuenkxOE4k =T6ZN -----END PGP SIGNATURE----- From regnauld at nsrc.org Tue Jan 3 10:56:32 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 3 Jan 2012 11:56:32 +0100 Subject: [Dnssec-trigger] Using dnssec-trigger when the forwarder lies In-Reply-To: <4F02C2AF.4020304@nlnetlabs.nl> References: <20120102214931.GA2782@sources.org> <20120102225552.GC70180@nysernet.org> <20120102234042.GE70180@nysernet.org> <4F02C2AF.4020304@nlnetlabs.nl> Message-ID: On 03/01/2012, at 09.56, "W.C.A. Wijngaards" wrote: > As much as I dislike censorship, this tool is to provide DNSSEC, not > censor-free-VPN. DNSSEC will detect and stop tampering, as you note. Isn't this type of hop by hop censorship (cf Paul Vixie's article yesterday) technically a subset of the case "broken and untrustworthy resolver" ? DNSSEC trigger shouldn't have to make - or care - about the difference. Or at least it could say "oh looks like someone is voluntarily tampering with the results, get a VPN" Phil From jaap at NLnetLabs.nl Tue Jan 3 11:18:53 2012 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Tue, 03 Jan 2012 12:18:53 +0100 Subject: [Dnssec-trigger] Using dnssec-trigger when the forwarder lies In-Reply-To: References: <20120102214931.GA2782@sources.org> <20120102225552.GC70180@nysernet.org> <20120102234042.GE70180@nysernet.org> <4F02C2AF.4020304@nlnetlabs.nl> Message-ID: <201201031118.q03BIrj7094287@bartok.nlnetlabs.nl> DNSSEC trigger shouldn't have to make - or care - about the difference. It doesn't. Or at least it could say "oh looks like someone is voluntarily tampering with the results, get a VPN" It can only find out whether DNSSEC works or not and in the last case, it warns that the DNS lookup is not secured by DNSSEC. There is no way for dnssec-trigger to find out why it cannot validate the dns lookup and so, how the user can remedy the situation. Tat has also never been the goal. As Wouter already has said: "The mission of dnssec-trigger is DNSSEC". jaap From regnauld at nsrc.org Tue Jan 3 14:01:06 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 3 Jan 2012 15:01:06 +0100 Subject: [Dnssec-trigger] OS X, resolv.conf Message-ID: <20120103140106.GB1072@macbook.bluepipe.net> I have an interesting buglet: right now, if I enable dnssec-trigger, it installs the following /etc/resolv.conf: # Generated by dnssec-trigger 0.9 domain xyz.fr nameserver 127.0.0.1 ... where xyz.fr is the domain returned by the DHCP server of a french network I was over a month ago. While on that network, I had installed 0.8. I have tried to uninstall 0.8, reinstall, and since have installed 0.9, but to no avail: I can go into the DNS settings in the System Preferences, remove xyz.fr (it shows up as manually added), and I can then see the usual two domains I normally have in the search list from my office DHCP. But if I stop/start dnssec-trigger, xyz.fr is back in /etc/resolv.conf... Questions: where does dnssec-trigger pick this up from, and how to reset it ? Cheers, Phil From wouter at NLnetLabs.nl Tue Jan 3 14:19:17 2012 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Tue, 03 Jan 2012 15:19:17 +0100 Subject: [Dnssec-trigger] OS X, resolv.conf In-Reply-To: <20120103140106.GB1072@macbook.bluepipe.net> References: <20120103140106.GB1072@macbook.bluepipe.net> Message-ID: <4F030E65.9030603@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Phil, On 01/03/2012 03:01 PM, Phil Regnauld wrote: > I have an interesting buglet: right now, if I enable dnssec-trigger, > it installs the following /etc/resolv.conf: > > # Generated by dnssec-trigger 0.9 > domain xyz.fr > nameserver 127.0.0.1 > > ... where xyz.fr is the domain returned by the DHCP server of a french network > I was over a month ago. While on that network, I had installed 0.8. I have > tried to uninstall 0.8, reinstall, and since have installed 0.9, but to no > avail: I can go into the DNS settings in the System Preferences, remove xyz.fr > (it shows up as manually added), and I can then see the usual two domains I > normally have in the search list from my office DHCP. It picked it out of DHCP when you first installed dnssec-trigger. Then it kept the setting when you upgraded. If you uninstall it leaves the config file behind in case you do not want to lose it, and on reinstall keeps this setting ... > But if I stop/start dnssec-trigger, xyz.fr is back in /etc/resolv.conf... > > Questions: where does dnssec-trigger pick this up from, and how to reset it ? edit: /etc/dnssec-trigger/dnssec-trigger.conf with eg: sudo vi /etc/dnssec-trigger/dnssec-trigger.conf or use another editor that you like. And change xyz.fr or put a commentsign (#) at the start of that line. The config file is documented, so it should be (relatively) obvious. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPAw5lAAoJEJ9vHC1+BF+N6BkP/i59FySkM1szhDdJJSNPc9Ui l1mZLf+/IMPuefeqLgBCNWNt1m8KLw9FtqiEbPZ5LFRblANtnen60TPL65e3dczM aqJzDKhJ1S2t0p7H8C6y688lanJ72sFuOkvMF97QnPCRxO5osG52NIfSSNkWe72x UP7/5cSPEturIsWM5lILvDPp+DJ4MEY69JTCHVMJjpdJPEsTLLz2B51T6ZmksKGm lE8HmVbsg+dVNIqKy8CKpjiMRtcX1GaGkn28hXAcv9Ugv25ZCY72z9CqmjuLZ151 D/TIuRKknIU/8770XU9b1ZAjMvijY2qikQdX2WyEI1AbWC9d2skEQCsz1hAb2TvW qQ9qp7Qo5YVN0hEDqj034eFoX69tZVZ8gp/rLZnAqC68n9v/dzbhlFwNn+XDv2U/ 0/rgvU/e8zh5hFqfOaF5kMlYs/Wzb27wo0exc2qUh04OPM5RxgcL4dNEStODTaNo QLK9eQAxEDIWu1/TlSfSWrrrjdSQ9rn+NMGDRjtW0TrsBXFB1F+UP9vXJ2IxjrB0 bqjwubW4aYJy5VrrHdQj4NeXnishQg9JXZzivjdeEI14MaAA5InpWMZv/+KqydUI /PXjoczcJ0Gzx/Hhm4fdNvmgA1XPzEzeP9FUgYMoium//vlivhsYPTP+2MAv9QZh HmAu7U5y5MVSGx9EktOZ =fLLr -----END PGP SIGNATURE----- From stephan.lagerholm at secure64.com Tue Jan 3 14:25:50 2012 From: stephan.lagerholm at secure64.com (Stephan Lagerholm) Date: Tue, 3 Jan 2012 07:25:50 -0700 Subject: [Dnssec-trigger] DNSSEC trigger and v6 DNS servers In-Reply-To: <4F016E82.8080006@nlnetlabs.nl> References: <20111224114927.d742899c.nlnetlabs@belanger.fr> <4F016E82.8080006@nlnetlabs.nl> Message-ID: Hi Wouter, > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Stephan, > > On 12/28/2011 04:58 PM, Stephan Lagerholm wrote: > > Hi, > > > > I can still access www.trasigdnssec.se (a deliberately DNSSEC > > broken domain) with DNSSEC trigger 0.9 installed and running on my > > windows 7 laptop when using v6 capable applications such as > > firefox. > > > > ----------------------------------------------- The probe results > > are: results from probe at 2011-12-28 09:26:37 > > > > cache 64.92.220.220: OK cache 208.67.222.222: error no RRSIGs in > > reply > > > > DNSSEC results fetched from (DHCP) cache(s) > > > > --------------------------------------------- > > > > What appears to happen is the firefox/IE is sending queries to the > > IPv6 DNS server 2001:5c0:1000:11::2 that I got provisioned via > > DHCPv6. Shouldn't dnssec-trigger rewrite both the 'resolv.conf' for > > IPv4 and IPv6 and start a local unbound on both ::1 and 127.0.0.1? > > Unbound is on ::1, but there is no resolv.conf on windows7, it writes > into the registry. There must be an additional entry to overwrite > with tthe DHCPv6 results. I would like you to search your registry > for that DNS server (as a string), it should give you a hit in > HKEY_LOCAL_MACHINE (abbrev to HKLM): > SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\ > What is the entire contents of that 'folder' in the registry? I mean > DNS related, such as 'Nameserver' or 'DNS' in the name? Now, it sets > the 'Nameserver' entry to 127.0.0.1. There is also a TCPIP6 folder: SYSTEM\CurrentControlSet\services\Tcpip6\Parameters\Interfaces\ I will send you a screenshot in a separate email. /S -------------- next part -------------- An HTML attachment was scrubbed... URL: From wouter at NLnetLabs.nl Tue Jan 3 14:28:58 2012 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Tue, 03 Jan 2012 15:28:58 +0100 Subject: [Dnssec-trigger] DNSSEC trigger and v6 DNS servers In-Reply-To: References: <20111224114927.d742899c.nlnetlabs@belanger.fr> <4F016E82.8080006@nlnetlabs.nl> Message-ID: <4F0310AA.4010609@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Stephan, On 01/03/2012 03:25 PM, Stephan Lagerholm wrote: >> with tthe DHCPv6 results. I would like you to search your registry > >> for that DNS server (as a string), it should give you a hit in > >> HKEY_LOCAL_MACHINE (abbrev to HKLM): > >> SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\ >> > >> What is the entire contents of that 'folder' in the registry? I mean > >> DNS related, such as 'Nameserver' or 'DNS' in the name? Now, it sets > >> the 'Nameserver' entry to 127.0.0.1. > > > > There is also a TCPIP6 folder: > > SYSTEM\CurrentControlSet\services\Tcpip6\Parameters\Interfaces\ > > > > I will send you a screenshot in a separate email. Thanks! I should be able to make something that (might) work with that. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPAxCqAAoJEJ9vHC1+BF+NXKMP/ilfM8WGDk9DBc0z1Ui1Tm80 oCrSa4D/va2C/Uq6hDDuWdvD2btkOXuQ+OHQUXv6Lfyh5/xk2+vQNIXzwKEO6a53 KiAjrGoLD6ydBvuTA3X+ZAWfQQRdqfwsRAUELF9t9qbp7TDl21SMoNWO1Ceh0oAd VDtWzZ3CfyY0rtn1g+eEv13TqNt6mXVUWzK2M9rRxULHNuwNic6ZJgdpfarSGiBL syP+pzDVBAV0W3/6uAt7mnqxPb86vqs+wn48ZuecZPhZbMgUN0GhCv+VaTeIZhs2 wFL2014SvEcDf9DkNUTXke71zRI7y88qyFOEIpLy8hQOD7j/PTZD9EhJa7Hu8udF jj0IzsNiuQM5CxvblZde1dsBPl8gp5jQjnQMUmSrftNgbmlCOSHxd3e0+DfjRp8n aS5cejNeG8QuAHr2jr98tv6v9royiydb3b6p367gzXaJRBN79JYW1EBF88nwawAt /NBC5BigvQUhh/vKoWZXgkQbVCM3wvqprGaev8G8u0UrEYu5aOVpD6rBw8XKCooX YXl/Rgboc8cc+mM1G8cu8qmalqG5g1mgzJa49e4bfsR6YTTSl31wARKELk3R1ors YtVm1bCpUSD7oqo1S3CC2lGVWkf06uynUXGy1B6ATzVVV3HHfBAz9YG5USyfVg6n hKYT663NI7OQexqYEp9W =o9w5 -----END PGP SIGNATURE----- From regnauld at nsrc.org Tue Jan 3 14:36:32 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 3 Jan 2012 15:36:32 +0100 Subject: [Dnssec-trigger] OS X, resolv.conf In-Reply-To: <4F030E65.9030603@nlnetlabs.nl> References: <20120103140106.GB1072@macbook.bluepipe.net> <4F030E65.9030603@nlnetlabs.nl> Message-ID: <20120103143632.GD1072@macbook.bluepipe.net> W.C.A. Wijngaards (wouter) writes: > with eg: > sudo vi /etc/dnssec-trigger/dnssec-trigger.conf > or use another editor that you like. > > And change xyz.fr or put a commentsign (#) at the start of that line. > > The config file is documented, so it should be (relatively) obvious. Right, I've played around with it, and commented out the domain: and search: parameters. Now, dns settings show "nothing.invalid" as the search suffix. I see the comment: # the search path from DHCP is not picked up, it could be used to misdirect. Is there a way to override this behaviour ? That's a policy decision. Cheers, Phil From wouter at NLnetLabs.nl Tue Jan 3 15:04:09 2012 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Tue, 03 Jan 2012 16:04:09 +0100 Subject: [Dnssec-trigger] OS X, resolv.conf In-Reply-To: <20120103143632.GD1072@macbook.bluepipe.net> References: <20120103140106.GB1072@macbook.bluepipe.net> <4F030E65.9030603@nlnetlabs.nl> <20120103143632.GD1072@macbook.bluepipe.net> Message-ID: <4F0318E9.1040507@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Phil, On 01/03/2012 03:36 PM, Phil Regnauld wrote: > W.C.A. Wijngaards (wouter) writes: >> with eg: >> sudo vi /etc/dnssec-trigger/dnssec-trigger.conf >> or use another editor that you like. >> >> And change xyz.fr or put a commentsign (#) at the start of that line. >> >> The config file is documented, so it should be (relatively) obvious. > > Right, I've played around with it, and commented out the domain: and > search: parameters. > > Now, dns settings show "nothing.invalid" as the search suffix. > > I see the comment: > > # the search path from DHCP is not picked up, it could be used to misdirect. > > Is there a way to override this behaviour ? That's a policy decision. There is no way to override this behaviour (at this time), and it would be somewhat difficult to make portable. If you need a couple you use you can put the search path into the config file manually, at this time. This is why I pick it up on install, e.g. if you install at home/work you get the 'right' DHCP searchpath all the time. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPAxjoAAoJEJ9vHC1+BF+NWkYP/0NlnTyNwk7ZDfGh9jKnWlF7 IzP+wwIRHMdqytWSpGhXNuMxHy2nJ5+gmfEWnwAlD0QJnatrSEmZxW9+JKID5X6l 0QhD90e1RBG5mkgUxGnEBxCLaS86RnV9gnye3R9MQUVLo7R7PzaTBxAI7ADwn8RG /f3k7n+ouZJZDu7/ZusrlqfoQCjGO6wFKp9a7Mf26IJ6oE1umhPkZMk5QM4wfuti 9K+Ho6lvcIW3n20IYwFtSUdv4sgE7i500c7neuNGMYyf1Atv8RIMIRpvotIn15TW 7dzw7nzWK9Yodfhs571J+DXtZSNMAn+hLcAvs3pntkfkNw3ga4oFApys8kNS3xsQ 5fKSBsyzx2T28Odyom9rnqyWysljNgjTeabR157PTI2YAWgViaEF0wpAmKj7JLaw UdhgwvQ7tFHla1qBMn5zwQanzc+XsOpOROuVULYdm1isrTazJndGI1NgfZFtJ/xW JGcMYkXnRzw6gQTGQOHufbor46qIurBQhgzWpu+B4TqMfy99W0Gk0zSgDR+H6ait SpjFKunKOcB5yrnOOwTkYbvlyy1BxWPjdS38vIx0xxxT7Q81NCcVz317izYDL9HS gPjtruX1ZTyQ0I8jjcFFDEcX2vg9+yUKLkfjqsRDI7LmY8N5n4HmTq+OTG//vo6f LO63Cgz2f7wK1ffD8NLA =ItQ2 -----END PGP SIGNATURE----- From regnauld at nsrc.org Tue Jan 3 15:26:22 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 3 Jan 2012 16:26:22 +0100 Subject: [Dnssec-trigger] OS X, resolv.conf In-Reply-To: <4F0318E9.1040507@nlnetlabs.nl> References: <20120103140106.GB1072@macbook.bluepipe.net> <4F030E65.9030603@nlnetlabs.nl> <20120103143632.GD1072@macbook.bluepipe.net> <4F0318E9.1040507@nlnetlabs.nl> Message-ID: <20120103152622.GF1072@macbook.bluepipe.net> W.C.A. Wijngaards (wouter) writes: > > There is no way to override this behaviour (at this time), and it would > be somewhat difficult to make portable. Ok, no problem. Yes, I know the pain it is with Windows. > If you need a couple you use you can put the search path into the config > file manually, at this time. I did that. > This is why I pick it up on install, e.g. > if you install at home/work you get the 'right' DHCP searchpath all the > time. Right. It was just slightly confusing that it would actively pick up what's essentially a localized setting from whatever DHCP was serving me at the time, and stick it into the config file at install time. Maybe it's just me :) Thanks, Phil From jaap at NLnetLabs.nl Tue Jan 3 15:39:24 2012 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Tue, 03 Jan 2012 16:39:24 +0100 Subject: [Dnssec-trigger] OS X, resolv.conf In-Reply-To: <20120103152622.GF1072@macbook.bluepipe.net> References: <20120103140106.GB1072@macbook.bluepipe.net> <4F030E65.9030603@nlnetlabs.nl> <20120103143632.GD1072@macbook.bluepipe.net> <4F0318E9.1040507@nlnetlabs.nl> <20120103152622.GF1072@macbook.bluepipe.net> Message-ID: <201201031539.q03FdOMB021203@bartok.nlnetlabs.nl> Right. It was just slightly confusing that it would actively pick up what's essentially a localized setting from whatever DHCP was serving me at the time, and stick it into the config file at install time. Maybe it's just me :) Probably not just confusing to you. One thing one can consider is not install a search path at all (or always the nathing.valid thingy). PS. BTW, the behavior is documented: domain: "example.com" The domain to set in resolv.conf. See resolv.conf(5). Picked up once during installation, and not from DHCP since it allows directing traffic elsewhere. although it doesn't says from what it is picked up. From regnauld at nsrc.org Tue Jan 3 15:47:31 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 3 Jan 2012 16:47:31 +0100 Subject: [Dnssec-trigger] OS X, resolv.conf In-Reply-To: <201201031539.q03FdOMB021203@bartok.nlnetlabs.nl> References: <20120103140106.GB1072@macbook.bluepipe.net> <4F030E65.9030603@nlnetlabs.nl> <20120103143632.GD1072@macbook.bluepipe.net> <4F0318E9.1040507@nlnetlabs.nl> <20120103152622.GF1072@macbook.bluepipe.net> <201201031539.q03FdOMB021203@bartok.nlnetlabs.nl> Message-ID: <20120103154731.GI1072@macbook.bluepipe.net> Jaap Akkerhuis (jaap) writes: > > PS. BTW, the behavior is documented: > > domain: "example.com" > The domain to set in resolv.conf. See resolv.conf(5). Picked > up once during installation, and not from DHCP since it allows > directing traffic elsewhere. > > although it doesn't says from what it is picked up. But it says "not from DHCP", and the domain in question HAD been handed out by DHCP... /me is further confused :) Phil From dk at intuix.com Tue Jan 3 16:09:40 2012 From: dk at intuix.com (Dmitry Kohmanyuk) Date: Tue, 3 Jan 2012 18:09:40 +0200 Subject: [Dnssec-trigger] OS X, resolv.conf In-Reply-To: <20120103154731.GI1072@macbook.bluepipe.net> References: <20120103140106.GB1072@macbook.bluepipe.net> <4F030E65.9030603@nlnetlabs.nl> <20120103143632.GD1072@macbook.bluepipe.net> <4F0318E9.1040507@nlnetlabs.nl> <20120103152622.GF1072@macbook.bluepipe.net> <201201031539.q03FdOMB021203@bartok.nlnetlabs.nl> <20120103154731.GI1072@macbook.bluepipe.net> Message-ID: <9506D413-8228-4E1B-ABF2-88EF0A6B2C77@intuix.com> On Jan 3, 2012, at 5:47 PM, Phil Regnauld wrote: > Jaap Akkerhuis (jaap) writes: >> >> PS. BTW, the behavior is documented: >> >> domain: "example.com" >> The domain to set in resolv.conf. See resolv.conf(5). Picked >> up once during installation, and not from DHCP since it allows >> directing traffic elsewhere. >> >> although it doesn't says from what it is picked up. > > But it says "not from DHCP", and the domain in question HAD been handed out > by DHCP... /me is further confused :) > I think this behaviour is not really helpful - for those folks who roam (and those are primary users of dnssec-trigger, right?) it may incidentally resolve using not-expected domain. it better be either option during install ("Do you want to use search path X.Y.Z?") or disabled. At least there should be a warning during installation (just displaying recorded setting is ok.) From wouter at nlnetlabs.nl Thu Jan 26 11:23:32 2012 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Thu, 26 Jan 2012 12:23:32 +0100 Subject: [Dnssec-trigger] bugzilla can be used to file dnssec-trigger bug reports via the web browser Message-ID: <4F2137B4.8010001@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There is a bugzilla location for dnssec-trigger bug reports: http://nlnetlabs.nl/bugs-script/enter_bug.cgi?product=dnssec-trigger So we can track them, and it is friendly to non-mailinglist-members that want to file a bugreport. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPITe0AAoJEJ9vHC1+BF+NLc0P/RMC1Tkh+dqquIMwIurus5Wp Z4RkkE6VaLEJpy5hd8iNlwBPzVgHSK28blaYHPzU1BKlJp5zb9mZ9loiLJC9nKYj PzvSpZOwZlDoqJDl/DQl8bAfg4QoKxW+Pr/twNmE43I76djJkWVr353VxdMSht/W wvbmr7zW4mkEJ2ffvpC7gEOct68Vhh0pdy3n8YUmpZ1pqLmDOYpHWQkKjgcCna/1 vMjzzlro+EIWso3/zW3szyB5+J8+9u1TC8gqbVDR1m/q/hS/BLpjALv8cAEfPs0W g/tvjYMMIqMIHfWxuZSUQIcbQfD3jvOXvym8HdCRO4U2KRUvVf2YTfUBo99uFbPH 1h8oClVYhldveXHW6T8iidkT988IlCSAxI9FXLxxvXEd99mk4AaqxLeAY8X3wKce jDajB/DkNUJIWB/R/ax2fcFZy1MG6nZF6w0HeZ3Z1/e7nguPTxhR+auWfBjkAKJW ImYiWkGQiTBb+yu2bzFDyX69CDZydTdK4diHSkr2FofzNYrsh99wyg0fy6vkvank CGLdy4GxDJexnfWa+VaT737oOGSjsU+KbTzoT5OI94yVFeaISsukIScPdK5r+DOy hlW3ONvsiNbRfkn2z7lnDSTrx7ITGZLBSlQD5xBWK5uQwysZKrlQ4IheoE/yBmpn sw0gARPyX6od1+2hBv05 =Iqbc -----END PGP SIGNATURE----- From paul at nohats.ca Thu Jan 26 14:56:59 2012 From: paul at nohats.ca (Paul Wouters) Date: Thu, 26 Jan 2012 09:56:59 -0500 (EST) Subject: [Dnssec-trigger] bugzilla can be used to file dnssec-trigger bug reports via the web browser In-Reply-To: <4F2137B4.8010001@nlnetlabs.nl> References: <4F2137B4.8010001@nlnetlabs.nl> Message-ID: On Thu, 26 Jan 2012, W.C.A. Wijngaards wrote: > There is a bugzilla location for dnssec-trigger bug reports: > http://nlnetlabs.nl/bugs-script/enter_bug.cgi?product=dnssec-trigger > > So we can track them, and it is friendly to non-mailinglist-members > that want to file a bugreport. So let me use this opportunity to talk about features :) The first is, why do we need to have the user decide when to switch from hotspot mode to secure mode? Why Can't we probe every 5 seconds? Perhaps with some exponential backoff? I really would like to see that process automated - it should not need user input. The second is, with Linux, there is network manager that keeps track of connections and properties. It would be nice if we could store and remember the brokenness/failures so when we reconnect to the same network, we could switch to the expected mode. This latter one is harder because hotspots function in two modes, pre and post the hotspot magic. Paul From paul at nohats.ca Thu Jan 26 19:59:54 2012 From: paul at nohats.ca (Paul Wouters) Date: Thu, 26 Jan 2012 14:59:54 -0500 (EST) Subject: [Dnssec-trigger] port 443 vs port 80? Message-ID: Hi, See these results: results from probe at 2012-01-26 14:49:28 ssl443 193.110.157.123: OK tcp80 193.110.157.123: OK authority 128.8.10.90: error timeout no cache: no DNS servers have been supplied via DHCP DNSSEC results fetched from open resolvers over TCP I think "over TCP" means port 80, not port 443. But I recommend telling the user whether tcp80 or ssl443 is used. Second, if indeed it is using tcp80, I suggest that since we can do ssl443, we might as well use that to give the user some query privacy. So I propose to use ssl443 over port80 if both are available. Paul From wouter at nlnetlabs.nl Thu Jan 26 21:45:54 2012 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Thu, 26 Jan 2012 22:45:54 +0100 Subject: [Dnssec-trigger] port 443 vs port 80? In-Reply-To: References: Message-ID: <4F21C992.7090505@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, On 01/26/2012 08:59 PM, Paul Wouters wrote: > > Hi, > > See these results: > > results from probe at 2012-01-26 14:49:28 > > ssl443 193.110.157.123: OK tcp80 193.110.157.123: OK authority > 128.8.10.90: error timeout > no cache: no DNS servers have been supplied via DHCP > > DNSSEC results fetched from open resolvers over TCP Yes it prefers port 80 above port 443. Port 80 is unencrypted plain-DNS-over-TCP. > I think "over TCP" means port 80, not port 443. But I recommend telling > the user whether tcp80 or ssl443 is used. > > Second, if indeed it is using tcp80, I suggest that since we can do > ssl443, we might as well use that to give the user some query privacy. > > So I propose to use ssl443 over port80 if both are available. Well without SSL is a lot easier on resources, also much faster in msec roundtrip time. The query itself, if someone interested was bothered, could easily be traced anyway (because it would have been sent to the local cache, through the local firewall, unencrypted if the local cache supported the DO flag). So, its not about privacy, but about the difference in resources. You could, of course, simply not configure tcp80 entries in the config file. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPIcmSAAoJEJ9vHC1+BF+NhOwP/R4r6MwiEwg78Kez12ejdBtH mK3qi9ArPAaXBfASQAWMW7nFr35+YiGr05JJs7T3PngKplxPb9HzNEMFrnfFXpUa IFaN0PF6avzSu0C2ngEnOMFsrjY1X8NpKKJ9qeVAOR6NyFAAqAYNublFq7OMg29f LETBerA5fvJLKFz8Q3S2d/dq8UScpnFgDXU4yASNcS5d9av46wuqOBFm36H4Qrxi IYX6GuNvDKfh1brSeVnsu3tlOTGBX4aEG99pfb8mfoLJbQ5uG3xWB21Z4AcvScy2 TsbcMNiFwGlEMRw8V+2k0HfMgkKRhOXVRDcYRhra6lOqExROm74vLoQDF3L4Lwcx FPHNHF9TfE6W5BiEnt9MUXPGOtrJOjHRPPLsKiHQL4/vT6XXEqlAg/cFXnoPJXyR Orq1MQDs5fEOHViqXsyW3DiyhP6quc8TTiHGH4vHz8AdC03sBt23MkXEEXh4QArK UPttgyIF+8N3lOWGL3NbaDIsB0h71aihF2TOcp5H6J3gFpIEy1XxpzMKqxBpX87f H/07U9aacTy3tdk82rp8IaGYtMJaSvCceDRrcZFeJYT1u1qUzO/YHOtjebDI6OwP 9UkyvkISmu6exDLUvMDpDT1dv1hbKTj0xspzrDLe+ux+YaBfXYvZ/2VeRS9aw/fm TwolKV+9HHpqV0ukg3w+ =ZKz6 -----END PGP SIGNATURE----- From wouter at nlnetlabs.nl Thu Jan 26 21:55:05 2012 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Thu, 26 Jan 2012 22:55:05 +0100 Subject: [Dnssec-trigger] bugzilla can be used to file dnssec-trigger bug reports via the web browser In-Reply-To: References: <4F2137B4.8010001@nlnetlabs.nl> Message-ID: <4F21CBB9.4090609@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, On 01/26/2012 03:56 PM, Paul Wouters wrote: > On Thu, 26 Jan 2012, W.C.A. Wijngaards wrote: > >> There is a bugzilla location for dnssec-trigger bug reports: >> http://nlnetlabs.nl/bugs-script/enter_bug.cgi?product=dnssec-trigger >> >> So we can track them, and it is friendly to non-mailinglist-members >> that want to file a bugreport. > > So let me use this opportunity to talk about features :) Yes, this is an experimental product to see how we can have DNSSEC at end hosts. > The first is, why do we need to have the user decide when to switch from > hotspot mode to secure mode? There are two insecure modes right now: hotspot mode: use chose hotspot mode to sign in. stay insecure until reprobe menu item. insecure dialog: probe failed, insecure dialog shown to user (disconnect or insecure?). Silent reprobes with timeouts in the background (with no popups, but if secure, takes it). > Why Can't we probe every 5 seconds? Perhaps > with some exponential backoff? I really would like to see that process > automated - it should not need user input. Yes, if the insecure-ness was because of a failed probe, then an exponential backoff timer is implemented today. If insecure-ness is because user chose hotspot-mode we keep that mode until the user clicks to exit it. Because, as Stephane found out, some hotspots can have DNSSEC (via some workaround), but then you cannot actually sign-on anymore (that uses the insecure local cache). This user hotspot and reprobe menu item thing works with you tech-guys, but it is difficult. I would like something easier, but I do not know how to help the user here. To dnssec-trigger everything may seem to be fine (dnssec with some workaround, yay), but then the web browser cannot connect anywhere and cannot sign-in either ... > The second is, with Linux, there is network manager that keeps track of > connections and properties. It would be nice if we could store and > remember the brokenness/failures so when we reconnect to the same > network, we could switch to the expected mode. This latter one is harder > because hotspots function in two modes, pre and post the hotspot magic. Yes. Somehow know that 'hotspot signon' mode is necessary, and sign-in completion can trigger a reprobe somehow... Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPIcu5AAoJEJ9vHC1+BF+NG88QALHQ3seICWoo/RfRY5eFIzos vxQVJfbqaFbU2I6/6UQGgkdxB87hCU+Hb8YKbT9Wq2JCwC6HhJQ6wOwmw3Muo1QP mg97x4E3vHFl6DBV4sXi5PVAuYnsRUXSVqXV75zvHvn+TPDSpz1h+gf5fBBdEzkk 4MROO8Au4SSazihVaVHULRS/nkv0WoZEJSt61mzTpgaJVmi074l8Tw5T1jJhWLuX L/mcKpDWk6Hk0/N9+FHbCCgv8+c2SO8lMSgyFsuXS6Zz9k8s2i6GP8kKZE36bKDu 1IGw8LExm/lTty2/u0b6faJ+2ZIJUy0pjtbQu/FlK0gj0USklmd1tMblTxjI+h4/ 0DX0Z4nYe1l4W92oikH10jWMOaYquOlgtynw1u1pe0fETieY49PRdcYcyjTvQLuy q2jyEsGnVevqNfc0Ek+sai/1D98mUr46mvfR2sjqFy98Qr1Z2n3OAt9PBBx7Y53x OGfSZlzQNi6XaeNmLpjd0VD0taNt32fErTvXY+rQ9OirebXuRDzgV7zH5fCdxHic ImQawetJ0dBa2dAGsSI59CflJzOdgNWuEdRw1lAA2kuKanEGjOlrw8DU+2pDRR+r hIqPR1hBwWzu8eGPSh9eAojrPS3QoAoRp5GytttE2cJnz34YZPmrMuZ4dlco5djo ZJDF7n8v9iXTO01JA9LU =nmD5 -----END PGP SIGNATURE----- From paul at nohats.ca Thu Jan 26 22:37:55 2012 From: paul at nohats.ca (Paul Wouters) Date: Thu, 26 Jan 2012 17:37:55 -0500 (EST) Subject: [Dnssec-trigger] bugzilla can be used to file dnssec-trigger bug reports via the web browser In-Reply-To: <4F21CBB9.4090609@nlnetlabs.nl> References: <4F2137B4.8010001@nlnetlabs.nl> <4F21CBB9.4090609@nlnetlabs.nl> Message-ID: On Thu, 26 Jan 2012, W.C.A. Wijngaards wrote: > There are two insecure modes right now: > hotspot mode: use chose hotspot mode to sign in. stay insecure until > reprobe menu item. > insecure dialog: probe failed, insecure dialog shown to user (disconnect > or insecure?). Silent reprobes with timeouts in the background (with no > popups, but if secure, takes it). Ahh, I did not realise the difference. > Yes, if the insecure-ness was because of a failed probe, then an > exponential backoff timer is implemented today. > > If insecure-ness is because user chose hotspot-mode we keep that mode > until the user clicks to exit it. Because, as Stephane found out, some > hotspots can have DNSSEC (via some workaround), but then you cannot > actually sign-on anymore (that uses the insecure local cache). > > This user hotspot and reprobe menu item thing works with you tech-guys, > but it is difficult. I would like something easier, but I do not know > how to help the user here. To dnssec-trigger everything may seem to be > fine (dnssec with some workaround, yay), but then the web browser cannot > connect anywhere and cannot sign-in either ... > Somehow know that 'hotspot signon' mode is necessary, and sign-in > completion can trigger a reprobe somehow... You should detect hotspot mode not based on DNS but based on web traffic. This is how apple (and I assume android) does it. For example, check http://nohats.ca/hotspot/ That should always return a page just containing "OK". If it returns ANYthing else, a redirect, a 404, or different html, you're on a hotspot. I am going to add such a super static page to the fedoraproject infrastructure that we will be able to test with that is more highly available then my single server instance, but it can be used for testing code. Paul From wouter at nlnetlabs.nl Fri Jan 27 10:16:24 2012 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Fri, 27 Jan 2012 11:16:24 +0100 Subject: [Dnssec-trigger] bugzilla can be used to file dnssec-trigger bug reports via the web browser In-Reply-To: References: <4F2137B4.8010001@nlnetlabs.nl> <4F21CBB9.4090609@nlnetlabs.nl> Message-ID: <4F227978.2000305@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, On 01/26/2012 11:37 PM, Paul Wouters wrote: > On Thu, 26 Jan 2012, W.C.A. Wijngaards wrote: > >> There are two insecure modes right now: hotspot mode: use chose >> hotspot mode to sign in. stay insecure until reprobe menu item. >> insecure dialog: probe failed, insecure dialog shown to user >> (disconnect or insecure?). Silent reprobes with timeouts in the >> background (with no popups, but if secure, takes it). > > Ahh, I did not realise the difference. > >> Yes, if the insecure-ness was because of a failed probe, then an >> exponential backoff timer is implemented today. >> >> If insecure-ness is because user chose hotspot-mode we keep that >> mode until the user clicks to exit it. Because, as Stephane >> found out, some hotspots can have DNSSEC (via some workaround), >> but then you cannot actually sign-on anymore (that uses the >> insecure local cache). >> >> This user hotspot and reprobe menu item thing works with you >> tech-guys, but it is difficult. I would like something easier, >> but I do not know how to help the user here. To dnssec-trigger >> everything may seem to be fine (dnssec with some workaround, >> yay), but then the web browser cannot connect anywhere and cannot >> sign-in either ... > >> Somehow know that 'hotspot signon' mode is necessary, and >> sign-in completion can trigger a reprobe somehow... > > You should detect hotspot mode not based on DNS but based on web > traffic. This is how apple (and I assume android) does it. For > example, check http://nohats.ca/hotspot/ > > That should always return a page just containing "OK". If it > returns ANYthing else, a redirect, a 404, or different html, you're > on a hotspot. I am going to add such a super static page to the > fedoraproject infrastructure that we will be able to test with that > is more highly available then my single server instance, but it can > be used for testing code. Yes that would be a user-friendly way to detect that the hotspot is 'open to the internet'. And if that fails, it is some for a warning dialog and hotspot_mode. Until it succeeds, which can have exponential backoff. There is then a new requirement for a user-override to insecure mode. Sometimes people simply need that, to access a local printer, and things like that, really a site-configuration issue. Something also to store in networkmanager profiles. Also there is a privacy problem with this page. What does the probe send in its http headers to this site (unique numbers?)? This site gets to track you because you send it traffic whenever you connect to the internet? The site itself could get very high traffic loads, because everyone downloads the page whenever they switch their wifi. Due to privacy and traffic load, I did not consider that we could run such a page ourselves, but then fedoraproject may have a CDN fronting it. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPInl3AAoJEJ9vHC1+BF+N2LwP+gKd9hzRcIsW3ZYlKfKn4gJd FOJxe2xUVRJcydwq4DhXYl0qbyiz/hY6H54wtTIzDdtcHNSUFFKsxfiUCvDj6fpr Ow1e8o7jvSYsuu7jTO1Nk0iYo4HJ1tfKnqHN/Ih57j+fHplR19guvgC7kpuJhanS eQAwKYZE2XCXdAEQm9KKVYIQzA8yGWRxAFb8Y7S62Q36wWfkCl/5zDYeROl1g2mH MdMojWg7WthB2b23D6RrcY20rl8qPWgU1texKdThwhCsPo7chSGY2ne3N0z9t+Kp C+dOSjJSMvoAp7KOdD7nl+StS+jPOPAXoVj3Ux+Ptj/ZToM/Mkz0tbFSeGoite+j jCKQ8l3Ggz79GRm8JJRdSRNqKnSPRfpc3BGlEn3Uq43opHVQbWRHOMOJANFNMaWQ 6UlIreztZdYF0VlWLDcYsLQV8gBYyCD7Wl1uQHWdlnN36bavnZxOzWPIl8U1XI3h 2xwK6M23cEB6pJchBuRF8QUp6kfX2gcuOvqM5aHfWqnYvyjiGIFCRC29hkpVbnWQ 7r1nfY/sdUDthPc6T6go3muhXFWwOr7Uj4Sy6UyAdNzmshRS3o24SLubI33J+LzW DRSRgOlguOWnJdUBFmDkQhtx46uwEsCnbiSWsgIajEthx2ZVwaqIxvDRnV2LzydT 8YGIg0R9js38dlPmdEuB =iE8P -----END PGP SIGNATURE----- From wouter at nlnetlabs.nl Fri Jan 27 11:08:44 2012 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Fri, 27 Jan 2012 12:08:44 +0100 Subject: [Dnssec-trigger] Open Issues Message-ID: <4F2285BC.6090800@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, Dnssec trigger (now at version 0.9) is an experiment to put DNSSEC on your laptop. It works, people are using it. Most of the bugs seem to have been worked out of the system. The issues that remain are visual and feature-completeness. They center on user-friendliness (i.e. for computer illiterate people), and on enterprise-site-configuration. o Visual. I have ignored these requests. Kept the GUI minimal. Icon change requested for brighter colours: lighter blue, more visible red pixels on the warning icon (everyones traybar has a different bg colour I guess). The configuration options would be along the lines of: overrides for insecure access to .local (from the dhcp dns), stubs for local-company-zones. o Autoupdate feature. On windows and OSX the update functionality is atrocious, you have to implement yourself and there is no support. On Linux and in BSD ports, this is handled by distros. Autoupdate would work without user intervention (silent updates). The real issue is having a signing key for this, that is safe enough (with DANE on the horizon, this component could become critical to the security of the machine, the software install is basically remote-root access). o Hotspot signon features. See email on that topic. About user friendliness, having to use a menu item is only possible for geeks. o Resolvers that can do tcp-dns-port80 and ssl-dns-port443 to be able to handle a large user group. Alternatively, we do not configure any such fallbacks, users will get a warning and go to insecure mode. Because this is the last fallback option, it should have a smaller traffic requirement (than the 'OK' page from the hotspot discussion). o there are some smaller todo items, such as facilitating ssl-key rollover on the ssl resolvers. o some people have expressed porting wishes, like app-store, ports to iPhone, Android. It is likely impossible because dnssec-trigger must have root access (for setting the DNS IP). Android is open source, its base system could be contributed to. Phone Oses do not give root access to apps. App-stores for PCs also have sandboxing, no root. o perhaps there are other obstacles? What features must the dnssec-trigger system contain? o an anti-idea that cropped up a couple times is to provide error-analysis of dnssec failures. This is not possible, only you (a geek) can understand the analysis anyway, and popups to workaround the error turn into 'ignore security failure' nightmares that destroy security. Right now the system checks for security on wifi-connect. After that, all dnssec failures are simply failures. (diagnostic tools are for the administrator, we could write errors to log, easy enough to set unbound to write validation failures to system log, and this is where systemadmins are used to looking for error desc). Separate diagnostic tools, of course, exist, like dnsviz, dnssec-tools.org. o do we really need a go-insecure-connect-to-this-wifi button? This button turns off dnssec, you have your old-fashioned dnssec-less experience. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPIoW8AAoJEJ9vHC1+BF+NFTQP/3CBQsTnxgK4yfnRHE9frgEH Gy3KpWXV/Q8BrSeVWkApxfLA3GBpc73AvHSK0KiIEfmxG+vFE2KS8Dvvd2nak/YR 0oaxdoj2znw1YuEwQy41ujMGwtr0MA+nVekbcTrgC+slOcGFI7bUkWPme2GjzWC6 y3XbDphawRc7fUI2ShhAz7qOVttJfV9A2WSwVvHlhVp8mrLtLCP/Bbm2i2a85CkJ iLQepTFs8S/EPOMMUUL+rPJzl8n4AnFo7E5nJSoxLjHgEgWEH7xvbo8Rmjayn5T/ gR/OaghWSOHwUaETMeUPFAtXgS1OncbpINYmWWuqhht92SjZ9tTWo41KgpRAzRSr Bf2NSXvhhGhaBVkBP+m9ySdjpbaajjWsZbGW0zzcE+jMu0Kbow0V2/L2uSqqP7IW BvIcxhk/1kZ0F75j/BddhBdgWExbqJPRAB7pJc0dVVNynZsEs+7Qut1ASlihToa+ 2I9g/q/JUpOZuDDMUvHbIFSTSCjCtW46iqil2lujQiorRbrD/HK0o3q+3rVxTz5B xDz9I5Il1CfcM59+4WIYZyfHOW4Nvvgc1s71QBemh+yGj3xPLOlEadqgP+iU16k4 B5iYV7DDIZGSmGoQZ0D5EaRc6fanD1ZZUJ5tJ8O0MxM32wcRlXy+uvvmUO65kP1W 0gNZ+DGDOTdb3zFxUusQ =0rtq -----END PGP SIGNATURE----- From bortzmeyer at nic.fr Fri Jan 27 11:37:39 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 27 Jan 2012 12:37:39 +0100 Subject: [Dnssec-trigger] bugzilla can be used to file dnssec-trigger bug reports via the web browser In-Reply-To: References: <4F2137B4.8010001@nlnetlabs.nl> <4F21CBB9.4090609@nlnetlabs.nl> Message-ID: <20120127113739.GA19705@nic.fr> On Thu, Jan 26, 2012 at 05:37:55PM -0500, Paul Wouters wrote a message of 44 lines which said: > For example, check http://nohats.ca/hotspot/ By the way, it is broken, it says "Content-Type: text/html" but does not return anything looking like HTML. It should use "Content-Type: text/plain". Also, it does not return Expires:, Cache-control: which could be necessary to avoid caching of the test. From paul at nohats.ca Fri Jan 27 14:05:16 2012 From: paul at nohats.ca (Paul Wouters) Date: Fri, 27 Jan 2012 09:05:16 -0500 (EST) Subject: [Dnssec-trigger] Open Issues In-Reply-To: <4F2285BC.6090800@nlnetlabs.nl> References: <4F2285BC.6090800@nlnetlabs.nl> Message-ID: On Fri, 27 Jan 2012, W.C.A. Wijngaards wrote: > Dnssec trigger (now at version 0.9) is an experiment to put DNSSEC on > your laptop. It works, people are using it. Most of the bugs seem to > have been worked out of the system. The issues that remain are visual > and feature-completeness. They center on user-friendliness (i.e. for > computer illiterate people), and on enterprise-site-configuration. For linux, a few issues remain: o Integrate with NM fully, so no chattr +i on resolv.conf is needed. o Convert the daemon to a plugin to be run by NM o Convert the panel to fully integrate in NM o Remember wireless network DNS problems? (specifically with DNS views and VPN's, where one might have to reject dnssec to get intranet DNS access) a "command line" version of the probe giving the results would be nice. > o Resolvers that can do tcp-dns-port80 and ssl-dns-port443 to be able > to handle a large user group. We will have a few from the Fedora infrastructure. We can see what load they will receive and how well they will work for people. Perhaps we can convert that in an "ntp.pool.org" type pool. I will disabled udp 53 on those instances so they cannot be used for amplification attacks. > o some people have expressed porting wishes, like app-store, ports to > iPhone, Android. It would be nice, but probably better left for iphone experts. I'm going to poll some of those and see what they can do :) > o an anti-idea that cropped up a couple times is to provide > error-analysis of dnssec failures. It would be nice to be able to submit the failed hotspots and perhaps build up a list. opt-in only, prob using a separate command so only experts will do this. It might provide useful information? > o do we really need a go-insecure-connect-to-this-wifi button? This > button turns off dnssec, you have your old-fashioned dnssec-less > experience. Awareness is good, but perhaps the message can be changed to say "this network is broken, advise the DNS admin to fix it" Paul From paul at nohats.ca Fri Jan 27 14:07:57 2012 From: paul at nohats.ca (Paul Wouters) Date: Fri, 27 Jan 2012 09:07:57 -0500 (EST) Subject: [Dnssec-trigger] bugzilla can be used to file dnssec-trigger bug reports via the web browser In-Reply-To: <4F227978.2000305@nlnetlabs.nl> References: <4F2137B4.8010001@nlnetlabs.nl> <4F21CBB9.4090609@nlnetlabs.nl> <4F227978.2000305@nlnetlabs.nl> Message-ID: On Fri, 27 Jan 2012, W.C.A. Wijngaards wrote: > Also there is a privacy problem with this page. What does the probe > send in its http headers to this site (unique numbers?)? This site > gets to track you because you send it traffic whenever you connect to > the internet? > > The site itself could get very high traffic loads, because everyone > downloads the page whenever they switch their wifi. > > Due to privacy and traffic load, I did not consider that we could run > such a page ourselves, but then fedoraproject may have a CDN fronting it. yes. I would first like to experiment with a simple page. Once we feel confident this works well, I can ping fedora to get the resource. Since the request will be a strange one (never ever change this page no matter what, and no redirects), I'd rather be sure we know it all works before I ask for it. Paul From peter.van.dijk at netherlabs.nl Tue Jan 31 22:12:48 2012 From: peter.van.dijk at netherlabs.nl (Peter van Dijk) Date: Tue, 31 Jan 2012 23:12:48 +0100 Subject: [Dnssec-trigger] Open Issues In-Reply-To: <4F2285BC.6090800@nlnetlabs.nl> References: <4F2285BC.6090800@nlnetlabs.nl> Message-ID: <9A034286-0F41-4993-9DF7-26024132B03C@netherlabs.nl> Hello Wouter, On Jan 27, 2012, at 12:08 , W.C.A. Wijngaards wrote: > o Autoupdate feature. On windows and OSX the update functionality is > atrocious, you have to implement yourself and there is no support. Have you seen http://sparkle.andymatuschak.org/ ? 99% of mac apps seem to be using it. Kind regards, Peter van Dijk