On Thu, 10 Apr 2014, Chuck Anderson wrote:

Yesterday, a new version of dnsmasq was released [2] that adds full DNSSEC support and provides an alternative to unbound which dnssec-trigger requires. There has also been great work done to solve the NTP/DNSSEC bootstrap problem [3]. What options are currently available in e.g. NetworkManager for using a local DNS cache and what is the current status of this integration? Is it ready yet for turning on by default in all Fedora products?

[2] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q2/008416.html [3] http://comments.gmane.org/gmane.comp.embedded.cerowrt.devel/2244

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.

On Thursday, 10 April 2014 8:12 PM, Chuck Anderson wrote: I think this needs to be revisited. 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.

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@yahoo.co.in wrote:

Please see -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver

It's a System Wide Change Proposal request up for review.

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@yahoo.co.in wrote:

...

On Saturday, 12 April 2014 12:28 AM, Bruno Wolff III 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.

Sorry, I did not get the question. Could you please explain it a bit?

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:

Hello,

...

On Thursday, 10 April 2014 11:39 PM, P J P wrote: 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.

Please see -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver

It's a System Wide Change Proposal request up for review.

I have set the target release as F22, because the proposal deadline for F21 was 08 Apr 2014 [1]. Besides, this change would require significant work on the related packages like NetworkManager etc. So F22 seems safer.

In case if you spot any discrepancies or have additional inputs or links to relevant documents etc. please feel free to update the wiki page or let me know and I'll add it there.

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,

On Saturday, 12 April 2014 12:51 AM, Dan Williams 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.

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:

Hello Dan,

...

On Saturday, 12 April 2014 12:51 AM, Dan Williams 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.

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?

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:

...

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?

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.

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.

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?

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@volny.cz wrote:

The goal is to have DNSSEC validation in a system-wide, dedicated code, trusted for that purpose; i.e. unbound does DNSSEC validation for every application, with a centralized configuration and cache, so no application needs or should do this on its own; it can simply consult the AD bit in the reply.

...

Not necessarily, and probably not. ...

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@wolff.to said:

If you are running a caching resolver you don't need the DNS information from DCHP (except except for the hotspot issue) at all.

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.

On Fri, 11 Apr 2014, Chris Adams wrote:

Unless you have a specific reason not to, you should use the DNS server from DHCP.

My specific reason is that I dont trust random strangers.

That may be the only DNS server that will work, there may be private DNS info not available anywhere else, etc.

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@nohats.ca wrote:

...snip...

I've been running this solution on fedora for about five years now. It works reasonably well, and anyone who is on this list surely has could try it out. Because of lack of NM integration I would not call it enduser ready yet.

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:

...

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.

Split horizon should still work with a caching recursive resolver (since that is based on the IP address of where the request is coming from). It won't work if network dnsserver provides alternative data out side of its bailiwick. But if these outside of bailiwick domains are known to you, you can tell your resolver where to look for them.

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)

If the network operator is just outright breaking things so that you can only connect to their dns server, well then you're going to need to do something about that. But even if it is switch to their server, you might want to know that that kind of thing is going on.

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)

The advantage of using your dns server is that you know what you're getting. Some large ISPs are known to do interesting things with dns information (such as rewrite ttl information) that can cause problems that are avoided by using your own server.

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@nohats.ca wrote:

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)

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.

Indeed, with DNSSEC we can use them as cache, because we can validate the answers. But those servers should never be "trusted".

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:

Once upon a time, Bruno Wolff III bruno@wolff.to said:

...

The advantage of using your dns server is that you know what you're getting.

You'll also lose almost all content-delivery network advantages (most of that is mapped to "close" servers with DNS).

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@nohats.ca wrote:

I'm not sure what you are trying to say here.

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:

Hello,

...

On Thursday, 10 April 2014 11:39 PM, P J P wrote: 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.

Please see -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver

It's a System Wide Change Proposal request up for review.

I have set the target release as F22, because the proposal deadline for F21 was 08 Apr 2014 [1]. Besides, this change would require significant work on the related packages like NetworkManager etc. So F22 seems safer.

In case if you spot any discrepancies or have additional inputs or links to relevant documents etc. please feel free to update the wiki page or let me know and I'll add it there.

[1] https://fedoraproject.org/wiki/Releases/21/Schedule

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@nohats.ca wrote:

First, TTLs you receive from a forwarder can always be manipulated, even with DNSSEC - otherwise caching wouldn't work.

Second, I still don't understand the point. Are you suggesting it is better to believe all DNS lies than to not know where the lies lead?

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:

On Fri, Apr 11, 2014 at 14:21:30 -0500, Dan Williams dcbw@redhat.com wrote:

...

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.

If you are running a caching resolver you don't need the DNS information from DCHP (except except for the hotspot issue) at all. For example, dnscache can be used for this. (It doesn't do dnssec though, so wouldn't provide what is wanted for the proposal.)

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.

On Fri, 11 Apr 2014, Simo Sorce wrote:

...

I hope the NM integration will show up at some point. It's really a pretty nice setup.

