From thozza at redhat.com Wed Dec 4 15:59:22 2013 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 4 Dec 2013 10:59:22 -0500 (EST) Subject: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called In-Reply-To: <1217956979.22868407.1386170183527.JavaMail.root@redhat.com> Message-ID: <287421960.22883489.1386172762119.JavaMail.root@redhat.com> Hi. I would like to discuss if the dnssec-triggerd behaviour when doing hot spot sign-on is really correct. At the moment dnssec-trigger writes nameservers obtained from DHCP into the /etc/resolv.conf on Linux. Wouldn't be better if it would set DNS servers obtained from DHCP (regardless if they support DNSSEC) as forwarders in unbound and also disable the validator module? When going back to the "secure" mode it could just enable the validator module and do the reprobing and set forwarders based on the probing results. Thank you. Regards, Tomas Hozza From paul at cypherpunks.ca Wed Dec 4 16:10:06 2013 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 4 Dec 2013 11:10:06 -0500 (EST) Subject: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called In-Reply-To: <287421960.22883489.1386172762119.JavaMail.root@redhat.com> References: <287421960.22883489.1386172762119.JavaMail.root@redhat.com> Message-ID: On Wed, 4 Dec 2013, Tomas Hozza wrote: > I would like to discuss if the dnssec-triggerd behaviour > when doing hot spot sign-on is really correct. At the moment > dnssec-trigger writes nameservers obtained from DHCP into > the /etc/resolv.conf on Linux. > > Wouldn't be better if it would set DNS servers obtained > from DHCP (regardless if they support DNSSEC) as forwarders > in unbound and also disable the validator module? > > When going back to the "secure" mode it could just enable > the validator module and do the reprobing and set forwarders > based on the probing results. No, that would contaminate your cache. Paul From thozza at redhat.com Wed Dec 4 16:23:49 2013 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 4 Dec 2013 11:23:49 -0500 (EST) Subject: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called In-Reply-To: References: <287421960.22883489.1386172762119.JavaMail.root@redhat.com> Message-ID: <921959402.22895296.1386174229677.JavaMail.root@redhat.com> ----- Original Message ----- > On Wed, 4 Dec 2013, Tomas Hozza wrote: > > > I would like to discuss if the dnssec-triggerd behaviour > > when doing hot spot sign-on is really correct. At the moment > > dnssec-trigger writes nameservers obtained from DHCP into > > the /etc/resolv.conf on Linux. > > > > Wouldn't be better if it would set DNS servers obtained > > from DHCP (regardless if they support DNSSEC) as forwarders > > in unbound and also disable the validator module? > > > > When going back to the "secure" mode it could just enable > > the validator module and do the reprobing and set forwarders > > based on the probing results. > > No, that would contaminate your cache. Good point. Unfortunately FWIK the validator module can be disabled only by changing the configuration file. For changes to be used you'd need to reload unbound, which would result in flushing the cache completely. Regards, Tomas From paul at cypherpunks.ca Wed Dec 4 16:48:17 2013 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 4 Dec 2013 11:48:17 -0500 (EST) Subject: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called In-Reply-To: <921959402.22895296.1386174229677.JavaMail.root@redhat.com> References: <287421960.22883489.1386172762119.JavaMail.root@redhat.com> <921959402.22895296.1386174229677.JavaMail.root@redhat.com> Message-ID: On Wed, 4 Dec 2013, Tomas Hozza wrote: >>> When going back to the "secure" mode it could just enable >>> the validator module and do the reprobing and set forwarders >>> based on the probing results. >> >> No, that would contaminate your cache. > > Good point. Unfortunately FWIK the validator module can be > disabled only by changing the configuration file. For changes > to be used you'd need to reload unbound, which would result > in flushing the cache completely. And for good reason. If you go from a polluted cache to enabling DNSSEC, you would have to validate the entire cache contents, or just flush it and start from scratch. You could not use any content in the cache since it had not been validated. Paul From psimerda at redhat.com Thu Dec 5 09:11:44 2013 From: psimerda at redhat.com (Pavel Simerda) Date: Thu, 5 Dec 2013 04:11:44 -0500 (EST) Subject: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called In-Reply-To: References: <287421960.22883489.1386172762119.JavaMail.root@redhat.com> <921959402.22895296.1386174229677.JavaMail.root@redhat.com> Message-ID: <950772235.23088509.1386234704065.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Paul Wouters" > To: "Tomas Hozza" > Cc: dnssec-trigger at NLnetLabs.nl, "Pavel Simerda" > Sent: Wednesday, December 4, 2013 5:48:17 PM > Subject: Re: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called > > On Wed, 4 Dec 2013, Tomas Hozza wrote: > > >>> When going back to the "secure" mode it could just enable > >>> the validator module and do the reprobing and set forwarders > >>> based on the probing results. > >> > >> No, that would contaminate your cache. > > > > Good point. Unfortunately FWIK the validator module can be > > disabled only by changing the configuration file. For changes > > to be used you'd need to reload unbound, which would result > > in flushing the cache completely. > > And for good reason. If you go from a polluted cache to enabling > DNSSEC, you would have to validate the entire cache contents, or > just flush it and start from scratch. You could not use any > content in the cache since it had not been validated. Actually, when you change configuration at runtime, you should always flush the cache for the respective subtree as well. For example when you remove an insecure forward zone, the cache is polluted as well. I actually think that unbound should flush the cache automatically to avoid that. As a workaround, the cache can be flushed explicitly. Cheers, Pavel From paul at cypherpunks.ca Thu Dec 5 15:10:53 2013 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 5 Dec 2013 10:10:53 -0500 (EST) Subject: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called In-Reply-To: <950772235.23088509.1386234704065.JavaMail.root@redhat.com> References: <287421960.22883489.1386172762119.JavaMail.root@redhat.com> <921959402.22895296.1386174229677.JavaMail.root@redhat.com> <950772235.23088509.1386234704065.JavaMail.root@redhat.com> Message-ID: On Thu, 5 Dec 2013, Pavel Simerda wrote: >> And for good reason. If you go from a polluted cache to enabling >> DNSSEC, you would have to validate the entire cache contents, or >> just flush it and start from scratch. You could not use any >> content in the cache since it had not been validated. > > Actually, when you change configuration at runtime, you should always flush the cache for the respective subtree as well. For example when you remove an insecure forward zone, the cache is polluted as well. I actually think that unbound should flush the cache automatically to avoid that. As a workaround, the cache can be flushed explicitly. The way we implemented runtime forwards, eg from VPNs, we do flush the particular DNS domain from the cache - no need to flush everything. Paul From psimerda at redhat.com Fri Dec 6 08:39:47 2013 From: psimerda at redhat.com (Pavel Simerda) Date: Fri, 6 Dec 2013 03:39:47 -0500 (EST) Subject: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called In-Reply-To: References: <287421960.22883489.1386172762119.JavaMail.root@redhat.com> <921959402.22895296.1386174229677.JavaMail.root@redhat.com> <950772235.23088509.1386234704065.JavaMail.root@redhat.com> Message-ID: <690005061.23452997.1386319187668.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Paul Wouters" > To: "Pavel Simerda" > Cc: "Tomas Hozza" , dnssec-trigger at NLnetLabs.nl > Sent: Thursday, December 5, 2013 4:10:53 PM > Subject: Re: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called > > On Thu, 5 Dec 2013, Pavel Simerda wrote: > > >> And for good reason. If you go from a polluted cache to enabling > >> DNSSEC, you would have to validate the entire cache contents, or > >> just flush it and start from scratch. You could not use any > >> content in the cache since it had not been validated. > > > > Actually, when you change configuration at runtime, you should always flush > > the cache for the respective subtree as well. For example when you remove > > an insecure forward zone, the cache is polluted as well. I actually think > > that unbound should flush the cache automatically to avoid that. As a > > workaround, the cache can be flushed explicitly. > > The way we implemented runtime forwards, eg from VPNs, we do flush the > particular DNS domain from the cache - no need to flush everything. > > Paul I can imagine that temporarily polluting /etc/resolv.conf with global DNS information can be tempting at first, as it sort of implements a permissive mode without losing the whole unbound cache. And it indeed works for testing or technology previews. But we need a rock solid solution and I don't think writing any other nameservers than 127.0.0.1 fits in this requirement. NetworkManager seems to be affected by changes to /etc/resolv.conf and 127.0.0.1 is easy to filter out at all levels. I've heard voices that selinux-based systems might want to pick up a single service that would be allowed write to /etc/resolv.conf and nobody says it will be dnssec-trigger. And after all we do have some development power and we could fix (or let's say improve) unbound so that it can properly handle secure/insecure objects in the cache. In the meantime we can flush the cache as a workaround. This is not the only limitation of unbound that we found regarding real-world DNSSEC deployment and certainly not the only one we employ workarounds for. In the long term, I would rather rely on a good RDNSS software (such as unbound with a couple of future improvements) than on hacks like dropping unbound temporarily from the name resolution process. Pavel From paul at cypherpunks.ca Fri Dec 6 20:52:18 2013 From: paul at cypherpunks.ca (Paul Wouters) Date: Fri, 6 Dec 2013 15:52:18 -0500 (EST) Subject: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called In-Reply-To: <690005061.23452997.1386319187668.JavaMail.root@redhat.com> References: <287421960.22883489.1386172762119.JavaMail.root@redhat.com> <921959402.22895296.1386174229677.JavaMail.root@redhat.com> <950772235.23088509.1386234704065.JavaMail.root@redhat.com> <690005061.23452997.1386319187668.JavaMail.root@redhat.com> Message-ID: On Fri, 6 Dec 2013, Pavel Simerda wrote: > I can imagine that temporarily polluting /etc/resolv.conf with global DNS information can be tempting at first, as it sort of implements a permissive mode without losing the whole unbound cache. And it indeed works for testing or technology previews. > > But we need a rock solid solution and I don't think writing any other nameservers than 127.0.0.1 fits in this requirement. NetworkManager seems to be affected by changes to /etc/resolv.conf and 127.0.0.1 is easy to filter out at all levels. I've heard voices that selinux-based systems might want to pick up a single service that would be allowed write to /etc/resolv.conf and nobody says it will be dnssec-trigger. > > And after all we do have some development power and we could fix (or let's say improve) unbound so that it can properly handle secure/insecure objects in the cache. In the meantime we can flush the cache as a workaround. This is not the only limitation of unbound that we found regarding real-world DNSSEC deployment and certainly not the only one we employ workarounds for. > > In the long term, I would rather rely on a good RDNSS software (such as unbound with a couple of future improvements) than on hacks like dropping unbound temporarily from the name resolution process. I don't think it is as much of a hack as you think. But of course, it would be better not to have to rewrite /etc/resolv.conf. The best solution blocks port 53/unbound from resolution on a new network until NM has handled the sign-on. This can require a hot spot sign on using some browser window that is isolated from any running firefox, uses its own resolving - for example using libunbound in insecure mode that is terminated with the browser window when done. This would prevent any and all race conditions to our secure unbound cache, and would require no resolving. But that "browser window" would have to not use any libc gethostbyname() or get_addr_info() calls - just libunbound calls. The system unbound daemon would return SERVFAILs until its port 53 block is lifted - or it could be put explicitely into "cache only" mode. Paul From psimerda at redhat.com Sun Dec 8 08:04:32 2013 From: psimerda at redhat.com (Pavel Simerda) Date: Sun, 8 Dec 2013 03:04:32 -0500 (EST) Subject: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called In-Reply-To: References: <287421960.22883489.1386172762119.JavaMail.root@redhat.com> <921959402.22895296.1386174229677.JavaMail.root@redhat.com> <950772235.23088509.1386234704065.JavaMail.root@redhat.com> <690005061.23452997.1386319187668.JavaMail.root@redhat.com> Message-ID: <437722253.23751315.1386489872297.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Paul Wouters" > To: "Pavel Simerda" > Cc: "Tomas Hozza" , dnssec-trigger at NLnetLabs.nl > Sent: Friday, December 6, 2013 9:52:18 PM > Subject: Re: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called > > On Fri, 6 Dec 2013, Pavel Simerda wrote: > > > I can imagine that temporarily polluting /etc/resolv.conf with global DNS > > information can be tempting at first, as it sort of implements a > > permissive mode without losing the whole unbound cache. And it indeed > > works for testing or technology previews. > > > > But we need a rock solid solution and I don't think writing any other > > nameservers than 127.0.0.1 fits in this requirement. NetworkManager seems > > to be affected by changes to /etc/resolv.conf and 127.0.0.1 is easy to > > filter out at all levels. I've heard voices that selinux-based systems > > might want to pick up a single service that would be allowed write to > > /etc/resolv.conf and nobody says it will be dnssec-trigger. > > > > And after all we do have some development power and we could fix (or let's > > say improve) unbound so that it can properly handle secure/insecure > > objects in the cache. In the meantime we can flush the cache as a > > workaround. This is not the only limitation of unbound that we found > > regarding real-world DNSSEC deployment and certainly not the only one we > > employ workarounds for. > > > > In the long term, I would rather rely on a good RDNSS software (such as > > unbound with a couple of future improvements) than on hacks like dropping > > unbound temporarily from the name resolution process. > > > I don't think it is as much of a hack as you think. That's ok, we're each looking at it from a different perspective. > But of course, it > would be better not to have to rewrite /etc/resolv.conf. Agreed. > The best solution blocks port 53/unbound from resolution on a new > network until NM has handled the sign-on. I don't think I understand the idea. 1) We need to keep name resolution on the localhost side working. 2) We need to resolve external addresses via hotspot temporarily. 3) We need to avoid serving those external addresses from the cache when fully connected. >From my perspective, the best way would be to teach 'unbound' to either cache the hotspot-mode results separately or not cache them at all, which might be even easier. I don't think blocking any unbound communication on firewall can help. > This can require a hot > spot sign on using some browser window that is isolated from any > running firefox, uses its own resolving - for example using libunbound > in insecure mode that is terminated with the browser window when done. Yes, that would be theoretically possible but unless we really need to do Firefox magic (which we apparently don't), I would rather avoid it. When the only problem is unbound caching during the hotspot registration, then why don't we just solve it there. It's so much easier than any magic and will eventually be more universal. > This would prevent any and all race conditions to our secure unbound > cache, and would require no resolving. But that "browser window" would > have to not use any libc gethostbyname() or get_addr_info() calls - just > libunbound calls. The system unbound daemon would return SERVFAILs until > its port 53 block is lifted - or it could be put explicitely into "cache > only" mode. Sounds like a solution, but not one I would prefer over simply solving the unbound cache pollution problem. But anyway thanks very much, you helped me to sort my thoughts better. Actually, you can view the "nocache" solution as a simplification of the browser windows solution, as indeed we need to act at the same phases. The only difference is whether we use a separate channel for name resolution, or we handle the caching. Thanks. Pavel From paul at cypherpunks.ca Sun Dec 8 19:23:44 2013 From: paul at cypherpunks.ca (Paul Wouters) Date: Sun, 8 Dec 2013 14:23:44 -0500 (EST) Subject: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called In-Reply-To: <437722253.23751315.1386489872297.JavaMail.root@redhat.com> References: <287421960.22883489.1386172762119.JavaMail.root@redhat.com> <921959402.22895296.1386174229677.JavaMail.root@redhat.com> <950772235.23088509.1386234704065.JavaMail.root@redhat.com> <690005061.23452997.1386319187668.JavaMail.root@redhat.com> <437722253.23751315.1386489872297.JavaMail.root@redhat.com> Message-ID: On Sun, 8 Dec 2013, Pavel Simerda wrote: >> But of course, it >> would be better not to have to rewrite /etc/resolv.conf. > > Agreed. > >> The best solution blocks port 53/unbound from resolution on a new >> network until NM has handled the sign-on. > > I don't think I understand the idea. > > 1) We need to keep name resolution on the localhost side working. No. You cannot. When on a hotspot, there is no valid "name resolution" until you have authenticated. Any DNS lookups to applications _should_ fail, because there is no DNS that is trustworthy. This is when the user sees warnings from IM clients or browsers or email clients saying "something wrong with certifiacte" when presented with the ssl variant of the hotspot. Resolution is better of getting servfails until the hotspot has been validated and dns can be trusted. > 2) We need to resolve external addresses via hotspot temporarily. No. _only_ the addresses required for the hotspot authentication should be resolved. > 3) We need to avoid serving those external addresses from the cache when fully connected. Not just "when fully connected". Whenever! >> From my perspective, the best way would be to teach 'unbound' to either cache the hotspot-mode results separately or not cache them at all, which might be even easier. I don't think blocking any unbound communication on firewall can help. > >> This can require a hot >> spot sign on using some browser window that is isolated from any >> running firefox, uses its own resolving - for example using libunbound >> in insecure mode that is terminated with the browser window when done. > > Yes, that would be theoretically possible but unless we really need to do Firefox magic (which we apparently don't), I would rather avoid it. When the only problem is unbound caching during the hotspot registration, then why don't we just solve it there. It's so much easier than any magic and will eventually be more universal. I don't think we are agreeing about what the problem is. I am saying it is a problem if _any_ application apart from the "hotspot signon" is receiveing untrusted DNS that has been specificaly bypassed DNSSEC. >> This would prevent any and all race conditions to our secure unbound >> cache, and would require no resolving. But that "browser window" would >> have to not use any libc gethostbyname() or get_addr_info() calls - just >> libunbound calls. The system unbound daemon would return SERVFAILs until >> its port 53 block is lifted - or it could be put explicitely into "cache >> only" mode. > > Sounds like a solution, but not one I would prefer over simply solving the unbound cache pollution problem. But anyway thanks very much, you helped me to sort my thoughts better. Actually, you can view the "nocache" solution as a simplification of the browser windows solution, as indeed we need to act at the same phases. The only difference is whether we use a separate channel for name resolution, or we handle the caching. Thanks. Right. Paul From psimerda at redhat.com Mon Dec 9 07:06:55 2013 From: psimerda at redhat.com (Pavel Simerda) Date: Mon, 9 Dec 2013 02:06:55 -0500 (EST) Subject: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called In-Reply-To: References: <287421960.22883489.1386172762119.JavaMail.root@redhat.com> <950772235.23088509.1386234704065.JavaMail.root@redhat.com> <690005061.23452997.1386319187668.JavaMail.root@redhat.com> <437722253.23751315.1386489872297.JavaMail.root@redhat.com> Message-ID: <426663104.23863050.1386572815820.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Paul Wouters" > To: "Pavel Simerda" > Cc: "Tomas Hozza" , dnssec-trigger at NLnetLabs.nl > Sent: Sunday, December 8, 2013 8:23:44 PM > Subject: Re: [Dnssec-trigger] dnssec-triggerd behaviour when hotspot_signon called > > On Sun, 8 Dec 2013, Pavel Simerda wrote: > > >> But of course, it > >> would be better not to have to rewrite /etc/resolv.conf. > > > > Agreed. > > > >> The best solution blocks port 53/unbound from resolution on a new > >> network until NM has handled the sign-on. > > > > I don't think I understand the idea. > > > > 1) We need to keep name resolution on the localhost side working. > > No. You cannot. When on a hotspot, there is no valid "name resolution" > until you have authenticated. Any DNS lookups to applications _should_ > fail, because there is no DNS that is trustworthy. Common, there are multiple solutions with their pros and con. And so far you have been using the very solution you now consider impossible. So at least we're not talking about a regression, right? > This is when the user > sees warnings from IM clients or browsers or email clients saying > "something wrong with certifiacte" when presented with the ssl variant > of the hotspot. If the hotspot has an SSL variant at all. And a transparent SMTP proxy. > Resolution is better of getting servfails until the > hotspot has been validated and dns can be trusted. No. That way you would break people's local network connectivity when a false positive occurs on hotspot detection and they would learn to turn DNSSEC off like they learned with selinux long time ago. Breaking users' networking is not part of our plan. We can indeed experiment with various solutions and we can develop a "strict mode" that would (partially) block DNS resolution for all tools except a special browser window, but I would rather see it as the next step and I doubt we will be able to make it default. > > 2) We need to resolve external addresses via hotspot temporarily. > > No. _only_ the addresses required for the hotspot authentication should > be resolved. Again, in the first stage, we must not impact functionality, otherwise we'll teach people to turn DNSSEC off. > > 3) We need to avoid serving those external addresses from the cache when > > fully connected. > > Not just "when fully connected". Whenever! > > >> From my perspective, the best way would be to teach 'unbound' to either > >> cache the hotspot-mode results separately or not cache them at all, which > >> might be even easier. I don't think blocking any unbound communication on > >> firewall can help. > > > >> This can require a hot > >> spot sign on using some browser window that is isolated from any > >> running firefox, uses its own resolving - for example using libunbound > >> in insecure mode that is terminated with the browser window when done. > > > > Yes, that would be theoretically possible but unless we really need to do > > Firefox magic (which we apparently don't), I would rather avoid it. When > > the only problem is unbound caching during the hotspot registration, then > > why don't we just solve it there. It's so much easier than any magic and > > will eventually be more universal. > > I don't think we are agreeing about what the problem is. I am saying it > is a problem if _any_ application apart from the "hotspot signon" is > receiveing untrusted DNS that has been specificaly bypassed DNSSEC. Yes and thank you for reminding me about those requirements that we need to consider when implementing a strict mode. Also, I think we'll need to make larger changes to NetworkManager when implementing the strict mode to synchronize the state of all the tools. Cheers, Pavel > >> This would prevent any and all race conditions to our secure unbound > >> cache, and would require no resolving. But that "browser window" would > >> have to not use any libc gethostbyname() or get_addr_info() calls - just > >> libunbound calls. The system unbound daemon would return SERVFAILs until > >> its port 53 block is lifted - or it could be put explicitely into "cache > >> only" mode. > > > > Sounds like a solution, but not one I would prefer over simply solving the > > unbound cache pollution problem. But anyway thanks very much, you helped > > me to sort my thoughts better. Actually, you can view the "nocache" > > solution as a simplification of the browser windows solution, as indeed we > > need to act at the same phases. The only difference is whether we use a > > separate channel for name resolution, or we handle the caching. Thanks. > > Right. > > Paul > From insertrealname at yahoo.ca Tue Dec 17 05:32:38 2013 From: insertrealname at yahoo.ca (Insert Real Name) Date: Mon, 16 Dec 2013 21:32:38 -0800 (PST) Subject: [Dnssec-trigger] Q: Disable Windows 7 DNS cache service with dnssec-trigger installed? Message-ID: <1387258358.45987.YahooMailNeo@web124506.mail.ne1.yahoo.com> Windows 7 has a DNS cache client service enabled by default, and installation of the Windows version of dnssec-trigger does not disable it. for safety's sake, I flushed this cache after this installation. Since this DNS cache service queries the unbound server at 127.0.0.1 anyway with dnssec-trigger installed, maybe nothing else needs to be done... Advice/explanations gratefully received (I'm no DNS/Windows expert).