On Thu, 10 Apr 2014, Chuck Anderson wrote: In my opinion, the last remaining hurdle is roaming users and captive portals. Nothing else prevents anyone from running with dnssec enabled per default (and even on laptops, developers can run with dnssec-triggerd and unbound). If you run a server, you should already be running unbound or bind (or dnsmasq w dnssec). I do not know if dnsmasq contains the proper code for being reconfigured on the fly based on network changes, which is a requirement for adopting to DNSSEC in various situations (such as VPNs, connecting to corporate LAN/Wifi with internal-only domains, DHCP/ISP forwarder failures). But libreswan, vpnc and openvpn already have the neccessary unbound reconfiguration code to properly support VPNs (eg flushing the cache for the vpn domain when (dis)connecting the VPN, etc) What is really needed to complete the solution and make it usable for users, not developers, is the proper integration of dnssec-trigger like code natively into NM. That must include captive portal checking (which dnssec-triggerd does) and upstream DNS forwarder checker, with dynamic reconfiguration on the fly. The current dnssec-trigger does a decent job, but its problematic because it is not native to NM. Fedora already hosts the captive portal detection services for dnssec-trigger. It would also need a little anaconda support. When the user is requested to put in a DNS server (for a static server configuration, not dhcp) than anaconda should configure that server as a _forwarder_ in an unbound configuration and ensure DNSSEC is enabled and running after install. For the roaming laptop case, anaconda should install unbound with the NM integrated dnssec-trigger replacement. In a perfect world, where all network applications are NM aware, it would be awesome if NM would launch a secure container to do the probing and captive portal logon using a sandboxed browser window. None of the other applications would even know there is a network. Once the captive portal login has succeeded, the uplink becomes available to all apps and the secure container can be destroyed. This would offer the maximum protection for applications against unsafe DNS, and limit the required acceptance of "DNS lies" to the captive portal login procedure only. The main issue to make this happen has been that we don't have enough resources to convert the dnssec-trigger code into native NM code. Paul

   Hello Chuck, Thank you so much for brining this up.   Totally agree. In fact, recently there have been multiple instances of discussions wherein this exact same topic was discussed and unanimously everyone agrees that for various reasons having a default local DNS resolver running at 127.0.0.1:53 is the best solution. And going forward it'll be even more beneficial. Paul pointed to one of these discussions in his reply. I plan to file a feature/change request for this one. I got caught up with other work this past week so could not do it. Will start with it right away. Thank you! --- Regards    -Prasad http://feedmug.com

On Sat, Apr 12, 2014 at 02:33:59 +0800, P J P <pj.pandit(a)yahoo.co.in&gt; wrote: I think there should be something explicitly about how this is going to work with captive portals that lie about dns in order to get people's web browsers to go to their sign in page.

On Sat, Apr 12, 2014 at 03:06:17 +0800, P J P <pj.pandit(a)yahoo.co.in&gt; wrote: It looks like your proposal is going to break things for people using some wifi hotspots. That isn't good. What is the plan to deal with that?

On Sat, 2014-04-12 at 02:33 +0800, P J P wrote: NM has had local caching nameserver capability built-in since Fedora 12 or something like that. Set 'dns=dnsmasq' in the [main] section of /etc/NetworkManager/NetworkManager.conf and NM will spawn dnsmasq in a local caching nameserver configuration and write 127.0.0.1 to resolv.conf. NM will update that dnsmasq instance whenever your network configuration chagnes to ensure that dnsmasq has the latest nameservers. It seems that 'unbound' is getting more love these days though, due to it's DNSSEC capabilities, and there is not yet a NetworkManager DNS plugin for unbound/dnssec-trigger. I know some people are working on that though (Thomas Hozza and Pavel Simerda) and I'd expect that to show up in the near future. Note that hotspot detection is an important part of this, since hotspots will clearly break any kind of DNSSEC validation that happens, and that's something that's being worked out between dnssec-trigger and NetworkManager right now too. NM in F20+ already has a "dns=none" option that prevents NM from touching resolv.conf, but obviously if NM isn't touching it, the DNS information that NM gets from upstream or your local configuration needs to get to the local caching nameserver somehow. Which is what the existing NM DNS plugins are for, like the dnsmasq one. Dan

   Hello Dan,   That's great. Thank you so much for sharing this information. I'll add it to the wiki page. About the wifi hotspots breakage, I'm still not in the clear. IIUC how they work is, all client traffic is blocked/redirected to a designated server till the time user authenticates/makes payment/accepts conditions etc. This blockage/redirection is probably done on the the gateway or some such entry/exit point, no? Thank you. --- Regards    -Prasad http://feedmug.com

On Sat, 2014-04-12 at 03:35 +0800, P J P wrote: They almost always run DNS interceptors, so that the DHCP server on the captive side always returns the portal's login page for any request, even "www.google.com" or "www.fedoraproject.org" will redirect you to the login page. Obviously that DNS reply will not be authenticated or secure in any way, because it clearly cannot be a trusted reply from google.com. Thus they will break any kind of DNSSEC or any other kind of authentication that the local caching DNS server might do. I think the big issue for me is the use of "trusted" in the proposal. What does that actually mean? Who is doing the trusting? Does it mean that Firefox can "trust" the local caching DNS server, and if so, why would that server be any more "trustworthy" than the upstream nameserver delivered to you by DHCP? If that local nameserver *is* somehow more trustworthy, what specifically does it do to deserve that trust? If it does do something, does that something break hotspot or portal detection and login? Dan