I am using it too successfully. Only occasionally unbound seem to get confused, not clear when, it doesn't happen more than twice a month and systemctl restart unbound.service fixes it.

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

On Saturday, 12 April 2014 2:13 AM, Paul Wouters wrote:> It's rude to bypass the global DNS caching infrastructure. That would significantly load people's DNS servers with more queries. There is no reason not to try and use ISP's DNS caches.

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.

dnscache is very obsolete software.

-> 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

On Saturday, 12 April 2014 3:55 AM, Chuck Anderson wrote: I think there needs to be more emphasis on the /other/ benefit, the whole reason I brought this up this time:

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

On Saturday, 12 April 2014 10:33 AM, P J P wrote:

...

...

On Saturday, 12 April 2014 2:13 AM, Paul Wouters wrote:>

It's rude to bypass the global DNS caching infrastructure. That would significantly load people's DNS servers with more queries. There is no reason not to try and use ISP's DNS caches.

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@firstyear.id.au wrote:

That makes no sense.

Say I have freshly installed my fedora system at home. I then boot it up and start to use it. My laptop is caching DNS results all the while from the "unreliable" ISP.

I then go to work and suddenly things don't work.

Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a complaint with your ISP.

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:

...

On Saturday, 12 April 2014 11:11 AM, William Brown wrote: Say I have freshly installed my fedora system at home. I then boot it up and start to use it. My laptop is caching DNS results all the while from the "unreliable" ISP.

I then go to work and suddenly things don't work.

Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a complaint with your ISP.

What, no! that was the case for having local cache and not forwarding queries to the ISP's name servers at all. Because those are not reliable.

...

See my previous email, about flushing the cache on network change.

Yes I saw. About automatic cache clearance etc. I agree. Those are features to be requested from the DNS software or maybe NM. I've been using 'dnscache' without any trouble whatsoever.

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.

On Saturday, 12 April 2014 12:41 PM, William Brown wrote: PS: The unreliable ISP I perceive as:

1. They often return no query within an acceptable time period
2. They return invalid or incorrect zone data
3. They mess with TTLs or other zone data

Right.

Consider, I get home, and open my laptop. Cache is cleared, and I'm now populating that cache with the contents from the ISP.

No, why contents from ISP? Local resolver will populate cache from root servers, no?

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.

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.

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.

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.

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,

IMO, local resolver can help here.

--- Regards    -Prasad http://feedmug.com

Am 12.04.2014 13:25, schrieb William Brown:

...

...

Consider, I get home, and open my laptop. Cache is cleared, and I'm now populating that cache with the contents from the ISP.

No, why contents from ISP? Local resolver will populate cache from root servers, no?

This isn't how DNS works ..... You populate your cache from the ISP, who queries above them and so on up to the root server.

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

http://technet.microsoft.com/en-us/library/cc961401.aspx

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:

On Fri, 11 Apr 2014, Simo Sorce wrote:

...

...

I hope the NM integration will show up at some point. It's really a pretty nice setup.

I am using it too successfully. Only occasionally unbound seem to get confused, not clear when, it doesn't happen more than twice a month and systemctl restart unbound.service fixes it.

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.

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:

...

On Saturday, 12 April 2014 7:38 AM, Simo Sorce 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.

True. The local resolver can be configured to resolve internal domains by pointing it to the dynamic name servers. Also one can set 'DNS1=127.0.0.1' in /etc/sysconfig script, that way dynamic name servers are listed as DNS2, DNS3 etc.

For this very reason the dynamic name server entries need to go as "..transitory name servers to be used by the trusted local resolver".

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:

On Sat, Apr 12, 2014 at 02:09:19PM +0800, P J P wrote:

...

...

On Saturday, 12 April 2014 11:11 AM, William Brown wrote: Say I have freshly installed my fedora system at home. I then boot it up and start to use it. My laptop is caching DNS results all the while from the "unreliable" ISP.

I then go to work and suddenly things don't work.

Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a complaint with your ISP.

What, no! that was the case for having local cache and not forwarding queries to the ISP's name servers at all. Because those are not reliable.

I disagree. You can still do DNSSEC validation with a local caching resolver and configure that local resolver to forward all queries to the ISP. That should be tried first, and only bypassed and become a full interative recursive querier bypassing the ISP resolvers if that fails. We need to respect the DNS caching infrastructure by default.

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:

Am 12.04.2014 15:31, schrieb Chuck Anderson:

...

On Sat, Apr 12, 2014 at 02:09:19PM +0800, P J P wrote:

...

...

On Saturday, 12 April 2014 11:11 AM, William Brown wrote: Say I have freshly installed my fedora system at home. I then boot it up and start to use it. My laptop is caching DNS results all the while from the "unreliable" ISP.

I then go to work and suddenly things don't work.

Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a complaint with your ISP.

What, no! that was the case for having local cache and not forwarding queries to the ISP's name servers at all. Because those are not reliable.

I disagree. You can still do DNSSEC validation with a local caching resolver and configure that local resolver to forward all queries to the ISP. That should be tried first, and only bypassed and become a full interative recursive querier bypassing the ISP resolvers if that fails. We need to respect the DNS caching infrastructure by default.

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

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:

