I talked with Paul Wouters over IRC about an interesting use of DNSSEC together with other security technologies. Paul wanted to have a possibility to keep all positive answers validated by DNSSEC whenever they would be otherwise flushed by the dnssec-trigger-script because of changing network configuration. Paul might want to explain whether and why he only cares about validated answers. In my opinion it's pretty much straightforward that only positive answers are interesting as negative answers generally have a low TTL anyway. He might also want to explain why this approach is useful as the next step after DNS lookup is typically to connect to the service and the names are often known through techniques like Passive DNS. Anyway, this technique relies on the fact that the user doesn't (1) roam between two (or more) sites with a split DNS view on any of the requested names, or (2) only one of the sites provides a positive answer. Split DNS view with different positive validated answers in different sites wouldn't work correctly and that's why I don't expect such an option to be the default.
By the way I can't think of a better name for such an option than: avoid_flushing_positive_validated_answers (Unless the discussion leads to a change in the semantics.)
Personally I would like to hear Paul's reasons first. When moving from network where provided nameserver had split-DNS configuration to the public network, you might end up resolving named that are not reachable from the Internet. This is not good IMHO.
AFAIK this non-default option is only suitable for people who don't connect to split viewed DNSSEC networks. Also unbound unfortunately doesn't provide a way to flush all non-validated data, so without changing unbound we would have to flush all data anyway whenever there's a chance that unbound has non-validated data, e.g. because it ran insecure for a while. For the future, writing out /etc/resolv.conf in insecure mode is not an option, as we're not only talking about DNSSEC here, but also about split DNS which is a valuable feature even without DNSSEC, for many people more valuable than DNSSEC itself.
I was not talking about non-validated data. I was talking about everything in the cache except negative responses. When unbound goes from insecure to secure, it must always get flushed. In fact, I would say once you are in "insecure" mode, and disconnect from a network, it should flush regardless. (currently, we are sticky on "insecure" which gives me additionals problems when i move around and then bring up the redhat vpn, as in insecure mode the forwarding to the vpn domain is lost. split dns networks must keep their TTLs low, so moving physically should expire those records regardless. facilitating split-dns should be at the cost of privacy. I know privacy is not a simple binary state, so we might have different weights attached to the importance of these. As we have gotten confirmations of pervasive monitoring, and we are trying our best to make it harder on nation states to map our whereabouts, I do believe this is an important issue. The IETF is working on various drafts (eg on opportunistic security) that tries to outline good common practise. Starting from an empty DNS cache every network connect leaves a very distinctive trail. Yes, I will likely make distinctive connections to those IPs, but every bit of anonymity lost makes it easier for a pervasive monitor to fingerprint you. split-DNS is the abnormal deployment (and becoming more and more abnormal as the classical divide between intranet and internet is vanishing). People deploying this should be responsible to make it work. We should not generally sacrifice our security of privacy to accommodate them. Other practical issues are when hitting a hotspot, you get all your DNS not cached possibly mangled. If that gets to the application layer, those applications will attempt to connect to the wrong things, get blocked, and possibly do application level caching of those bad records from the hotspot. I dont get my DNS records mangled by a hotspot if I already have them in my cache. For devices that often connect/disconnect to safe battery power, such as phones and tablets, there will be a noticeable delay while unbound needs to resolve hunderds of records for the common dnssec path of trust records. This could be avoided when not flushing the cache when reconnecting to the same network. As for CDN records, those should also have a short ttl for the above reasons. There is no value in caching negative responses. There is no data to protect, and the only reason it is cached is not to retry these again too soon. Moving to another network means those records have no value whatsoever, and can safetely be flushed. That is why unbound thought this was a good feature and added an option for it. If certain resources are only available within a private network via private DNS labels, then trying to access these on a non-private network will fail regardless of whether this is by DNS entries or by IP address. But I'm happy with a solution that would flush the DHCP obtained domain similarly to how we now flush the VPN obtained DNS domain. Although that won't work for private networks with many internal only domains that span multiple independant domains. I'm happy to think about solutions in this space, for instance some kind of DHCP option that lists the domains we should flush on network exit, provided we authenticated to this network using some form of authorization. It's flushing the entire cache that I have problems with. The real issue is how far are we willing to bend over backwards to accommodate sub-optimal split-DNS and CDN deployments versus optimised DNS caches with a little more privacy. I think the networks involved are the ones that should know the limits of their deployments and run with proper short TTLs. And I think flushing the DNS cache excessively will only lead to more applications doing their own in-application caching that ignore the TTL altogether.
(In reply to Paul Wouters from comment #4) > facilitating split-dns should be at the cost of privacy. I know privacy is > not a simple binary state, so we might have different weights attached to > the importance of these. As we have gotten confirmations of pervasive > monitoring, and we are trying our best to make it harder on nation states to > map our whereabouts, I do believe this is an important issue. The IETF is > working on various drafts (eg on opportunistic security) that tries to > outline good common practise. Starting from an empty DNS cache every network > connect leaves a very distinctive trail. Yes, I will likely make distinctive > connections to those IPs, but every bit of anonymity lost makes it easier > for a pervasive monitor to fingerprint you. If you are going to connect to those IPs then it is really hard to argue that caching will make any difference privacy wise, but it does make a difference functionally wise. I think functioning properly should trump handwavy privacy claims here. > split-DNS is the abnormal deployment (and becoming more and more abnormal as > the classical divide between intranet and internet is vanishing). citation needed, unfortunately it is quite common and even more so in braindead deployments that mimic amazons "private" netowrks in clouds environments, where split view is the norm, and TTLs *cannot* be kept low due to that because only very few clients see both sides of the horizon and the large majority of clients benefits from larger TTLs on the 'public' side of the split. > People > deploying this should be responsible to make it work. We should not > generally sacrifice our security of privacy to accommodate them. This is wrong, nobody is going to care if your Linux client does not work as long as Mac and windows and Android tablets do, so you have to do what works, not what you whish were the "correct" way to configure things. > Other practical issues are when hitting a hotspot, you get all your DNS not > cached possibly mangled. If that gets to the application layer, those > applications will attempt to connect to the wrong things, get blocked, and > possibly do application level caching of those bad records from the hotspot. Application level caching is bad, if one thing need fixing it is that. > I dont get my DNS records mangled by a hotspot if I already have them in my > cache. This is actually a pretty big issue that required me to disable dnssec-trigger quite a few times (until I did it for good in frustration while on vacation and still haven't brought it back up). If you cache enmtries a lot of Hotsposts will fail, because web browser will try to connect to the "right" IP address instgead of the hotspot some intercept any DNS request andf give back the hotspot address but with an extremeley low TTL. I do not like it but it is how it works in some places and if you do not drop the caches you will never get past the hotspot, hardly useful. > For devices that often connect/disconnect to safe battery power, such as > phones and tablets, there will be a noticeable delay while unbound needs to > resolve hunderds of records for the common dnssec path of trust records. > This could be avoided when not flushing the cache when reconnecting to the > same network. This would required selective flushing, you should be able to flush only non-DNSSEC protected records, or have a mode by witch you can "save" caches for later use so that in hotspot mode you do passthrough resolution, and later reuse the saved cache once you are past the hotspot. > As for CDN records, those should also have a short ttl for the above reasons. > > There is no value in caching negative responses. There is no data to > protect, and the only reason it is cached is not to retry these again too > soon. Moving to another network means those records have no value > whatsoever, and can safetely be flushed. That is why unbound thought this > was a good feature and added an option for it. > > If certain resources are only available within a private network via private > DNS labels, then trying to access these on a non-private network will fail > regardless of whether this is by DNS entries or by IP address. But I'm happy > with a solution that would flush the DHCP obtained domain similarly to how > we now flush the VPN obtained DNS domain. Although that won't work for > private networks with many internal only domains that span multiple > independant domains. > I'm happy to think about solutions in this space, for instance some kind of > DHCP option that lists the domains we should flush on network exit, provided > we authenticated to this network using some form of authorization. > > It's flushing the entire cache that I have problems with. Yet unfortunately this is exactly what is needed when a hotspot is encountered or at least somehow temporarily disable reading from the cache. > The real issue is how far are we willing to bend over backwards to > accommodate sub-optimal split-DNS and CDN deployments versus optimised DNS > caches with a little more privacy. I think the networks involved are the > ones that should know the limits of their deployments and run with proper > short TTLs. And I think flushing the DNS cache excessively will only lead to > more applications doing their own in-application caching that ignore the TTL > altogether. Can you define excessively ? How often do you change networks ? It's not like you are going to flush while connected to a network, and a little bit of "waiting" when switching on a new network is generally acceptable by users. By trying to optimize you risk causing "functionally visible" issues that are much worse for the user than the dealy of a few more DNS exchanges when you jump on a new network. Simo.
As I've said before, if you want to design hotspot detection properly, we do: 1 Do not tell any application there is a real network until past hotspot authentication 2 do hotspot authentication in a secure throwaway container so none of this DNS or http content ever leaks to the non-hotspot applications If you follow your logic of sacrificing security for usability or what works today, you're throwing out DNSSEC and IPv6 and a whole lot more and will end up with an interNAT on port 80 for everything. My laptop or phone often ends up switching/reconnecting to a network. Reconnecting to flaky wifi networks at coffeeshops happens to me on a daily basis. Especially when the network is flaky I do not want to have to redo my DNS cache.
(In reply to Paul Wouters from comment #6) > 2 do hotspot authentication in a secure throwaway container so none of this > DNS or http content ever leaks to the non-hotspot applications This would be ideal, but until we get there you need a usable approach > My laptop or phone often ends up switching/reconnecting to a network. > Reconnecting to flaky wifi networks at coffeeshops happens to me on a daily > basis. Especially when the network is flaky I do not want to have to redo my > DNS cache. Surely you do not need to flush the cache if you reconnect to the same network, just if yopu change it ?
> Surely you do not need to flush the cache if you reconnect to the same network, just if yopu change it ? I have not seen anyone mention we are keeping state of the last network to prevent those cache flushes on flay networks. With the introduction of DNSSEC we are breaking all kinds of DNS deployments that were bad and are now even worse. While I'm in favour of supporting those where we can, I am against downgrading the newly gained DNSSEC security for the sake of supporting those broken deployments. With the additional mobility of laptops, phones and tablets, we are often connecting to rogue or unknown networks. We need to be properly protected to safely use those unsafe networks. Networks need to learn, sooner rather than later, that hosts connecting to it have an existing DNS cache with DNSSEC validation enabled.
Sorry Paul, but I was not able to clearly understand what change you are proposing for dnssec-trigger work-flow. Please state *clearly* WHEN and WHICH CACHE would be flushed by your opinion.
My philosophy is that my device is my own. My DNS resolving is my own until I allow a (trusted) network some temporary additional access to my DNS configuration. Such access is temporary and should not go beyond my connection to their network. Flush negative cache on joining any network / VPN Flush entire cache upon joining or leaving trusted network (eg lan.redhat.com) Trusted is physical plug or user setting in NM for wifi/3g, which also allows search/domain in resolv.conf to be overwritten (I previously suggested "wifi passwords" but those are not good enough with hotspots moving to stupid/simple passwords on their wifi hotspots) Flush vpn xauth "domain" cache upon establishing/disconnecting VPN connection ( eg redhat.com) (we currently do that for most vpn types when unbound runs) In all other cases, do not flush cache. This leaves is up to the user to tell us what networks are to be "trusted". It leaves our caching and security enabled as much as possible. If a trusted network has a broken DNS server announced via DHCP, we currently try to resolve directly to auth servers. If that fails (because the trusted network insists going through its DNS servers) we fallback to tcp80 ot tcp443, which likely works, but would fail to see the local domains. We could set a forward in unbound for the dhcp obtained domains (via option "domain-search" and option "domain") to the local IPs obtained via "domain-name-servers". Blindly using the local DNS as forwarder despite being detected as broken will lead to things like DNSSEC validation failures, so we cannot do that. If the above hole poking is not possible we can only go fully insecure. That means bypassing the cache and not validating on the local host itself.This leaves us more vulnerable. We should then inform the user of this scenario (eg trusted + broken = warning and go insecure) so the trusted networkadmin will hopefully fix their DNS setup. When changing networks, we should also flush all RFC1918 in-addr.arpa. Ideally, upon leaving a trusted network we would only flush the domain list obtained via DHCP. I'm okay with flushing the entire cache for now, but would like to revisit this in the future.
We decided to add undocumented option as we think that it should not be used by default and we don't want to encourage users to start using it. The default behavior will be that all cache is flushed on network configuration change. With the undocumented option all cache, but the positively validated cache. We think there is rather small benefit in using it and may cause issues on split DNS configuration with DNSSEC.
please ensure it is a network CHANGE and not a network RECONNECT. If someone is on flaky wifi (happens to be regularly) it would be really bad to have a cache flush every few seconds or minutes, especially because the already bad wifi leads to dns packet loss and cache flushing requires a new round of a few hundred DNS packets to make it through (on a flaky wifi)
(In reply to Paul Wouters from comment #12) > please ensure it is a network CHANGE and not a network RECONNECT. The change we're planning for this bug report is just the change the call to unbound-control. I wanted to provide a way to keep *positive* *validated* answers as the summary says. In my opinion unbound doesn't offer a way to flush all except those, so I think we'll have to step back to keep all positive answers. That unfortunately breaks many split DNS enviornments. I personally would never use such an option, but it seems to be what you originally requested. Can you please confirm that this is what you want to use? > If someone > is on flaky wifi (happens to be regularly) it would be really bad to have a > cache flush every few seconds or minutes, especially because the already bad > wifi leads to dns packet loss and cache flushing requires a new round of a > few hundred DNS packets to make it through (on a flaky wifi) Seems unrelated to this bugzilla ticket, let's talk on IRC.
Created attachment 982675 [details] patch to implement keeping all positive answers The patch should be applicable directly to /usr/libexec/dnssec-trigger-script if you want to test it.
Created attachment 983077 [details] patch to implement keeping all positive answers
No unbound support to flush only insecure stuff, let's be happy with negative ones.
dnssec-trigger-0.12-18.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/dnssec-trigger-0.12-18.fc21
Package dnssec-trigger-0.12-18.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnssec-trigger-0.12-18.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-1279/dnssec-trigger-0.12-18.fc21 then log in and leave karma (feedback).
dnssec-trigger-0.12-19.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/FEDORA-2015-3864/dnssec-trigger-0.12-19.fc22
dnssec-trigger-0.12-19.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/FEDORA-2015-3843/dnssec-trigger-0.12-19.fc21
dnssec-trigger-0.12-19.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
dnssec-trigger-0.12-20.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.