On Fri, 11 Apr 2014, Dan Williams wrote: There are two captive technologies that need to be checked for. One is port 80/443 interception and one is DNS interception. dnssec-triggerd offers those but its integration with NM is poor because it was written as a stand aline daemon+gnone applet. On top of the captive portals, the solution needs to deal with VPN situations and split-view DNS. Unbound handles this with libreswan, vpnc and openvpn already. This also involves flushing the cache when the VPN connection goes up/down. unbound supports all of this via runtime unbound-control daemon reconfiguration and also supports shipped exceptions via /etc/unbound/*.d/ directories. I am not aware of dnsmasq offering these features at all. dnsmasq also only very recently got beta suppor for dnssec, so I am uncomfortable with using dnsmasq for these tasks. The DNSSEC trust comes from a shipped root key that's local to your machine, augmented by installed trust anchoes (eg in /etc/unbound.d/keys.d/). This means all the validation happens on the host and cannot be mangled in transit by an attacker. The alternative is to request a non-local DNS server with DNSSEC support and looking at the answer's AD bit. But this bit is not cryptographically protected, so it assumes a trust in the network. What would be the most awesome solution, is if NM on finding a new network connection, can bring up a secure container with resolv.conf from the DHCP server, do the captive portal tests, allows the user to login in a throw away browser context, and once accepted on the network, and the mangling has stopped, to release the actual network to the rest of the OS and destroy the used container. Paul

On Saturday, 12 April 2014 1:35 AM, Miloslav Trmač <mitr(a)volny.cz&gt; wrote: ...  Thanks so much for the precise responses Miloslav. But, am I the only one to not see Dan's earlier mail? Or was it a different thread?? Thank you. --- Regards   - Prasad http://feedmug.com

Once upon a time, Bruno Wolff III <bruno(a)wolff.to&gt; said: Unless you have a specific reason not to, you should use the DNS server from DHCP. That may be the only DNS server that will work, there may be private DNS info not available anywhere else, etc. -- Chris Adams <linux(a)cmadams.net&gt;

On Fri, 11 Apr 2014, Chris Adams wrote: My specific reason is that I dont trust random strangers. That situation is dealt with, see my other email to the list Paul

On Fri, 11 Apr 2014 16:39:34 -0400 (EDT) Paul Wouters <paul(a)nohats.ca&gt; wrote: ...snip... Me too. :) I hope the NM integration will show up at some point. It's really a pretty nice setup. kevin

On Fri, 11 Apr 2014, Bruno Wolff III wrote: If you don't know there is an exception for a domain (eg at the other end of a VPN) than you will get the public answers and might not get where you need to go. Additionally, with DNSSEC there is the problem that the public view cryptographically proves the internal view does not exist (eg internal.fedoraproject.org) We support that with the VPN software by using the received DOMAIN and DNS servers from IPsec XAUTH and reconfigure unbound on the fly to use the internal servers for that domain (and flush the cache) Indeed, with DNSSEC we can use them as cache, because we can validate the answers. But those servers should never be "trusted". Paul

On Fri, Apr 11, 2014 at 16:59:05 -0400, Paul Wouters <paul(a)nohats.ca&gt; wrote: With an iterative resolver that may not be true. If the route to the name server that has that information is over the VPN (so that you have the correct source address), you should get the right answer. That doesn't get you the right answers though, it only tells you that they are lying.

On Fri, 11 Apr 2014, Chris Adams wrote: Another reason to attempt to configure your locally running DNSSEC resolver with your ISP's DNS servers as forwarder........ Paul

On Fri, Apr 11, 2014 at 17:46:29 -0400, Paul Wouters <paul(a)nohats.ca&gt; wrote: It was a comment about ISPs changing TTLs (or other things). DNSSEC can be used to tell you the data might not be authoritative, but doesn't tell you what the correct information is.

On Sat, Apr 12, 2014 at 02:33:59AM +0800, P J P wrote: Thank you! I think there needs to be more emphasis on the /other/ benefit, the whole reason I brought this up this time: While DNSSEC support has historically been a driving factor for implementing this, there is an even more fundamental need due to the poor performance of the system in case the first listed nameserver in /etc/resolv.conf fails for some reason. It is shameful that Linux systems and applications in general still, after 20+ years, can't perform adequately after a primary DNS server failure. The stub resolver in glibc which uses /etc/resolv.conf can decide that the first listed nameserver entry is down, but this decision has to be made over and over in every single process on the system that is doing DNS resolution, resulting in repeated long application hangs/delays. We need an independent, system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to solve this fundamental design problem with how name resolution works on a Linux system. Windows has had a default system-wide DNS cache for over a decade. It is about time that Linux catches up. I can have a go at adding some text to the wiki.

On Fri, Apr 11, 2014 at 18:44:21 -0400, Paul Wouters <paul(a)nohats.ca&gt; wrote: Not better. That DNSSEC doesn't really solve everythin one might want it to. And hence one might want to avoid ISPs' DNS services in some cases.

On Fri, 2014-04-11 at 15:22 -0500, Bruno Wolff III wrote: Not true, in many networks you want it, for example in corporate networks. You really want to be able to resolve the local resources and they are only resolvable if you consult the local DNS as provided to you by DHCP. For hotspots in public places that doesn't matter as much of course. Simo. -- Simo Sorce * Red Hat, Inc * New York

On Fri, 11 Apr 2014, Simo Sorce wrote: Next time please run sudo unbound-control list_forwards and cat /etc/resolv.conf and see if that locates the problem? The one issue I have is that sometimes I NM fails to write resolv.conf in insecure mode, and I end up with no resolvers. The other issue is that in insecure mode (which you are not meant to run in other than signon or with very broken captive portals)) the VPN forward is added to unbound, but unbound is bypassed during secure mode, so internal resources are not available. Paul

  You mean let local resolver forward queries to the ISP's name servers? That is same as using ISP's name servers in '/etc/resolv.conf'. I wouldn't prefer that without DNSSEC.   -> http://pjp.dgplug.org/ndjbdns/ There is new version of it. It does not support DNSSEC, but is alive and well maintained. --- Regards    -Prasad http://feedmug.com

  Sure; I tried to cover it in the detailed description as === ...Apart from trust, these name servers are often known to be flaky and unreliable. Which only adds to the overall bad and at times even frustrating user experience. In such a situation, having a trusted local DNS resolver not only makes sense but is in fact badly needed. It has become a need of the hour. (See: [1], [2], [3]) === Also, this thread is linked there at [3]. --- Regards    -Prasad http://feedmug.com

There is also the case that Chuck mentioned about ISP's name servers being unreliable. --- Regards    -Prasad http://feedmug.com 

On Sat, Apr 12, 2014 at 15:11:35 +0930, William Brown <william(a)firstyear.id.au&gt; wrote: No, but using a caching iterative resolver does. (Barring the ISP rewriting your traffic.)

On Sat, 2014-04-12 at 14:09 +0800, P J P wrote: Umm what? You cannot have your cake and eat it too. If you flush the cache of interface route change, the entire point you made about trying to no forward to an unreliable ISP is invalid. Consider, I get home, and open my laptop. Cache is cleared, and I'm now populating that cache with the contents from the ISP. But if you weren't to clear the cache, I could be at home caching bad records, then when I go to work they persist. You cannot have both. I would rather that cache is flushed on interface change as it prevents so many more issues than making that cache last across potential network boundaries. At the end of the day, I cannot stress enough, if you have an ISP with bad DNS caching or that is unreliable, you need to fault your ISP, it is not an issue for the OS to solve. -- William Brown <william(a)firstyear.id.au&gt;

  Right.   No, why contents from ISP? Local resolver will populate cache from root servers, no?   This is a glitch that when you are at home the cache still has office domain addresses cached, to which you can not connect, because you aren't connected to the office network. Do I understand it right? IMO, that's not bad cache.   Sure, no contention there. IMO, that could be a feature for NM, to clear local cache on interface change. Because NM is suitably placed to do that.   IMO, local resolver can help here. --- Regards    -Prasad http://feedmug.com

Am 12.04.2014 13:25, schrieb William Brown: no - only if you enter your ISP's servers as forwarder which makes only partial sense because it lowers the effective TTL and you have more and more cahcings between the origin and your machine while some of them may ignore TTL at all a DNS server doing recursion don't ask any forwarder nice, but you need to understand the contents especially point 3 and because point 1-8 it is called "recursion" because you sart to ask the root-servers which tell you "hey i don't konw the address, but i know who knows .com" followed by the server for .com answers "well, i don't know the answer but i can tell you who knows"

On Fri, Apr 11, 2014 at 10:44:31PM -0400, Paul Wouters wrote: I'm proposing that /etc/resolv.conf is never re-written under any circumstances. A local caching resolver should ALWAYS be used and resolv.conf should ALWAYS say: nameserver 127.0.0.1 so that the applications/services don't hang when ONE external server goes down or becomes unreachable. All the "magic" for secure/insecure modes during NTP bootstrapping or captive portals has to happen inside unbound (or whatever caching resolver/forwarder is eventually chosen) and it should never be bypassed. That way the forwarder can switch to a second, third, etc. upstream resolver without applications noticing that the first one failed. Or if it is a full iterative resolver, it will internally handle failed authoritative nameservers without applications noticing. Maybe we should set the file to be immutable after setting it to 127.0.0.1: chattr +i /etc/resolv.conf

On Sat, Apr 12, 2014 at 01:22:32PM +0800, P J P wrote: You cannot rely on DNS2 and DNS3 to be queried UNLESS DNS1=127.0.0.1 fails to respond. This might be a way to mitigate failure of the local caching resolver process, but it is not a way to ensure the ability to resolve internal names from the corporate nameserver. The way to ensure the latter is to configure the local caching resolver to forward to the DHCP-provided nameservers rather than becoming a full iterative resolver.

Am 12.04.2014 15:31, schrieb Chuck Anderson: nonsense - there are so much ISP nameservers broken out there responding with wildcards and so on that you can not trust them and you will realize that if not before after you started to run a production mailserver which relies on NXDOMAIN responses for proper operations there are also a lot of broken DNS servers in general not respecting the TTL - not so long ago we moved one of our servers into our datacenter, changed the TTL to 5 minutes two days before and *7 months* later the DNS of my private ISP answered randomly with the old and the new address other DNS servers out there answered after 7 months still with the old the most broken one just answered with *both* suggesting round robin to the client - problem: the old IP did no longer exist at all how i tested that? by google for public answering nameservers, ask all which i found with a script and finally asked the tech contact of the broken ones why they not start to hire someone with the skills for DNS

On Sat, Apr 12, 2014 at 04:03:14PM +0200, Reindl Harald wrote: I don't disagree that there is lots of broken DNS out there. But realistically, we still need to default to using the DHCP-provided DNS servers as forwarders because there are unfortunately lots of circumstances where this is required to resolve corporate DNS names or to allow captive portals to work. If the local caching resolver is intelligent enough, it can handle the common use cases (corporate DNS resolution, VPN into corporate, captive portals) and work around the common failure modes (automatic cache flushing, switching to iterative mode to bypass upstream nameservers when necessary, using both the upstream nameservers AND iterative queries and combining the results) for us. What we cannot do is have the default be to bypass the upstream DNS resolvers without some way to handle the above cases. If mainstream operating systems started doing that by default, then corporate networks, ISPs, captive portals etc. will probably start blocking DNS to outside servers or redirecting port 53 to their own servers. In fact some already do this. We don't want to escalate the arms race by encouraging this behavior.

On Sat, 12 Apr 2014, William Brown wrote: This currently works for the VPN scenario. When you connect the VPN, and the VPN gives you a domain/nameservers, unbound is reconfigured on the fly with those nameservers as forwards. A cache flush is done on connecting/disconnecting from the VPN for the specified domain. Part of the new proposal for dealing with your scenario consists of two parts. - LAN and secured WIFI that return a search domain and nameserver IPs will be installed as forwaders in unbound. The current content and request_list will be flushed using unbound-control. - open WIFI will do the same only after the user has told NM this network is to be "trusted". The current content and request_list will be flushed using unbound-control. That should deal with flushing internal-only records when not internal and flushing external records when not external. If the internal domain is using DNSSEC, further configuration of a trust anchor override might be needed. This can be done in /etc/unbound/*.d/ directories (commented out examples are present). Possible, this directory structure can be replaced by integrated NM support that reconfigured unbound (or dnsmasq) based on the same information. Paul

On Sat, 12 Apr 2014, Chuck Anderson wrote: Cheers. That's a goal I share with you, but... Currently, to prevent unbound from either rejecting DNS lies or get polluted by accepting DNS lies, is "taken offline" by the system during hotspot signon. resolv.conf is rewritten to use the DHCP supplied nameservers to get past the portal. During this time, all applications are exposed to DNS lies. Once the captive portal is done, resolv.conf is changed back to 127.0.0.1 and unbound is "online" again protecting all applications. If the network is so bad this cannot work, and the user opts to remain "insecure", the vulnerable situation is continued. If the user opts to go "cache only", than resolv.conf is written as 127.0.0.1 but unbound is configured with 127.0.0.127 as forwarder, meaning no new DNS answers will ever come in. As I said in previous posts, the ideal situation to not mess with resolv.conf on the host is to have a disposable secure container get the "new network" before any application gets network, do the hotspot login, and throw away the container. In that case, resolv.conf on the host (not container) never has to be modified. That is the trick currently used by dnssec-triggerd to prevent other applications from messing with that file. Paul

On Sat, 12 Apr 2014, Reindl Harald wrote: That's not what the http://atlas.ripe.net/ data set indicates. Your story seems anecdotal and incidental. Yes, there are a few bad players out there (like Rogers in Canada) but those are in a minority. That said, I agree that using unbound on your servers will reduce upstream DNS outage problems on your servers. I wouldn't run unbound on every VM though. Paul

On Sat, 12 Apr 2014, Reindl Harald wrote: We know and handle a lot more than you think already using unbound with dnssec-trigger and VPNs. Why don't you give it a shot and give us some feedback on how it works for you on your laptop? They needs to make no decision, it has been automated already: https://github.com/libreswan/libreswan/blob/master/programs/_updown.netke... if [ -n "$(pidof unbound)" ]; then echo "updating local nameserver for ${PLUTO_PEER_DOMAIN_INFO} with ${PLUTO_PEER_DNS_INFO}" /usr/sbin/unbound-control forward_add ${PLUTO_PEER_DOMAIN_INFO} ${PLUTO_PEER_DNS_INFO} /usr/sbin/unbound-control flush_zone ${PLUTO_PEER_DOMAIN_INFO} /usr/sbin/unbound-control flush_requestlist return 0 fi [...] if [ -n "$(pidof unbound)" ]; then echo "flushing local nameserver of ${PLUTO_PEER_DOMAIN_INFO}" /usr/sbin/unbound-control forward_remove ${PLUTO_PEER_DOMAIN_INFO} /usr/sbin/unbound-control flush_zone ${PLUTO_PEER_DOMAIN_INFO} /usr/sbin/unbound-control flush_requestlist return 0 fi It even has fallbacks for when not running unbound to do this via editing /etc/resolv.conf - obviously not as preferred as running unbound, but still supported. Paul

On Sat, 12 Apr 2014, Reindl Harald wrote: If we are going to do appeals to authority for making arguments, I've been doing DNSSEC since 2001, ran an ISP between 1995 and 2005 that had 500+ domains, have pending DNS RFC drafts out there, am acknowledged on many more DNS RFCs published, am a member of a global DNS incident response team, member of DNS-OARC, implemented a failover dual-software dual-setup multi-local DNSSEC signed for a TLD larger that .at praised by the entire DNS industry, performed DNS outage post-mortem at one of Canada's largest banks and was one of ten ICANN newGTLD Registry Services panel members evaluting the 1500 new TLD submissions for their technical implementations of DNS and Registry Services. I think I know what recursion means..... Now can we go back to actually discussion technical arguments again? Thanks. Paul

Am 12.04.2014 17:21, schrieb Paul Wouters: than stop repsond with "That's wrong" if i tell someone forwarding != recursion because you should know it better and use correct terms

On Sat, 12 Apr 2014, Richard W.M. Jones wrote: Which is we need native NM integration, and applications telling NM what to do with resolv.conf so only NM modifies it (and provides with overrides to accomodate your "hardcoded" version). Preferably enforced by SElinux. Paul

On Sat, Apr 12, 2014 at 04:40:50PM +0100, Richard W.M. Jones wrote: Bind mount the file to a read-only filesystem?

On Sat, Apr 12, 2014 at 12:06:23PM -0400, Paul Wouters wrote: Of course there would be /some/ state kept. It just wouldn't cache the data, it would only use the state of recent queries and response times to determine if that resolver was dead and start sending those queries to another resolver. It would basically do exactly what glibc's stub resolver does now, but ONCE for the entire system rather than having each process do that independently. I would want this daemon to be as lightweight as possible to minimize any interference with optimising DNS caches, latency, etc. and so that it could be used everywhere, just like systemd is used on all Fedora systems and some form of "init" is used on all Linux systems. Another way to think of this is to separate out the built-in logic in unbound/BIND/dnsmasq/etc. that determines when an authoritative server is dead and apply it to all queries that are made by glibc's stub resolver. Or separate out the logic that glibc uses to determine when a nameserver in /etc/resolv.conf is dead and make that a system-wide daemon. Because things get messy once you start caching on the end-user system. Sure, you can optionally have that messiness (and I'd argue that for Fedora Workstation that would be a sane default) but for Fedora Server I think it is too heavyweight of a solution to run everywhere, and you agreed that running this in VMs is probably not desired. If the lightweight dnslookupd process is configured to forward the request to a local unbound+dnssec-triggerd, then everything from that point will work in the same way it does today with local caching, TTL handling, DNSSEC, etc. But that should be /optional/. I'm arguing that dnslookupd should be on by default everywhere. It doesn't need to do active heartbeats--it could passively watch queries/responses that it is forwarding to the resolver and decide based on that if a server is dead and stop querying it until the next one fails, etc. just like glibc does today. For the use cases you desire with full caching and DNSSEC, dnslookupd shouldn't get in the way. All applications/glibc would query 127.0.0.1, which would immediately forward all those requests to the local unbound+dnssec-triggerd setup. Dnslookupd would only take action if unbound died for some reason (and if there was an alternate DNS resolver to switch to).

On Sat, 2014-04-12 at 13:04 -0400, Chuck Anderson wrote: You can do this today, just write a nsswitch module to handle the host database and connect to it via a pipe from all processes. Citation please ? What kind of messy ? If you properly handle TTLs what gets messed up ? *especially* if unbound is configured to automatically flush caches when you change networks. Can you substantiate what is lightweight for you ? I have unbound running on my machine and it is basically unnoticeable. The resident memory is 15MiB, with the data and all right around the same size of other similar daemons like polkitd system-journald dhclient dbus-daemon, all stuff you already run your servers and I have never heard anybody call them *heavy* weight. Are you volunteering for writing this daemon ? Because if you are not then we are wasting time I would think. I still fail to see what is the point of writing yet another DNS caching (but non-caching) dameon when we already have unbound, and as Paul said, if you really want to, you can tell it to override TTLs to 0 causing it to effectively not cache data. I see no point in writing something new in this area. Simo. -- Simo Sorce * Red Hat, Inc * New York

Actually no. This whole thread has forgotten one major thing ... use cases. Proposal is to add a local caching DNS server to fedora systems. This may or may not accept a DHCP provided forwarder(?). Case 1: Standard home user. Has little knowledge of DNS, and a router provided by their ISP. DHCP provides the laptop with the DNS ip of the router, which then acts as a forwarder to the ISP Case 2: Moderate home user. They have a little knowledge of DNS, and have setup a system like OpenWRT or gargoyle on their router. They have their own zone, .local . This means that their DHCP provides the DNS ip of the router to clients. Case 3: Power home user. They likely have their own fedora router server or some other system setup. They run their own bind / named instance on their network, with their own zone or two. They have DHCP setup, perhaps to use DDNS updates to named. Case 4: Small business workstation. Likely the small business, like the power home user, has their own name server. It may be Windows DNS from AD, or bind. Case 5: Medium / Large business workstation. It's nearly guaranteed that the business runs their own zones. They have their own extensive, well organised bind / named setup. Case 6: Fedora server in a small business: Same as the workstation, likely AD or bind in the office. Case 7: Fedora server in the large business. Same as the workstation. Case 8: Road warrior to the power home, small business, or large business. Uses VPN, and needs access to the DNS provided by the push dhcp / dns options from their vpn tunnel. Now, in all of these cases the system local DNS cache *must* forward to the local DNS server. You can't at the OS distinguish between any of these cases with just the DHCP record or lease. It is unreasonable to ask everyone to manually setup DNS on every network they join. You must have the forwarder set to the DNS provided by DHCP so that you can access the local network resources. You cannot suggest bypassing these. Case 1: The user doesn't know much about DNS. the ISP might be reliable or unreliable. If we assume as discussed that the cache is flushed on network change, they will have an empty cache. With a good, ISP, they will get consistent answers to queries, and there is no point to having the cache. If the ISP is unreliable, they will get records that are incorrect (See broken TTLs etc), or no record at all. The cache will only help once a record has been returned once, and will only aleviate pain "later" in the session. So DNS caching *may* help here. Case 2: The user does know a bit. But when they change name records they may not be able to solve why a workstation can't resolve names like other clients. We don't want to give Fedora the same name as Windows, where you need to turn on/off the network interface all the time to solve issues (to flush the DNS cache). In this example, the user wants their router to (maybe) cache the records, and to absolve this from clients. Case 3: This user does understand DNS, and they don't need DNS cache. They have bind / named setup, and they would like to rely on that instead. When they change records in their local zones, they don't want to have to flush caches etc. If their ISP is unreliable, or their own DNS is unreliable, a DNS cache will potentially mask this issue delaying them from noticing / solving the problem. Case 4, 5, 6 and 7: DNS cache, again, isn't needed. The infrastructure is well setup, and caching is done by the business servers. DNS outages at the business level, mean there are other issues and they will likely be resolved quickly. You don't want to reboot / reset interfaces for each time you make a change or as the first result of an issue (Again, this would give fedora a bad name). DNS caching may mask a bigger problem. Case 8: Vpns are a bit unreliable, and have relatively high(ish) latency. But mostly they are quite good, ie openvpn. DNS cache *might* help here in case of traffic loss. Again, this would be masking a greater issue though, and could be better solved with TCP dns queries rather than UDP. Only case 1 and 8 have real reasons to use a local OS dns cache. However, you can not distinguish these from the other cases at a network level. IE you couldn't make the cache easily enabled / disabled based on some network parameter. Additionally, case 1 is only needed in the situation that you have a low quality connection, or a low quality ISP forwarder. Both of these are issues you should take up with your ISP, and shouldn't be solved by Fedora. Case 8 with the VPN, is inherently hard to fix. VPN reliability is always improving and I think it's becoming less of an issue. I would also say it's a "rarer" use case than the others. In conclusion, I don't percieve that a DNS cache in Fedora is a good idea, as it solves few real world problems, and may in fact create issues, mask issues and create a bad stigma about Fedora network reliability. If it is to become available to users I would like: * DNS cache is not the default. It bust be enabled on a connection (IE user's in case 1 can enable it if needed) * DNS cache should be able to be enabled from the NM Gui * DNS cache should be able to be flushed live from the NM Gui * DNS cache should be flushed on route or interface state change. * If two interfaces are active, the default route DNS cache setting takes precedence. -- William Brown <william(a)firstyear.id.au&gt;

On Sun, 13 Apr 2014, William Brown wrote: That was in response to someone using appeal of authority statements, not factual discussions. Yes. It depends on the "trustworthiness" of the network and or preconfiguration of some of your own networks you join. Works reasonably well with unbound+dnssec-triger, could use better NM integration for captive portals. Same if their wifi is closed (eg WPA2), will need an exception in NM if their wifi is open for the .local forward. Same as above. Same as above. When connecting to their LAN or secure wifi, same as above for one one forwarding zone. Multiple forwarding zones would need to be configured. It if is an enterprise, they might need their corporate CAs as well as their zones configuration, so a corporate rpm package would make sense. Same as previous Same as previous Same, already works if you only need the one domain that is negotiated via the VPN (eg the IKE XAUTH domain). We are not suggesting that for LAN or secure wifi. In those cases the forward will be added. However, you don' want those forwards for open wifi or else I can bring up "linksys" push you a forward for your internal.domain.com and mislead you into thinking you would be going over your VPN. The cache is never fully flushed. It is only flushed for the domain obtained via DHCP or VPN, because those entries can change. They are not changed for anything else. If the upstream ISP could have spoofed them, so be it - the publisher of the domains could have used DNSSEC to prevent that from happening. There is no such things as "broken TTLs". And there is no modern nameserver that believes or honours TTLs for months. The unbound default is cache-max-ttl: 86400. Nothing will be cached for more than one day regardless of the TTL received. Again, if a publisher of a zone wants ISPs to keep their hands of their records, they should use DNSSEC and sign their zone. While we could flush the entire cache on (dis)connect, I think that's rather drastic for this kind of odd use-case. If the user runs their own zone and their own records, they should know about DNS and TTLs. But even so, NM could offer an option to flush the DNS cache. That depends. You need caching for DNSSEC validation, so really, every device needs a cache, unless you want to outsource your DNSSEC validation over an insecure transport (LAN). That seems like a very bad idea. They can. DNS caches are chained. There is no reason to say you cannot run your own cache and have a network based cache. This is becoming really contrived. Again, if you think this is a real scenario (I don't think it is) than you could run unbound with ttl=0. But a requirement of automagically understanding what a local zone is and automagically understanding when a remote authoritative dns server changes data, and not willing to enforce that with ttl=0, and using that as argument why any solution of unbound to provide a security feature (DNSSEC) is getting a little unrealistic. If you want your laptop to start validating TLSA and SSHP and OPENPGPKEY records, you need DNSSEC validation on the device. The question should be "how do you change your network requirements to meet that goal". Yes, enforcing security comes at a price. Let me use your scenario based on TLS. You want to be able to change your TLS certificates and the private CA you regenerate at any time, without any browser on your network ever giving you a popup warning. You know you cannot ask this - it goes against the security model. The same applies for DNS with DNSSEC. The security demands we need to do validation and caching and we should try to make that as flexible and painless as possible. Again, DNSSEC validation on the device requires caching. I don't really understand this paragraph. The VPN cases aleady work very well in Fedora. I seamlessly connect and disconnect from the redhat VPN. Resources that are available only via the VPN are never blocked by wrong DNS cache I got from when the VPN was down. VPNs are a non-issue. I believe you will need to re-think that in light of running a validating DNSSEC resolver on your laptop or servers. You cannot separate dns cache from DNSSEC. DNS caching is not a problem, it is a feature. If you don't want your records cached, use ttl=0. Paul

On 2014-04-12 16:12 (GMT-0400) Simo Sorce composed: What daemon did I go out of my way to run? Simple without X running, where I normally perform my elementary configuration chores in an OFM? When I install, I install minimal, so there is no X available to tweak the installer's defaults. Maybe so, but then some of us don't need our networks "managed", only just configured at installation time, after which they are left untouched for the remaining lifetime of the installation. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

On Sun, 2014-04-13 at 06:35 +0200, Reindl Harald wrote: That is the WHOLE point of DNSSEC, really. It is not necessary, integrity protection allows me to find out if my traffic is getting through or not. If not, though luck. If you need to ask this question I think you missed the whole point of DNSSEC. Caching DNS is common on many OSs, it is nothing special really. Oh yeah, you have to. You may decide you do not like it. That is fine, but DNSSEC does change things slightly and, IMHO, for the better. Just to answer William too, I do not think you brought any evidence that this would not be a good default. On the contrary in base OS we've felt for a long time now the need for it. It is a pain to do without a decent cache, and nscd is not it! A way to toggle it on and off is not a bad idea, but I do not think it needs to be a requirement. Turning off the unbound service is not exactly difficult. I totally agree there should be a way to flush the cache, I am not sure it makes sense to have it in the GUI, certainly nm-cli (or other command) should offer it. I do not see why, the only reason to flush a cache is when there is a DNS change (new interface, eg VPN coming up, or going away) This would break VPNs, which are often not the default route. What you want is to send arbitrary queries to the default DNS, and have forwarders per domain for special interfaces like VPNs (unless in the configuration you establish that all DNS traffic should go over the VPN when you connect). That's a different cache, however if you feel strongly you will be able to turn off the local caching dns server on your machines, at your option. Forwarders are pushed via DHCP, not caches. Which is useless in the *general* case. You may think your physical security is perfect, that;s great, but for everybody else, trusting the network is not ok, that's why more an more people de[ploy TLS or GSSAPI in internal networks too. The era of the clear text trusted private network is coming to an end, whether you like it or not. Let me troll a bit, this is why you do all your banking without HTTPS ? :-) I am strongly in favor of a DNS cache on Fedora, and I would even seriously consider any proposal of making it the default on Fedora Server too. Regards, Simo. -- Simo Sorce * Red Hat, Inc * New York

On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote: About the above 2, can you explain *why* ? A bunch of people here, feel that it would be a great improvement, you keep saying it is doomsday, yet I haven't seen a concise explanation of why that would be (maybe I overlooked, apologies if so). So you will be able to do the same by setting 1 configuration option in unbound, or you could disable the resolver entirely. Can you tell why *everybody* should have the cache disabled by default ? Paul mentioned the single configuration option need to make your resolver tweak the TTL locally, what else do you need ? And again why your preference should be the default ? What compelling arguments can you make ? Simo. -- Simo Sorce * Red Hat, Inc * New York

Not really: Every network you join, you have to semi-trust. If you don't trust it, why did you join it? There are too many cases where the network admin is correct, and does the right thing. It's more the exception I think that the network is truly untrustworthy. But you can't account for every captive portal in the world. This is why the cache is a bad idea, because you can't possibly account for every system that is captive like this. What if I call my network .concrete. Or .starfish. Or any other weird thing I have seen on personal networks. Again, you cannot bypass the local network DNS as the forwarder. You must respect it. How do you plan to make this work? You can't magically discover all the DNS zones hosted in an enterprise. At my work we run nearly 100 zones, and they are all based at different points (IE, a.com, b.com, c.com.) You cannot assume a business has just "a.com" and you can forward all quieries for subtree.a.com to that network server. Again, you *must* respect the DHCP provided DNS server as the forwarder else you will savagely break things. You can negotiate more than one domain on a VPN .... again, see above. This is a more serious problem, than a caching resolver could hope to solve as it shows malicious intent. No no no!!!! You need to flush *all* entries. Consider what I resolve www.google.com to. That changes *per* ISP because google provides different DNS endpoints and zones to ISPs to optimise traffic! So when I use google at work, I'm now getting a suboptimal route to their servers! So that's a valid point: A non-caching unbound that caps TTLs is a good idea, but as you say, you can't stop a dodgy ISP. But this isn't even an odd use case. There are enough power users in the world who do this. It's not just computer enthusiasts, I know a chemist who did this, and others. You can't just assume a generic case, and then break it for others. If your lan is insecure, you have other issues. That isn't the problem you are trying to solve. But you don't *need* it. I went to efforts to setup my own bind to cache, I shouldn't need it on my system. Again, local caches cause all kinds of issues. A home user is likely to toy with things and set a high-ish ttl, say even 10 minutes, and change records on their server. Then their records appear broken, because the local cache isn't expired yet. It's not contrived: This is a common network setup for all the people I know who are enthusiasts or how they setup their home networks. This is why it's a use case. The issue is that by adding DNSSEC in this way, you are going to cause a great deal of pain because these caches. Add DNSSEC, but if you need to cache, cache for the most minimal time possible. It's linked to the other cases. It's the point that local system caches aren't needed as you have access to highly reliable DNS systems. Additionally, business networks are "trusted" so you can trust their DNS caches etc. (to a point) Consider a business with external and internal DNS zones. This becomes an issue in this case. If you have cached say "website.example.com" to the external IP, and that is DMZed somehow on the internal network, when you change to VPN, you need to use the internal view of that zone instead. But you can't the name is cached. No, cache is not a feature. It's a chronic issue. Look at windows systems that service desks around the world always advise the first step is reboot: Why? Flush dns caches (Or other things). When you can't get to a website? Restart the webbrower, to flush the cache. Intermittent network issues for different people on a network? The cache is allowing some people to work, but masking the issue to them. It's not allowing people to quickly and effectively isolate issues. DNSSEC is a good idea: Caches are a problem. If this really is to be used, I cannot stress enough, that a cache must be completely flushed every time the default route or network interface changes. You can't, and I can't possibly conceive every network setup in the world. If you make assumptions like this, systems will break and fedora will be blamed. -- William Brown <william(a)firstyear.id.au&gt;

On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote: PS: It also seemed like the proposal was to *bypass* the networks provided forwarders from DHCP. This *is* a serious issue if it's the case. -- William Brown <william(a)firstyear.id.au&gt;

William Brown wrote: If the admins on that network configured a five-minute TTL, it's because they *want* the clients to cache the records for five minutes. They can set the TTL to zero if they want the servers to be queried for every single lookup. And if they're migrating a system they will know this more than five minutes in advance, so they can set a zero TTL temporarily. -- Björn Persson

On Sun, 13 Apr 2014, William Brown wrote: You don't always control which networks your device roams on. If I agree to starbucks at my street, my phone will connect to any network named starbucks, even if it is yours. So to draw the line between the user _knowingly_ joining a network, we drew the line at "plug in physically or provided the authentication credentials". Yes we can by monitoring for "captivity signs" when a new network is joined. Again, please yum install dnssec-trigger on your laptop and start the dnssec-trigger applet once, and go have a coffee outside. Let us know your experience. We will! If your DHCP has: option domain-name-servers 10.1.2.3; option domain-name "starfish"; Then unbound would get a forward configured to use 10.1.2.3 for the domain .starfish, basically calling: sudo unbound-control forward_add starfish 10.1.2.3. sudo unbound-control flush starfish sudo unbound-control flush_requestlist When you leave the network, forward_remove is called. sudo unbound-control forward_remove starfish sudo unbound-control flush startfish sudo unbound-control flush_requestlist If you are that large a business, you should really have a corporate build rpm package with your enterprise information such as local CA, local zones, etc. DNS forwarder zones can be dropped into /etc/unbound/*.d/ currently. I would expect we would make this software neutral via NM integration, where an NM unbound plugin would use those directories. We could add a per-network option that specifies to use a forward for "." (everything) instead of just the DHCP specified domain, or perhaps even do this for trusted (see above) networks. However, that should not be the default for open wifi networks for security reasons. And not doing anything will cause people to have insecure DNS. So I think the question should be turned around a little bit. There is a need for DNSSEC on the end nodes - how can we best facilitate that while trying to be as supportive of current deployments as we can be? That is what we are trying to do. If you only counter with "I require insecure DNS for my network to function" or "all cache is evil", than you are not openminded enough to the realities of the requirement of DNSSEC support. not with IPsec/XAUTH. If more domains can come in via openvpn or something, that I would assume the existing openvpn unbound plugin already deals with that case. If not, please file a bug and we will fix it. I'm sorry I don't understand what you are trying to say here. google publishes TTLs for that which are honoured. If google requires different records when you switch ISPs, they need to use shorter TTLs. The publisher decides here, not the consumer. Additionally, to resolve these issues, there is a new draft that has been implemented by some (such as opendns which specifically has this problem at a large scale): https://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-02 So I consider this a solved problem, even if code and deployment is not there yet at this moment. Actually you can! A captive hotspot is not much different from a dodgy ISP. unbound tries its best to not use any DNS server that messes with DNS. So ISPs like Rogers who like to rewrite DNS packets are explicitely not used by unbound - it prefers to become a full recursive server without offloading to any forwarder if the forwarder is that malicious. We even run DNS resolvers as Fedora infrastructure that provides DNS over TCP-80 and DNS over TLS-443 as alternatives to work around these broken ISPs that also block port 53 in an attempt to force you to use their DNS lies. If you are changing DNS records, you need to understand TTL and cache flushing. If you don't than sure, you can be the clueless windows user that reboots their machine. I care much more about some of the more realistic use cases of fedora machines connected over 3G, where latency matters and flushing the entire cache would cause both more traffic and more latency. And things like pre-fetching where we renew cached DNS entries that are still being served from cache, to avoid the outage when the record expires. Yes it is. When I'm at the coffee shop, my LAN is insecure. I don't want to trust DNS answers coming in. I want to validate those using DNSSEC on my own device. So I need to run a validating recursive (caching) nameserver for very valid security reasons - so that the guy next to me cannot spoof paypal.com. See above where the same argument was discussed. But also, you would have the exact same problem on many devices on your network that won't throw away that DNS record immediately. In-browser caches, OSX system wide cache, and who knows what your PVR, game console and TV do these days. If this worked for you in the past, you were lucky AND you engineered this to work. If you handed that solution to you unknowledgable chemist, it's time to update their solution to meet the modern demands of facilating to use DNSSEC on every device. I suggest you keep a close eye on the IETF HOMENET people, because DNSSEC is coming into your home automation one way or the other, and if you depend on this system, you will run into trouble into the future. As I argued in the last few days, I do not see this "great deal of pain" and I've provided an unbound workaround for you, and your corner case can be dealt with via a new NM option. You will just have to come to term with the fact that caches are needed when you are doing constant DNSSEC validation. So your argument that caches are not needed might have been true in the past, but is no longer. Now let's work on ensuring your exception cases can be supported in the precense of caches. Business networks are never compromised? But as I stated, we already said we will do the forward using the DHCP supplied nameserver in case of a LAN or secured WIFI connection. Which is why we flush the cache for the domain in question when we detect a network change. See the above unbound commands used. This is a solved problem. Every day, when my VPN is up I reach bugzilla.redhat.com on its internal IP, and when my VPN is down I reach bugzilla.redhat.com on its external IP. Without any manual intervention. It just works. Then please let us know what you intend to replace DNS with. The reason DNS has worked for over 20 years is because it is a caching system. If DNS cache was the only cause for Windows machines to need a reboot, I'm sure Microsoft would have fixed that by now. Let's remain honest here and say there are a 1001 reasons why Windows users reboot their machines. DNS might be one of them but it has no relationship to the discussion we are having right now. We disagree. Consider some of the options I suggested for addition to NM to accomodate your scenario, or suggest alternatives. If you are believe the only solution is "no cache ever", than there is not much more we can talk about. And if the majority of fedora users prefers an insecure no-cache over a DNSSEC-cache solution, I guess I will go elsewhere and stop running Fedora. Paul

On Sun, 2014-04-13 at 16:29 +0930, William Brown wrote: I keep seeing this repeated by you and Harald. I am truly in awe that your networks are *secure*, however that is not the common case, networks are routinely breached by zombified machines or are insecure by default (wifi, or very large networks where anyone can plug in). Basically if any of the machines on the network can be compromised the network is not secure anymore. Finally you can't certainly trust network as large as common ISPs. All these networks need to be treated as insecure by default. You cannot trust a DNS server not on your machine to do DNSSEC resolution for you or, as soon as you want to start using DANE, TLSA, etc.. you are a sitting duck, and people will be able to MITM you extremely easily. The default needs to cater for these issues. But of course it is just a default, on your network you'll be able to change the resolvers however you want. The only thing I agree on is that the default MUST use the forwarders provided by the local DHCP unless the user explicitly configured otherwise. Simo. -- Simo Sorce * Red Hat, Inc * New York

On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote: As mentioned unbound does flush away the specific domains, so I will write this one off. We can discuss the fine tuning for sure but it is not a general concern. Just like about everything, I will write this off as well as I've seen lack of caching causing the same difficult to diagnose issues (two collaborating application getting different IPs for the same service and inconsitencies between the 2 endpoints causing odd results). So I do not think this is a generally valid concern, in the sense that the benefits outweight the potential issues IMO. Not really, it would reduce unnecessary traffic, and give you for free a bit of server affinity in general a good thing for most cases. Whether it is *needed* or not depends on the situation, however my sensation over many years is that a cache would bring more benefits than not. I have had a lot more issues with flaky networks on machine w/o a cache than one those with a cache, browsing in particular becomes erratic on networks with high packet loss or flakey DNS server when you do not have a cache as UDP packets are easily lost while TCP connection can retry and recover more quickly, so the DNS is the one that causes more issues and delays for the browser. If the TTL is 5 minutes, the cache will expire in 5 minutes too. And tey will do the same with a local cache, local caches *will* respect TTLs of course! And some people want unicorns, nobody prevent those people from disabling this default. My personal experience is that these are rare events and are not that important, and can be properly handled by admins by lowering the TTLs in advance of a planned outage by bringing them down to very short timeouts or even 0. And also a source of benefits, as always it is a matter of balance, and with the advent of DNSSEC I personally think the balance has definitely tipped in favor of a *default* local resolver cache. (note: the *default*, it means it is not bolted on, you can easily replace it like you do for other services, for example the first thing I do on my machines is to throw sendmail out the window and bring in postfix, it's not a big deal, kisckstarts makes it trivial too). I think the default will be to forward everything to the DHCP provided nameservers, and forward to specific servers per specific domain on resources like VPN (unless otherwise configured, and there are already knobs for that). I guess you do not travel much with a laptop on unreliable networks, there a local cache makes a big difference. I think it is a great default for workstations, and debatable for servers if it weren't for DNSSEC, which again makes it a good default for server too. If you want machines on your network to not cache locally much, just change your local DNS servers to change TTLs to 0 or a very low amount, problem solved. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York

On Sun, 13 Apr 2014, Richard W.M. Jones wrote: Installing for a static server, even if not running NM, should be no problem for the DNS case. The DNS your put in via kickstart/GUI will be configured as a forwarder for unbound. No need to do anything. Paul

What is a "captivity-sign" as you so put it? Okay, so lets expand this to my workplace, that run's a University network. We have thousands of students connected. Now, we have many zones on our network, from services.university.edu university.edu, medicalcenter.org, ersearch.com etc etc. We can't possibly put all of these into our "domain-name" dhcp option. iirc it's a single value attribute anyway. So how does unbound handle this? Does it bypass my network DNS servers completely for everything that isn't university.edu or a child of? IMO that's not acceptable behaviour. See above: We can't possibly hope to deploy such a package to students and staff with bring-your-own-device. How do you propose we populate all the needed forwarders for our students (Such, maybe only a few hundred use linux / fedora - but it will cause them to have a negative view of the OS. Sure, lets agree we "need" dnssec, and that follows that we need cache. Set cache times to be deliberately low so that silly network admin's don't break things (Even 300). Don't try and by pass the local network DNS: There are more network configurations in the world than you or I can contemplate, and bypassing this *will* break things for people. See also my comments about internal and external zones on a network. If you want to cache, then you can't assume that what I cache on network A will be valid on network B. Consider the home user with the dodgy ISP that set's all TTLs to say 30 days. Do you want that user to take that cached entry to a working network and be using that cache for 30 days? (Or whatever unbound sets it TTL max to.) But you can't really tell what's a dodgy DNS and what's not. There are plenty of good ISP's with well configured DNS systems that you *should* use as a forwarder. Again, you can't determine what zones exist in this DNS server so that you can use it "just for those" and bypass it for all else. Consider also, that some ISP's force all port 53 traffic to their own DNS servers too. How does unbound know when the ISP is forcing this? Essentially, what I'm hearing at the moment, is that the proposal isn't just a caching DNS server: It's a DNS server that will be: * DNSSEC * Caching * Attempts to always bypass my local DNS forwarder. DNSSEC doesn't solve the coffee shop problem: You're still on open wireless and there are plenty of other attacks you are still vulnerable too. Sure it helps. But this is DNSSEC helping, not the cache. That's deflecting the point. The first advice when you can't access some website or service foo, is to reboot for this reason. I'm glad that the NM integration is being considered, that will help. I might not be afraid to touch a CLI, but I do think of users who use the GUI only. I think that at the end of the day, there are just too many network setups than we can both contemplate. Some of them will be ready for DNSSEC and systems like unbound when the time comes (As stubborn as I may seem, When it becomes default, I will try and make my systems work seamlessly with the OOB defaults) Consider how many networks don't advertise all their domain names via DHCP. How many networks have more than one zone that unbound can't magically discover. How many networks have split views. These are all reasons to flush the cache on interface state change, because the world won't magically make their networks "perfect" for fedoras sake. We need to work in a world of various configurations ranging from sane to insane. DNS as a caching system has worked, because the caches on networks don't move. They have one view of the world and they don't move. If you have a laptop or other system that moves around, and you take that view of the DNS world with you, things will become screwy and might break in subtle ways that ordinary users can't explain. In summary, all I ask is that: * If a forwarder exists on the network, unbound uses it for all queries. (You can't know all the internal zones it's holding, and often they are not all advertised). * If that forwarder returns an invalid signed DNSSEC zone then you bypass it for only that zone. (IE the zone is being tampered with) * Unbound flushes it's cache between interface state changes, because you are moving between networks with different DNS views of the world. * That you keep the DNS cache time short, to help avoid issues with DNS admins who forcefully increase TTLs. Consider google, with the TTL of 300. Perhaps even set each cached record to have a cache time of ttl or 3600 which ever is lower. Im trying to think about the "user experience" of fedora here rather than a technically perfect world. These suggestions will eliminate all the concerns I have with this system and would hopefully make the default experience better. :) -- William Brown <william(a)firstyear.id.au&gt;

On Mon, 2014-04-14 at 00:42 -0400, Paul Wouters wrote: This seems like a sane(ish) method of doing this. What happens if the hotspot page is down? Why not use a mirror-like setup with yum where you try 2 or 3 mirrors and if they fail then you declare it to be a portal? This point was not made clear. Will summarise at the bottom ... *how* can you tell if it's dodgy. You can tell captivity from above, but you can't easily see if an ISP is say TTL tampering or data tampering? How do you setup DNS over TLS? Again, how can you guarantee that the fedora infrastructure won't go down? My devils advocate points out we are adding more reliance on "third party" infrastructure here. Could it again be a case similar to the mirrors where you can "become" a fedoraproject DNS node to help load balance? It's not as much the case, which makes me happier, but I want to know the conditions on which you decide a DNS server is "dodgy" or not. Agreed. Okay. Can this point be made clear on the proposal page? Also the conditions for Physical wire, and secured wifi? There are also a number of tethering situations that may actually be mis-interpreted as secure. IE my phone has a WPA2 hotspot with DNS that goes via 3g. How does unbound treat this? It would only see the secure wifi ... Consider also some wifi hotspots have their own "local" zones that are needed, so again, I do think that unbound should use the local forwarder irrespective of network security, because else you may risk breaking things. Or how would you suggest this is solved. For arguments sake lets say: SSID: myawesomeopenhotspot DHCP provides no domain-name info. I CNAME all records to my.hotspot. until authenticated. Your hotspot test will be triggered, but if unbound won't use the local forwarder, you won't be able to resolve my.hotspot. on the insecure wifi. Okay that makes sense. okay, but lets combine these two points. My ISP mucks with the TTL of some website from say 300 to 30000000. Unbound would respect this to that amount, or to the TTL max (Which is still 86400 iirc). If you aren't flushing the cache between networks you could end up with: * Suboptimal routes causing a poor user experience. * Incorrect cached zone data moving between networks with different DNS views of the world. Ignoring the TTL change, lets just look at flushing between network state change. This would solve both the dot points listed. You only need to rebuild the cache on first network reconnect meaning: * You are caching for that session the correct results as that network sees them. * You get the TTLs for that network (Even if they were tampered with) * You don't take that data to other networks. Alternately, consider a per-network cache? IE on one network I build a named cache for that network, when I join the other I use that cache. This way the cache: * Persists across interface changes * Keeps sane zone data in each network environment. This would also solve my 3g WPA hotspot case, given the cache built on the hotspot doesn't polute my work wifi for example. Thanks. That's what these mailing lists are for, even if it can end up in essay length posts. At the end of the day, I'm sure we both want the best user experience. In summary (Possibly something to add to the wiki) * Unbound does captive portal detection. Detail how it's done (See above in this email) * Unbound tries to find dodgy DNS servers. Detail how this detection is done. * On an open (Insecure) access point, unbound bypasses the local forwarder, except for names listed in the single valued attribute "options domain-name" from dhcp * On a secure network (Encrypted wifi, lan) unbound will use the forwarders as provided by DHCP. * Unbound will flush the cache between authenticated networks. (If I read your last point correctly) Sincerely, -- William Brown <william(a)firstyear.id.au&gt;

On Mon, Apr 14, 2014 at 02:07:07PM +0200, Juan Orti Alcaine wrote: The NTP Bootstrapping problem is well known. There is an effort to deal with that here (in the context of dnsmasq DNSSEC on OpenWRT/CeroWRT): http://comments.gmane.org/gmane.comp.embedded.cerowrt.devel/2244 Search for the word "prototype" to find a description of one implementation. "The nice thing about this switch to dnsmasq is that it does validation of the chain, just ignoring validity times; which presumably would make it harder to exploit as you'd need an actual valid key, rather than just be able to spoof the packets reply of the non-validated query.." There are many other ideas in that thread.

I meant for say bind, but okay. IE, If I have an out of box bind9 setup with a few zones, or even 100s of zones, these cases should never be triggered. I would hate to see the "dodgy DNS" check giving a false positive on networks that are actually sane ... Such checks need to be conservative in their triggers IMO. Thanks. It actually is quite common from certain Australian ISPs .... especially the "cheap" ones (You get what you pay for ... ) Even if we ignore the TTL mangling, the first issue of incorrect cached zone data moving between networks is a real world issue IMO. As previously mention, split view business networks. I believe you have said this is solved by flushing "." forwarder between networks that are "secure". Okay, This is another point to make clear on the wiki. I thought this was what you were saying was the case on open wifi. Again, can you on the wiki detail the "functional" requirements. The reason I ask these are documented, is so that when other network admins (like myself) come along, you have already had the argument and provided the justification and detailed explanations of these "edge cases". Moved ... These two statements really seem to contradict. On one hand you say that moving between secure networks, the "." forwarder gets flushed. But then you say the whole point is that it isn't flushed! On my 3g tether, and work, both would be secure wifi, so according to this both flush (Which really, I like :) ) But according to what you are saying they shouldn't do that, but they do? Really, it seems like the only time the cache *won't* flush is when I move from a secure wifi to an insecure wifi. What happens when I move from the insecure wifi back? I would like to argue that given not all domains have DNSSEC yet, you can't "trust" the records from the insecure wifi, so at the least on insecure wifi interface down, you should flush the non-dnssec cached records. Which collecting this seems to mean (Current functional state): Secure to secure network -> Flush "." cache. Secure to insecure network -> Keep cache Insecure to Insecure network -> Keep cache Insecure to secure network -> Keep cache. I think in the perfect world, assuming that insecure networks are insecure shouldn't it be? Secure to secure network -> Flush "." cache. Secure to insecure network -> Keep cache Insecure to insecure network -> Keep DNSSEC cache only. Insecure to secure network -> Keep DNSSEC cache only. But considering split horizon private secure networks etc, shouldn't it really be? Secure to secure network -> Keep DNSSEC cache only. Secure to insecure network -> Keep DNSSEC cache only. Insecure to insecure network -> Keep DNSSEC cache only. Insecure to secure network -> Keep DNSSEC cache only. The only records you can really guarantee as being the same on all network views are ones signed by DNSSEC. From the secure networks you may have internal views, and on the insecure networks you can't trust unsigned records. And IIRC there are DNSSEC split view functions too which may not even let you cache the DNSSEC records anyway .... It gets messy very quickly when you start talking about moving a cache with specific, limited views of the DNS world around between sites ;) Sure, this won't affect "every person ever who uses fedora", but it will really annoy they ones who get affected by it. Some people will know how to diagnose it, others won't. Sincerely, -- William Brown <william(a)firstyear.id.au&gt;

On Mon, 14 Apr 2014, Dan Williams wrote: I don't know what they do when you query for anything else. If there is no hotspot redirection on port 80/443 and their DNS server works properly, and your wifi was secure, you would then get their forward and the above would work. If it is an open wifi, we would not install the forward and you would not get there. but in the current setup, you can pick "hotspot login" mode and it puts their DNS in place, and than you will reach it. Note that manual hotspot login sessions require you to manually mark them for "reprobe" as well because apparently we cannot probe for it because you manually overrode it. If you switch networks, and bring up the VPN, you'll encounter weird things. While still in hotspot mode, the VPN forward put into unbound is not active because you are not using unbound yet (until you hit reprobe to leave "hotspot signon" mode. Paul

On Tue, 15 Apr 2014, William Brown wrote: bind does not support this. Correct. It only happens for bind4/bind8 or broken old bind9s, djbdns/cache, but mostly because of 5 year old dnsmasq versions embedded in the platforms as "dns proxy". Correct. If an ISP starts modifying DNS content, it is simply an attack. You have no trust relationship with them. Understood. The number of flushes should be limited as much as possible. It is only to accomdate certain networks that we flush the cache. Our preference is to never flush. But we accept sometimes it cannot be avoided to support certain type of DNS deployments. The price we have to pay to support some kind of setups. We can also add an option that tells us to not flush certain (secure) networks because we know there is no special casing there. Those are tunings we can do later. Whether the network is "secure" or "insecure" only has an effect on the forwarder state, and thus potentially certain domains handled by that forwarder. DNSSEC validation is not skipped in those cases, so data can still be trusted. Non-DNSSEC domains are always vulnerable to a MITM. Since they can just sign their domains, I don't feel personally that we need to go out of our ways to accomodate those insecure setups. If people will differently, again we could tune and make a toggle. I'll think about these a little more. Note that "keep DNSSEC cache only" is currently not an option implemented by unbound. Not really, you can have differently signed zones for the same name for internal and external view. Hopefully with at least the same DNSKEY, but even that could be different. It would require a manual configuration though of files in /etc/unbound/*.d/ Paul

On Mon, Apr 14, 2014 at 9:06 AM, Dan Williams <dcbw(a)redhat.com&gt; wrote: If you want to get really fancy, you could try to detect a state in which there is no connection to the internet, the router has an address 192.168.*.1, and the router is listening on TCP port 80, and suggest an alternate "you are connected to a possibly unconfigured router" mode. --Andy

On 12.4.2014 17:25, Reindl Harald wrote: It seems that this thread contains a lot of hand-waving about problems which can theoretically happen. I would like to move the discussion to more constructive stage - get your hands dirty! :-) Instructions for testing on Fedora 20+ are available on: https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_... Please, run dnssec-trigger and let exclamations like "It can't possibly work!" apart. Send constructive bug reports instead. E.g. - My network has static configuration XYZ in /etc/sysconfig/... and it doesn't work. "unbound-control list_forwards" shows empty list. - I can't access my corporate mail server when I'm connected to VPN. journalctl -f -u unbound.service shows this: unbound[1062]: [1062:0] info: validation failure <mail.corp.com. A IN>: no keys have a DS with algorithm RSASHA1 from 192.168.2.1 for key dnssec-failed.org. while building chain of trust etc. etc. We need real data. Thank you very much for your attention. -- Petr^2 Spacek

   Hi, Please see -> https://www.piratepad.ca/p/dnssec-requisites-configurations I've collected the major functionalities people wish to have with a default DNS resolver along with couple of 'unbound' configurations that I tried. It'll greatly help if others could also list their configuration details on the same page. Thank you. --- Regards    -Prasad http://feedmug.com

On Fri, 2014-04-25 at 09:56 -0600, Pete Zaitcev wrote: nscd is ... bad Simo. -- Simo Sorce * Red Hat, Inc * New York

DNS over SSL does NOT work - I get no connectivity whatsoever after following the below steps. Tracking bug at https://bugzilla.redhat.com/show_bug.cgi?id=1119050 Can you please tell me what am I doing wrong? @ https://fedoraproject.org/wiki/Test_Day:2012-12-11_Network_Manager_and_DN... it says to do: sudo yum install dnssec-trigger sudo systemctl enable dnssec-triggerd.service sudo systemctl enable unbound.service sudo reboot Then to get DNS over SSL @ https://fedoraproject.org/wiki/QA:Testcase_DNS-over-SSL it says to do: sudo iptables -A OUTPUT -o lo -j ACCEPT sudo iptables -A OUTPUT -p tcp --dport 53 -j DROP sudo iptables -A OUTPUT -p udp --dport 53 -j DROP Then we are supposed to click on re-probe. And now there is no connectivity.