I should clarify. I cache the record foo.work.com from the office, and it resolves differently externally. When I go home, it no longer resolves to the external IP as I'm using the internally acquired record from cache.

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:

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

Cheers. That's a goal I share with you, but...

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.

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.

Maybe we should set the file to be immutable after setting it to 127.0.0.1:

chattr +i /etc/resolv.conf

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:

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

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" should not do anything - because "we" don't have a clue about the network of the enduser

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?

if the roadrunner has the VPN client directly on his machine, well then he needs to make a decision:

They needs to make no decision, it has been automated already:

https://github.com/libreswan/libreswan/blob/master/programs/_updown.netkey/_...

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:

...

That's wrong. a DNS server can use a forwareder for some or all of its recursive queries. unbound+dnssec-triggerd mostly cause unbound to do full recursion but using the ISP nameserver as forward for all queries.

oh no - please try to understand what recursion means in case of DNS

may i suggest to read some docs because if i talk about DNS as one who maintains 600 domains as DNS provider as well as Registry for the .at domain and implemented DNS admin-backends years ago i know what i am talking about

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:

On Sat, 12 Apr 2014, Reindl Harald wrote:

...

...

That's wrong. a DNS server can use a forwareder for some or all of its recursive queries. unbound+dnssec-triggerd mostly cause unbound to do full recursion but using the ISP nameserver as forward for all queries.

oh no - please try to understand what recursion means in case of DNS

may i suggest to read some docs because if i talk about DNS as one who maintains 600 domains as DNS provider as well as Registry for the .at domain and implemented DNS admin-backends years ago i know what i am talking about

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?

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:

...

...

chattr +i /etc/resolv.conf

That is the trick currently used by dnssec-triggerd to prevent other applications from messing with that file.

Oh crap, that means I'm going to need a "really really don't touch this file" flag, perhaps a one-way flag that can never be un-set.

I'm already setting chattr +i /etc/resolv.conf to stop anything touching the file, and I don't want apps to mess with that flag (or the file).

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:

On Sat, Apr 12, 2014 at 11:01:20AM -0400, Paul Wouters wrote:

...

On Sat, 12 Apr 2014, Chuck Anderson wrote:

...

Maybe we should set the file to be immutable after setting it to 127.0.0.1:

chattr +i /etc/resolv.conf

That is the trick currently used by dnssec-triggerd to prevent other applications from messing with that file.

Oh crap, that means I'm going to need a "really really don't touch this file" flag, perhaps a one-way flag that can never be un-set.

I'm already setting chattr +i /etc/resolv.conf to stop anything touching the file, and I don't want apps to mess with that flag (or the file).

Bind mount the file to a read-only filesystem?

On Sat, Apr 12, 2014 at 12:06:23PM -0400, Paul Wouters wrote:

On Sat, 12 Apr 2014, Chuck Anderson wrote:

...

Okay, so here is where you and I differ then. We need a solution to run everywhere, on every system, in every use case.

Sounds like wanting ponies? Obviously I fully agree with a solution that works everywhere, all the time, for everyone, however the want it :)

...

The local DNS daemon (note that I didn't say "cache" this time) should be a part of the Base OS like init/systemd is. It should be small, unobtrusive, and do very little, namely the one thing we need: handle failover between multiple DNS servers. I would use the term "DNS proxy" but that term is too overloaded with other connotations and preconceived ideas.

Handling failover requires keeping state of previous queries and outstanding requests to determine which servers are bad or not. Mind you, unbound allows you to set a max TTL on any record received using cache-max-ttl=0, so you can very easilly implement this idea. I think it is a bad idea, because your solution violates your own principle above: it interferes with my use case of optimising DNS caches, reducing unneccessary latency, and doing things like pre-fetching of low TTL records.

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.

In DNS, the publisher of data tells you how long the data should be valid for. If they want the record not to be cached at all, they can set the TTL to 0. Why should we deploy a daemon that does not provide the very useful feature of caching in general (especially when doing DNSSEC validation) when people who wish to not get cached already have a means out, publish records with TTL=0? If you want to be Akamai, you can!

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.

...

dnslookupd keeps track of up/down DNS servers via some health check mechanism, and switches between them appropriately.

I tend to call heartbeats/keepalives "make deads". They often do the opposite. Why invent a whole new health check protocol when you can simple send DNS queries and use strategies to prefer the nearest/fastest servers already. These kind of selection/preference protocols are part of any decent DNS implementation. There is no need to re-invent the wheel.

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:

On Sat, Apr 12, 2014 at 12:06:23PM -0400, Paul Wouters wrote:

...

On Sat, 12 Apr 2014, Chuck Anderson wrote:

...

Okay, so here is where you and I differ then. We need a solution to run everywhere, on every system, in every use case.

Sounds like wanting ponies? Obviously I fully agree with a solution that works everywhere, all the time, for everyone, however the want it :)

...

The local DNS daemon (note that I didn't say "cache" this time) should be a part of the Base OS like init/systemd is. It should be small, unobtrusive, and do very little, namely the one thing we need: handle failover between multiple DNS servers. I would use the term "DNS proxy" but that term is too overloaded with other connotations and preconceived ideas.

Handling failover requires keeping state of previous queries and outstanding requests to determine which servers are bad or not. Mind you, unbound allows you to set a max TTL on any record received using cache-max-ttl=0, so you can very easilly implement this idea. I think it is a bad idea, because your solution violates your own principle above: it interferes with my use case of optimising DNS caches, reducing unneccessary latency, and doing things like pre-fetching of low TTL records.

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.

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.

...

In DNS, the publisher of data tells you how long the data should be valid for. If they want the record not to be cached at all, they can set the TTL to 0. Why should we deploy a daemon that does not provide the very useful feature of caching in general (especially when doing DNSSEC validation) when people who wish to not get cached already have a means out, publish records with TTL=0? If you want to be Akamai, you can!

Because things get messy once you start caching on the end-user system.

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.

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.

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.

...

...

dnslookupd keeps track of up/down DNS servers via some health check mechanism, and switches between them appropriately.

I tend to call heartbeats/keepalives "make deads". They often do the opposite. Why invent a whole new health check protocol when you can simple send DNS queries and use strategies to prefer the nearest/fastest servers already. These kind of selection/preference protocols are part of any decent DNS implementation. There is no need to re-invent the wheel.

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.

Are you volunteering for writing this daemon ? Because if you are not then we are wasting time I would think.

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).

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.

Now can we go back to actually discussion technical arguments again?

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.

On Sun, 13 Apr 2014, William Brown wrote:

...

Now can we go back to actually discussion technical arguments again?

Actually no.

This whole thread has forgotten one major thing ... use cases.

That was in response to someone using appeal of authority statements, not factual discussions.

Proposal is to add a local caching DNS server to fedora systems. This may or may not accept a DHCP provided forwarder(?).

Yes. It depends on the "trustworthiness" of the network and or preconfiguration of some of your own networks you join.

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

Works reasonably well with unbound+dnssec-triger, could use better NM integration for captive portals.

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.

Same if their wifi is closed (eg WPA2), will need an exception in NM if their wifi is open for the .local forward.

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.

Same as above.

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.

Same as above.

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.

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.

Case 6: Fedora server in a small business: Same as the workstation, likely AD or bind in the office.

Same as previous

Case 7: Fedora server in the large business. Same as the workstation.

Same as previous

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.

Same, already works if you only need the one domain that is negotiated via the VPN (eg the IKE XAUTH domain).

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.

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.

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.

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.

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),

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.

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.

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.

Case 3: This user does understand DNS, and they don't need 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 have bind / named setup, and they would like to rely on that instead.

They can. DNS caches are chained. There is no reason to say you cannot run your own cache and have a network based cache.

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.

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.

Case 4, 5, 6 and 7: DNS cache, again, isn't needed.

Again, DNSSEC validation on the device requires caching.

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.

I don't really understand this paragraph.

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.

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.

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:

I believe you will need to re-think that in light of running a validating DNSSEC resolver on your laptop or servers.

• 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.

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:

On Sat, 2014-04-12 at 13:11 -0400, Felix Miata wrote:

...

On 2014-04-12 11:01 (GMT-0400) Paul Wouters composed:

...

...

Chuck Anderson wrote:

...

...

...

Maybe we should set the file to be immutable after setting it to 127.0.0.1:

...

...

...

chattr +i /etc/resolv.conf

...

...

That is the trick currently used by dnssec-triggerd to prevent other applications from messing with that file.

...

I've been doing that myself for years on installations that think my ethernet-only non-wireless LAN host connections need "managing" by NetworkManager, Resolvconf, Wicked or anything else that came along to automagically mis-configure it.

So you've gone out of your way to run a daemon but prevent it from working as configured, instead of just reconfiguring it to do what you need.

What daemon did I go out of my way to run?

I have Network Manager and it is extremely simple to configure it to keep fixed DNS Servers as well as have static addresses for ethernet interfaces.

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.

I find that today, except extremely rare case, all that people that complain about network management tools interfering are people that never tried or tried once *years* ago and never checked again.

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.

On Sun, 2014-04-13 at 06:35 +0200, Reindl Harald wrote:

and if you believe that in a not trustable network you don't know if you get the signing informations at all - fine, but you hardly an enforce that with a local software

That is the WHOLE point of DNSSEC, really.

if i control the network i control the whle traffic and without your own satellite link you can't change that

It is not necessary, integrity protection allows me to find out if my traffic is getting through or not. If not, though luck.

...

...

Case 4, 5, 6 and 7: DNS cache, again, isn't needed.

Again, DNSSEC validation on the device requires caching.

the question is if i gain aynthing doing it on the end-device

If you need to ask this question I think you missed the whole point of DNSSEC.

have fun debugging DNS troubles of a road-warrior in your network without realize that he brings his own DNS server

Caching DNS is common on many OSs, it is nothing special really.

...

...

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:

I believe you will need to re-think that in light of running a validating DNSSEC resolver on your laptop or servers.

no

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.

...

...

• DNS cache is not the default. It bust be enabled on a connection (IE

user's in case 1 can enable it if needed)

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!

...

...

• DNS cache should be able to be enabled from the NM Gui

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.

...

...

• DNS cache should be able to be flushed live from the NM Gui

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.

...

...

• DNS cache should be flushed on route or interface state change.

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)

...

...

• If two interfaces are active, the default route DNS cache setting

takes precedence.

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).

...

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

the cache already is running in my LAN for good reasons

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.

that DNS cache is pushed with DHCP

Forwarders are pushed via DHCP, not caches.

that DNS cache already does DNSSEC validation

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.

if you don't trust the network itself you are lost anyways

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.

On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:

A system wide resolver I am not opposed to. I am against a system wide *caching* resolver.

In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a cache is a severe detriment.

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).

I disable the DNS cache in firefox with developer tools.

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 ?

Additionally, a short TTL is good, for this situation, but it can't fix everything.

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.

...

Proposal is to add a local caching DNS server to fedora systems. This may or may not accept a DHCP provided forwarder(?).

Yes. It depends on the "trustworthiness" of the network and or preconfiguration of some of your own networks you join.

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.

...

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

Works reasonably well with unbound+dnssec-triger, could use better NM integration for captive portals.

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.

...

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.

Same if their wifi is closed (eg WPA2), will need an exception in NM if their wifi is open for the .local forward.

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.

...

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.

Same as above.

...

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.

Same as above.

...

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.

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.

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.

...

Case 6: Fedora server in a small business: Same as the workstation, likely AD or bind in the office.

Same as previous

...

Case 7: Fedora server in the large business. Same as the workstation.

Same as previous

...

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.

Same, already works if you only need the one domain that is negotiated via the VPN (eg the IKE XAUTH domain).

You can negotiate more than one domain on a VPN .... again, see above.

...

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.

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.

This is a more serious problem, than a caching resolver could hope to solve as it shows malicious intent.

...

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.

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.

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!

...

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),

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.

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.

...

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.

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.

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.

...

Case 3: This user does understand DNS, and they don't need 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.

If your lan is insecure, you have other issues. That isn't the problem you are trying to solve.

...

They have bind / named setup, and they would like to rely on that instead.

They can. DNS caches are chained. There is no reason to say you cannot run your own cache and have a network based cache.

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.

...

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.

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.

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.

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.

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.

...

Case 4, 5, 6 and 7: DNS cache, again, isn't needed.

Again, DNSSEC validation on the device requires caching.

...

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.

I don't really understand this paragraph.

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)

...

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.

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.

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.

...

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:

I believe you will need to re-think that in light of running a validating DNSSEC resolver on your laptop or servers.

...

• 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.

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.

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.

On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote:

On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote:

...

On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:

...

A system wide resolver I am not opposed to. I am against a system wide *caching* resolver.

...

In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a cache is a severe detriment.

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).

...

I disable the DNS cache in firefox with developer tools.

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 ?

...

Additionally, a short TTL is good, for this situation, but it can't fix everything.

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.

Internal and external zone views in a business. These records may different, and so would need flushing between network interface state changes.

Additionally, local DNS caches may issues and delay diagnosis.

It's also not *needed* in a lot of setups. The business cases were to show that these caching layers already exist on these networks. It would be duplication of effort.

In businesses, it's also common place to have a low-ish ttl (Say 5 minutes) and when a system is migrated, they swap the A/AAAA records to the new system. The dns servers on the network are updated, but the workstation has the old record cached. Without a local cache, they would query the local server again, which is relatively cheap. IE: It keeps users happier even if they only needed to wait 5 minutes. Some people like things to be instant.

It's certainly not the end of the world, but it's adding more complexity, and a potential source of issues.

There is additionally, some confusion: It sounds like Paul wants to add the resolver to only forward queries for the local domain name to the local name servers. But this is impossible to discover all possible local domain names that are available.

tl;dr - DNSSEC I believe is a good thing (Even if it's rare). I don't think there are "benefits" to caching except in a minor number of cases where existing DNS caching mechanisms aren't in place. We are adding a layer of caching complexity that doesn't solve a real problem.

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 wrote:

In businesses, it's also common place to have a low-ish ttl (Say 5 minutes) and when a system is migrated, they swap the A/AAAA records to the new system. The dns servers on the network are updated, but the workstation has the old record cached. Without a local cache, they would query the local server again, which is relatively cheap. IE: It keeps users happier even if they only needed to wait 5 minutes. Some people like things to be instant.

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.

On Sun, 13 Apr 2014, William Brown wrote:

...

Yes. It depends on the "trustworthiness" of the network and or preconfiguration of some of your own networks you join.

Not really: Every network you join, you have to semi-trust. If you don't trust it, why did you join it?

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".

...

Works reasonably well with unbound+dnssec-triger, could use better NM integration for captive portals.

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.

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.

...

...

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.

Same if their wifi is closed (eg WPA2), will need an exception in NM if their wifi is open for the .local forward.

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.

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

...

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.

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.

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.

Again, you *must* respect the DHCP provided DNS server as the forwarder else you will savagely break things.

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.

...

Same, already works if you only need the one domain that is negotiated via the VPN (eg the IKE XAUTH domain).

You can negotiate more than one domain on a VPN .... again, see above.

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.

...

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.

This is a more serious problem, than a caching resolver could hope to solve as it shows malicious intent.

I'm sorry I don't understand what you are trying to say here.

...

...

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.

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.

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!

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.

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.

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.

...

...

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.

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.

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 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.

...

...

Case 3: This user does understand DNS, and they don't need 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.

If your lan is insecure, you have other issues. That isn't the problem you are trying to solve.

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.

...

...

They have bind / named setup, and they would like to rely on that instead.

They can. DNS caches are chained. There is no reason to say you cannot run your own cache and have a network based cache.

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.

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.

...

...

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.

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.

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.

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.

...

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.

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.

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.

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.

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.

Additionally, business networks are "trusted" so you can trust their DNS caches etc. (to a point)

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.

...

...

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.

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.

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.

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.

No, cache is not a feature. It's a chronic issue.

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.

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.

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.

DNSSEC is a good idea: Caches are a problem.

We disagree.

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.

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:

...

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.

If your lan is insecure, you have other issues. That isn't the problem you are trying to solve.

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.

On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote:

On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote:

...

On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:

...

A system wide resolver I am not opposed to. I am against a system wide *caching* resolver.

...

In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a cache is a severe detriment.

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).

...

I disable the DNS cache in firefox with developer tools.

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 ?

...

Additionally, a short TTL is good, for this situation, but it can't fix everything.

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.

Internal and external zone views in a business. These records may different, and so would need flushing between network interface state changes.

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.

Additionally, local DNS caches may issues and delay diagnosis.

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.

It's also not *needed* in a lot of setups. The business cases were to show that these caching layers already exist on these networks. It would be duplication of effort.

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.

In businesses, it's also common place to have a low-ish ttl (Say 5 minutes) and when a system is migrated, they swap the A/AAAA records to the new system. The dns servers on the network are updated, but the workstation has the old record cached.

If the TTL is 5 minutes, the cache will expire in 5 minutes too.

Without a local cache, they would query the local server again, which is relatively cheap.

And tey will do the same with a local cache, local caches *will* respect TTLs of course!

IE: It keeps users happier even if they only needed to wait 5 minutes. Some people like things to be instant.

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.

It's certainly not the end of the world, but it's adding more complexity, and a potential source of issues.

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).

There is additionally, some confusion: It sounds like Paul wants to add the resolver to only forward queries for the local domain name to the local name servers. But this is impossible to discover all possible local domain names that are available.

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).

tl;dr - DNSSEC I believe is a good thing (Even if it's rare). I don't think there are "benefits" to caching except in a minor number of cases where existing DNS caching mechanisms aren't in place. We are adding a layer of caching complexity that doesn't solve a real problem.

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.

On Sun, 13 Apr 2014, Richard W.M. Jones wrote:

...

So you've gone out of your way to run a daemon but prevent it from working as configured, instead of just reconfiguring it to do what you need.

I have to go out of my way to *stop* NetworkManager from running and to configure a fixed IP address.

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

...

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.

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.

What is a "captivity-sign" as you so put it?

...

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.

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

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.

...

...

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.

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.

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.

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.

...

Again, you *must* respect the DHCP provided DNS server as the forwarder else you will savagely break things.

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.

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.

...

...

...

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.

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.

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!

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.

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.)

...

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.

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.

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.

...

...

...

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.

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.

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 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.

...

...

...

Case 3: This user does understand DNS, and they don't need 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.

If your lan is insecure, you have other issues. That isn't the problem you are trying to solve.

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.

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.

...

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.

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.

That's deflecting the point. The first advice when you can't access some website or service foo, is to reboot for this reason.

...

DNSSEC is a good idea: Caches are a problem.

We disagree.

...

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.

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.

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. :)

On Mon, 2014-04-14 at 00:42 -0400, Paul Wouters wrote:

On Mon, 14 Apr 2014, William Brown wrote:

...

What is a "captivity-sign" as you so put it?

Check for clean port 80. It fetches the url specified in dnssec-triggerd.conf's url: option (default http://fedoraproject.org/static/hotspot.txt)

If it returns a redirect or a page that does not contain the exact text "OK" it knows a hotspot has intercepted the page and will prompt the user to login to the hotspot. It the user agrees, resolv.conf is filled in with the DHCP obtained values and it fires of xdg-open to the page http://hotspot-nocache.fedoraproject.org/ which is a special DNS entry with TTL=0 so it can never be cached (so we will go through the DNS lies that are told about the name)

When port 80 becomes clean, it is assumed you have "logged on" and it then runs various DNS/DNSSEC tests against TLD servers for known features and bugs in old DNS software. This will determine if DNS is still messed with. If the forwarder shows broken behaviour, it is attempted to bypass it as I described before.

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?

...

...

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

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.

As we indicated, for "trusted" networks (LAN, secure WIFI) a domain of "." will be used which means "forward everything". This does NOT mean we stop being a recursor. We still recursive because we need tod perform DNSSEC validation. We just use the available DNS cache of the local network - which also gets us your internal-only domains.

This point was not made clear. Will summarise at the bottom ...

Yes. The problem here is the dodgy ISP. If they are dodgy enough, unbound will bypass them anyway. If we need to add an NM option for "don't use this dodgy ISPs DNS servers" we can also add that.

...

But you can't really tell what's a dodgy DNS and what's not.

Yes we can. There is both dnssec-trigger and some other software that runs various tests for this.

*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?

...

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?

unbound does not really care about transparent proxy's on port 53. As long as they don't break DNS (and DNSSEC). If they redirect port 53 to some broken DNS server, unbound will try to work around it. If port 53 is broken it will attempt DNS over port 80 of various fedoraproject DNS servers, or DNS over TLS on port 443.

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?

...

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.

I hope I clarified it now that your third bullet point is not the case.

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.

...

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.

This is why we did not want to force everyone on dnssec-triggerd. We know that solution is not good enough for non-devs.

Agreed.

...

In summary, all I ask is that:

• If a forwarder exists on the network, unbound uses it for all queries.

Yes, but not for open wifi. Only for physical wire and secured wifi.

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.

...

• If that forwarder returns an invalid signed DNSSEC zone then you

bypass it for only that zone. (IE the zone is being tampered with)

That's not how things work. The DNS server is either capable or not capable of doing DNSSEC. That is not a "per zone" thing. If it fails to return RRSIG signature records for the root zone, there is nothing you can do but forget about that server. (technically speaking, I do what you say, if you consider "." to be "only that zone")

Okay that makes sense.

...

• Unbound flushes it's cache between interface state changes, because

you are moving between networks with different DNS views of the world.

I am not convinced that is required. It does a lot of damage too.

...

• 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.

No. As I stated repeatedly, we are NOT in the business of modifying DNS records. If people pubilsh long TTLs, we will honor those TTLs. Doing otherwise is similar to launching an attack on the nameservers of those domains, who might not be able to handle such short TTLs. Imagine if I run a domain using a nameserver on my DSL. TTL of 7200. The name gets known, and everyone starts hammering it because middle boxes cut the TTL to 300. That's irresponsible.

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.

...

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. :)

I think we are fairly close to agreement on what's needed. Thank you for your discussion this with us. It is clear now that we must flush the entire cache when we use a forwarder for more than one domain (eg not the VPN cases) when using authenticated networks. That is something I had not considered before.

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,

On Mon, Apr 14, 2014 at 02:07:07PM +0200, Juan Orti Alcaine wrote:

One thing I would like to note is that in machines which don't have a hardware clock, I had problems starting bind and unbound, because the date was back to 1970 in each boot, so the root dns key was not yet valid and there were no valid dns resolvers to update time by ntp. I had to hardcode some ntp servers IP addresses to perform the ntp queries at boot time.

This was using the OpenWrt distro in a mips router, I don't know if we can face this kind of problem in ARM machines. I guess all x86 have hardware clock, doesn't they?

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.

...

...

unbound does not really care about transparent proxy's on port 53. As long as they don't break DNS (and DNSSEC). If they redirect port 53 to some broken DNS server, unbound will try to work around it. If port 53 is broken it will attempt DNS over port 80 of various fedoraproject DNS servers, or DNS over TLS on port 443.

How do you setup DNS over TLS?

Unbound has this capability already build in. unbound-control activates via (currently via dnssec-triggerd, in the future via NM) using the keywords tcp-upstream or ssl-upstream.

I meant for say bind, but okay.

...

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.

For a detailed list you will have to check the source code. But it includes thing like DNSSEC records, proper wildcard NSEC(3) records, CNAME support, EDNS0 support, packet sizes, etc. The known bugs in older versions of common DNS software. Cases the IETF actually experienced in the wild.

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.

...

...

...

• If a forwarder exists on the network, unbound uses it for all queries.

Yes, but not for open wifi. Only for physical wire and secured wifi.

Okay. Can this point be made clear on the proposal page? Also the conditions for Physical wire, and secured wifi?

Yes, we can do that.

Thanks.

...

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.

If we believe that artificial increase of TTL is a common manglement, we can have dnssec-trigger (or the NM integrated version of that) check for such mangling. I'm reluctant to try and solve every _imaginable_ problem out there. If your ISPs badness causes suboptimal routes, than that's not the end of the world, and you have your ISP to blame. One ISP shouldn't be responsible for every fedora user flushing caches all the time. Let's deal with this problem when we actually find it is a real world problem.

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".

...

• 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

No, we cannot do that. As I said, a rogue hotspot could give the domain-name "corp.paypal.com" to fool me into thinking I'm connecting to my internal corporate network. We cannot automatically insert those forwards on open wifi, unless the user manually performs an override.

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.

...

• On a secure network (Encrypted wifi, lan) unbound will use the

forwarders as provided by DHCP.

Provided they are functional (eg don't break DNSSEC)

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".

...

• Unbound will flush the cache between authenticated networks. (If I

read your last point correctly)

If we did a "." forward, yes.

Moved ...

...

...

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:

"only rebuild"? You are asking everyone else to do hundreds of queries for each time to join their 3G network. Remember, when validating, you don't just have one record for a queried A record. Since you need to recurse and do all the intermediate queries too because otherwise you don't have the records to do full DNSSEC validation. It's not a reasonably thing to flush the cache. We are working hard on ensuring the user _hits_ their cache and gains speed up (including pre-fetching). Waiting on various roundtrips for DNS over 3G is going to cause a lot more delays than a "suboptimal route". Your workaround will actually be detrimental to the user experience.

Note, I'm trying to optimise that path too, see: http://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-00

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,

On Mon, 14 Apr 2014, Dan Williams wrote:

But another scenario I've seen: older Netgear routers which intercept "www.routerlogin.net" as the setup page. The instructions literally are:

1. connect your computer to the router with a cable
2. go to www.routerlogin.net
3. follow the setup guide instructions

Any idea how dnssec-trigger + unbound would handle this? Since it's router setup, maybe spawning the whole new window for the "portal" would work, but you'd want to make sure the window didn't go away or DNS didn't change until the user was done setting up the router.

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:

...

...

How do you setup DNS over TLS?

Unbound has this capability already build in. unbound-control activates via (currently via dnssec-triggerd, in the future via NM) using the keywords tcp-upstream or ssl-upstream.

I meant for say bind, but okay.

bind does not support this.

...

For a detailed list you will have to check the source code. But it includes thing like DNSSEC records, proper wildcard NSEC(3) records, CNAME support, EDNS0 support, packet sizes, etc. The known bugs in older versions of common DNS software. Cases the IETF actually experienced in the wild.

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.

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".

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".

Correct. If an ISP starts modifying DNS content, it is simply an attack. You have no trust relationship with them.

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".

Understood.

...

...

"suboptimal route". Your workaround will actually be detrimental to the user experience.

Note, I'm trying to optimise that path too, see: http://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-00

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!

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.

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?

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.

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.

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.

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.

I'll think about these a little more. Note that "keep DNSSEC cache only" is currently not an option implemented by unbound.

The only records you can really guarantee as being the same on all network views are ones signed by DNSSEC.

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@redhat.com wrote:

On Mon, 2014-04-14 at 12:00 -0400, Paul Wouters wrote:

...

On Mon, 14 Apr 2014, Dan Williams wrote:

...

But another scenario I've seen: older Netgear routers which intercept "www.routerlogin.net" as the setup page. The instructions literally are:

1. connect your computer to the router with a cable
2. go to www.routerlogin.net
3. follow the setup guide instructions

Any idea how dnssec-trigger + unbound would handle this? Since it's router setup, maybe spawning the whole new window for the "portal" would work, but you'd want to make sure the window didn't go away or DNS didn't change until the user was done setting up the router.

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

Since the user is setting things up, they can pick whether it's open or protected wifi. We don't control that.

...

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

Ok, that could be a problem. This is a user setting up wifi on a router they just bought, so it has no upstream connection yet, is not yet configured at all, and they are just following the directions in the printed brochure they got with the router. Which obviously won't say anything about "hotspot login" mode.

Also, this is the procedure you follow if you reset the router to factory defaults, which support people sometimes tell you to do. So we'd run into the issue if/when the user contacted Netgear technical support too.

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:

Am 12.04.2014 17:11, schrieb Paul Wouters:

...

On Sat, 12 Apr 2014, Reindl Harald wrote:

...

"we" should not do anything - because "we" don't have a clue about the network of the enduser

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?

because i stopped to use laptops years ago? because i have way too complex dns setups for such magic? because i don't touch NM in that life?

i speak in that thread as one who understands the pain of playing with DNS and what happens if assumtions are made wrong

...

...

if the roadrunner has the VPN client directly on his machine, well then he needs to make a decision:

They needs to make no decision, it has been automated already:

https://github.com/libreswan/libreswan/blob/master/programs/_updown.netkey/_...

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

and if you cross my street with a users machine give me a single button to disable that because you break my setups with that - no i can't explain internal infrastructure in the public but there has to be no local cache in my way

if a co-worker asks for a dns-record, tried to call the site already you have no business to have a negative cache on the client while all 4 internal nameservers where two are already caching-servers for external responses and used as forwarder for non-auth zones have already the answer

DNS1: cache DNS2: cache DNS3: auth for 600 zones DNS4: auth for 600 zones

users asking DNS1 and DNS2 they are doing recursion

DNS3 and DNS4 are for public access from the internet to resolve customer domains

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_Tes...

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.

Hi,

On Tuesday, 15 April 2014 4:02 PM, Petr Spacek wrote: We need real data.

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:

On Thu, 10 Apr 2014 10:41:54 -0400 Chuck Anderson cra@WPI.EDU wrote:

...

[...] 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 observe you pointedly ignore the existence of nscd (which does not require any changes to resolv.conf). Why is that?

nscd is ... bad

Simo.

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_DNSSE...

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.