= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P pjp@fedoraproject.org, Pavel Šimerda pavlix@pavlix.net, Tomas Hozza thozza@redhat.com
To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
The automatic name server entries received via dhcp/vpn/wireless configurations should be stored separately, as transitory name servers to be used by the trusted local resolver. In all cases, DNSSEC validation will be done locally.
This change was submitted after the Submission deadline.
== Detailed Description == There are growing instances of discussions and debates about the need for a trusted DNSSEC validating local resolver running on 127.0.0.1:53. There are multiple reasons for having such a resolver, importantly security & usability. Security & protection of user's privacy becomes paramount with the backdrop of the increasingly snooping governments and service providers world wide.
People use Fedora on portable/mobile devices which are connected to diverse networks as and when required. The automatic DNS configurations provided by these networks are never trustworthy for DNSSEC validation. As currently there is no way to establish such trust.
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])
Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous, having a trusted local DNS resolver will not only be imperative but be unavoidable. Because it will perform the most important operation of establishing trust between two parties.
All DNS literature strongly recommends it. And amongst all discussions and debates about issues involved in establishing such trust, it is unanimously agreed upon and accepted that having a trusted local DNS resolver is the best solution possible. It'll simplify and facilitate lot of other design decisions and application development in future. (See: [1], [2], [3])
People:- * Petr Spacek * Paul Wouters * Simo Sorce * Dmitri Pal * Carlos O'Donell
== Scope == * Proposal owners: Proposal owners shall have to ** define the syntax and semantics for new configuration parameters/files. ** persuade and coordinate with the other package owners to incorporate new changes/workflow in their applications.
* Other developers: (especially NetworkManager and the likes) ** would have to implement the new features/workflow for their applications adhering to the new configurations and assuming the availability of the '''trusted''' local DNS resolver. ** NetworkManager already has features & capability to support local DNS resolvers. Though few details are still under development, but are expected to realize in near future. Please see [4]
* Release engineering: ** would have to ensure that trusted local DNS resolver is available throughout the installation stage and the same is installed on all installations including LiveCDs etc.
* Policies and guidelines: ** the chosen trusted DNS resolver package(ex dnsmasq or dnssec-trigger etc.) would have to ensure that their DNS resolver starts at boot time and works out of the box without any user intervention. ** NetworkManager and others would have to be told to not tamper with the local nameserver entries in '/etc/resolv.conf' and save the dynamic nameserver entries in a separate configuration file.
[1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html [2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html [3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html [4] https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html
_______________________________________________ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Hello, 2014-04-29 14:15 GMT+02:00 Jaroslav Reznik jreznik@redhat.com:
= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
== Upgrade/compatibility impact ==
So what *exactly* happens on upgrade? Before the upgrade, most resolv.conf files will not point to 127.0.0.1. What will they point to after the upgrade, and if they will point to 127.0.0.1, which package will actually do that, and what will happen with the old contents of the file? For example, is it assumed that ifcfg-* are always authoritative and it's safe to just overwrite resolv.conf?
== User Experience ==
Similarly, what do we tell users who used to edit /etc/resolv.conf to do in the new system?
Generally, the page doesn't actually say *which* resolver will be used. Has that been decided? Or is that intentionally undefined? Mirek
Hello,
On Tuesday, 29 April 2014 7:22 PM, Miloslav Trmač wrote:
So what exactly happens on upgrade? Before the upgrade, most resolv.conf files will not point to 127.0.0.1. What will they point to after the upgrade, and if they will point to 127.0.0.1, which package will actually do that, and what will happen with the old contents of the file? For example, is it assumed that ifcfg-* are always authoritative and it's safe to just overwrite resolv.conf?
After upgrade, the default DNS resolver should listen on 127.0.0.1:53. And the entry will be added to '/etc/resolv.conf' by NetworkManager. The old contents of the file should be passed on to the local resolver as transitory name servers. The actual workflow is currently being worked upon.
Similarly, what do we tell users who used to edit /etc/resolv.conf to do in the new system?
We tell users to never edit the '/etc/resolv.conf' file and ensure that the local resolver is listening at 127.0.0.1:53.
Generally, the page doesn't actually say which resolver will be used. Has that been decided? Or is that intentionally undefined?
The choice of the default resolver is not yet done. From the discussion so far unbound(https://unbound.net/) appears to be the strong contender.
--- Regards -Prasad http://feedmug.com
On Tue, 2014-04-29 at 22:10 +0800, P J P wrote:
Hello,
On Tuesday, 29 April 2014 7:22 PM, Miloslav Trmač wrote:
So what exactly happens on upgrade? Before the upgrade, most resolv.conf files will not point to 127.0.0.1. What will they point to after the upgrade, and if they will point to 127.0.0.1, which package will actually do that, and what will happen with the old contents of the file? For example, is it assumed that ifcfg-* are always authoritative and it's safe to just overwrite resolv.conf?
After upgrade, the default DNS resolver should listen on 127.0.0.1:53. And the entry will be added to '/etc/resolv.conf' by NetworkManager. The old contents of the file should be passed on to the local resolver as transitory name servers. The actual workflow is currently being worked upon.
If NetworkManager is used, an upgrade would simply involve dropping a config file into /etc/NetworkManager/conf.d that specifies the "dns=[plugin]" option. Then, either NM rewrites resolv.conf to 127.0.0.1 (if an NM DNS plugin is used), or NM stops touching resolv.conf entirely (dns=none) and something else handles resolv.conf. In both cases, NetworkManager gets the DNS information from the same places it already does, and passes it along to the caching nameserver automatically.
If NetworkManager is not being used on the system, then yes, there are some additional questions which the proposal needs to answer.
Similarly, what do we tell users who used to edit /etc/resolv.conf to do in the new system?
We tell users to never edit the '/etc/resolv.conf' file and ensure that the local resolver is listening at 127.0.0.1:53.
If NetworkManager is being used, users already don't touch resolv.conf, they edit /etc/sysconfig/network-scripts/ifcfg-* files and use DNS1/DNS2/DNS3 and SEARCHES to set DNS information.
If NetworkManager is not being used, then the proposal needs to address what config file users *do* edit to ensure that the upstream DNS servers are pushed to the caching nameserver.
Dan
Generally, the page doesn't actually say which resolver will be used. Has that been decided? Or is that intentionally undefined?
The choice of the default resolver is not yet done. From the discussion so far unbound(https://unbound.net/) appears to be the strong contender.
Regards -Prasad http://feedmug.com
Hi,
On Tuesday, 29 April 2014 8:59 PM, Dan Williams dcbw@redhat.com wrote: If NetworkManager is being used, users already don't touch resolv.conf, they edit /etc/sysconfig/network-scripts/ifcfg-* files and use DNS1/DNS2/DNS3 and SEARCHES to set DNS information.
Yes, true!
If NetworkManager is not being used, then the proposal needs to address what config file users *do* edit to ensure that the upstream DNS servers are pushed to the caching nameserver.
If NetworkManager is not used, dnssec-trigger seamlessly handles lot of its responsibilities. I'll update the proposal page with information about it.
--- Regards -Prasad http://feedmug.com
On Tue, 29 Apr 2014, P J P wrote:
Similarly, what do we tell users who used to edit /etc/resolv.conf to do in the new system?
We tell users to never edit the '/etc/resolv.conf' file and ensure that the local resolver is listening at 127.0.0.1:53.
We should leave a comment in resolv.conf that warns the user.
Generally, the page doesn't actually say which resolver will be used. Has that been decided? Or is that intentionally undefined?
The choice of the default resolver is not yet done. From the discussion so far unbound(https://unbound.net/) appears to be the strong contender.
We've been working with the unbound people to get the features in that we needed. It is the only one that is feature-rich enough for us to currently use (for instance with dynamic reconfiguration when using VPNs).
Note that FreeBSD also picked unbound recently for the exact same task.
Paul
On Tuesday, 29 April 2014 9:29 PM, Paul Wouters paul@nohats.ca wrote: Note that FreeBSD also picked unbound recently for the exact same task.
True! -> http://www.freebsdnews.net/2013/09/20/freebsd-10s-new-technologies-and-featu...
--- Regards -Prasad http://feedmug.com
To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
Can the proposal owners clarify for me how this is intended to impact the cloud products? There's general resistance to having more services running by default, and the dns resolvers aren't famous for being lightweight. Plus, some of the assumptions (like "People use Fedora on portable/mobile devices which are connected to diverse networks as and when required") do not seem to apply, or may apply in different ways.
On Tuesday, 29 April 2014 7:56 PM, Matthew Miller wrote: Can the proposal owners clarify for me how this is intended to impact the cloud products?
Cloud products is somewhat of a hazy area(at-least for me). It's unclear how things operate there. Any information about how we could/should address it well is required and most welcome.
Please see -> https://lists.fedoraproject.org/pipermail/devel/2014-April/198620.html
Thank you. ---
Regards -Prasad http://feedmug.com
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P pjp@fedoraproject.org, Pavel Šimerda pavlix@pavlix.net, Tomas Hozza thozza@redhat.com
To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work.
Not sure how to fix something like that though...
On Tue, Apr 29, 2014 at 05:15:57PM +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P pjp@fedoraproject.org, Pavel Šimerda pavlix@pavlix.net, Tomas Hozza thozza@redhat.com
To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work.
Not sure how to fix something like that though...
Is it possible to use a different loopback device like 127.0.0.53 and then have that point outside the container somehow?
On Tue, Apr 29, 2014 at 8:18 AM, Chuck Anderson cra@wpi.edu wrote:
On Tue, Apr 29, 2014 at 05:15:57PM +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P pjp@fedoraproject.org, Pavel Šimerda pavlix@pavlix.net, Tomas Hozza thozza@redhat.com
To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work.
Not sure how to fix something like that though...
Is it possible to use a different loopback device like 127.0.0.53 and then have that point outside the container somehow?
I like this solution, although I think it'll require making unbound bind to 127.0.0.53 for the non-container case, too.
OTOH, it would be straightforward to write a tiny stub that forwards 127.0.0.1:53 to something outside the container.
--Andy
Hi,
On Tuesday, 29 April 2014 10:08 PM, Andrew Lutomirski luto@mit.edu wrote:
but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work.
Ah, interesting! Thank you so much for sharing these details.
OTOH, it would be straightforward to write a tiny stub that forwards
127.0.0.1:53 to something outside the container.
I think this is a better option than having a different device address like 127.0.0.53. Forwarding traffic from inside namespace to a loop-back device on the host is analogous to a guest(VM) forwarding traffic to its host via bridge interface.
Thank you. --- Regards -Prasad http://feedmug.com
On Tue, Apr 29, 2014 at 12:17 PM, P J P pj.pandit@yahoo.co.in wrote:
Hi,
On Tuesday, 29 April 2014 10:08 PM, Andrew Lutomirski luto@mit.edu wrote:
but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work.
Ah, interesting! Thank you so much for sharing these details.
OTOH, it would be straightforward to write a tiny stub that forwards
127.0.0.1:53 to something outside the container.
I think this is a better option than having a different device address like 127.0.0.53. Forwarding traffic from inside namespace to a loop-back device on the host is analogous to a guest(VM) forwarding traffic to its host via bridge interface.
FWIW, this approach has other benefits. For example, virtme could use it to avoid hacks like trying to bind-mount something on top of /etc/resolv.conf. Some day I hope to propose explicit virtme guest support as a Fedora feature, and, if /etc/resolv.conf were to have constant, predetermined contents, a major wart would go away.
https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git
--Andy
On Tue, Apr 29, 2014 at 09:29:00AM -0700, Andrew Lutomirski wrote:
OTOH, it would be straightforward to write a tiny stub that forwards 127.0.0.1:53 to something outside the container.
Is this tiny stub a process running inside the container? What starts that process? What about in the "single application" docker case where an init system isn't used?
On Tue, Apr 29, 2014 at 12:41 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Apr 29, 2014 at 09:29:00AM -0700, Andrew Lutomirski wrote:
OTOH, it would be straightforward to write a tiny stub that forwards 127.0.0.1:53 to something outside the container.
Is this tiny stub a process running inside the container? What starts that process? What about in the "single application" docker case where an init system isn't used?
No clue. What sets /etc/resolv.conf right now?
FWIW, how many "single applications" actually work correctly when run as PID 1? I suspect that, eventually, Docker will end up with a specialized PID 1 even for single applications.
--Andy
On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P pjp@fedoraproject.org, Pavel Šimerda pavlix@pavlix.net, Tomas Hozza thozza@redhat.com
To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work.
Not sure how to fix something like that though...
Any way we can redirect the connection to the host ?
On the host we cannot listen on 0.0.0.0 so we cannot make unbound available through normal routing on a different interface.
However we can perhaps make it listen on a special virtual interface dedicated to let containers talk to other processes on the host maybe ? (could even be other privileged containers). There is a question of what addresses to use though ...
Simo.
On tis, 2014-04-29 at 11:24 -0400, Simo Sorce wrote:
On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P pjp@fedoraproject.org, Pavel Šimerda pavlix@pavlix.net, Tomas Hozza thozza@redhat.com
To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work.
Not sure how to fix something like that though...
Any way we can redirect the connection to the host ?
On the host we cannot listen on 0.0.0.0 so we cannot make unbound available through normal routing on a different interface.
However we can perhaps make it listen on a special virtual interface dedicated to let containers talk to other processes on the host maybe ? (could even be other privileged containers). There is a question of what addresses to use though ...
I don't see any nice way to make this "just work" in docker (i.e. without changes to docker). Docker as well as the host sets up 127.0.0.1/8 for the loopback device, so any 127.0.0.* will get routed to the local loopback.
The only ways to have a ip available to both the host and the container are to either have a ip not in the 127.0.0.x range (thus this will be forwarded to the default gw, i.e. the host) or to set up some kind of forwarding of a port in 127.0.0.x (i.e. use iptables). The later needs to be done by docker, as its what sets up the network interfaces for the container.
So, without changes to docker the option seems to be to set up another local interface with address range different than 127.0.0.1 and have the dns server listen to that.
On Wed, 2014-04-30 at 08:49 +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 11:24 -0400, Simo Sorce wrote:
On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P pjp@fedoraproject.org, Pavel Šimerda pavlix@pavlix.net, Tomas Hozza thozza@redhat.com
To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work.
Not sure how to fix something like that though...
Any way we can redirect the connection to the host ?
On the host we cannot listen on 0.0.0.0 so we cannot make unbound available through normal routing on a different interface.
However we can perhaps make it listen on a special virtual interface dedicated to let containers talk to other processes on the host maybe ? (could even be other privileged containers). There is a question of what addresses to use though ...
I don't see any nice way to make this "just work" in docker (i.e. without changes to docker). Docker as well as the host sets up 127.0.0.1/8 for the loopback device, so any 127.0.0.* will get routed to the local loopback.
Yep, seen that.
The only ways to have a ip available to both the host and the container are to either have a ip not in the 127.0.0.x range (thus this will be forwarded to the default gw, i.e. the host) or to set up some kind of forwarding of a port in 127.0.0.x (i.e. use iptables). The later needs to be done by docker, as its what sets up the network interfaces for the container.
I thought as much, would it be rally bad to have docker forward via iptables ? I guess the question really is, *how* do you do that ? The local resolver listend on 127.0.0.1:53 *only* on the host, so it is not like we can use iptables to forward to a routable address. Although clearly we are on the same machine ... but I guess iptables is namespaced so the one configured in the container has no way to see the host's loopback ?
So, without changes to docker the option seems to be to set up another local interface with address range different than 127.0.0.1 and have the dns server listen to that.
And here comes the problem (actually 2) 1. the local caching resolver is meant to listen exclusively on 127.0.0.1:53 in the normal case, although I guess docker could be allowed to poke at the configuration. 2. what address are you going to steal ? Just pull one out of the hat like libvirt does for the default VMs network and just take possession of another address in 192.168.X.0/24 ?
Sounds like we should try to define some "standard" network address to do things like this instead, would it make sense to use the IPv4 network some times ago microsoft bought and made available as a local collision domain for these kind of things ? They reserved the network in 169.254.0.0 as a local collision domain where clients can auto-assign themselves an IP address and try to communicate with neighbours in the same collision domain. I wonder if we should perhaps hijack a subnet of that network, so we can avoid stealing another /24 from 192.168 ?
Simo.
On 30.4.2014 15:29, Simo Sorce wrote:
On Wed, 2014-04-30 at 08:49 +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 11:24 -0400, Simo Sorce wrote:
On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote:
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P pjp@fedoraproject.org, Pavel Šimerda pavlix@pavlix.net, Tomas Hozza thozza@redhat.com
To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work.
Not sure how to fix something like that though...
Any way we can redirect the connection to the host ?
On the host we cannot listen on 0.0.0.0 so we cannot make unbound available through normal routing on a different interface.
However we can perhaps make it listen on a special virtual interface dedicated to let containers talk to other processes on the host maybe ? (could even be other privileged containers). There is a question of what addresses to use though ...
I don't see any nice way to make this "just work" in docker (i.e. without changes to docker). Docker as well as the host sets up 127.0.0.1/8 for the loopback device, so any 127.0.0.* will get routed to the local loopback.
Yep, seen that.
The only ways to have a ip available to both the host and the container are to either have a ip not in the 127.0.0.x range (thus this will be forwarded to the default gw, i.e. the host) or to set up some kind of forwarding of a port in 127.0.0.x (i.e. use iptables). The later needs to be done by docker, as its what sets up the network interfaces for the container.
I thought as much, would it be rally bad to have docker forward via iptables ? I guess the question really is, *how* do you do that ? The local resolver listend on 127.0.0.1:53 *only* on the host, so it is not like we can use iptables to forward to a routable address. Although clearly we are on the same machine ... but I guess iptables is namespaced so the one configured in the container has no way to see the host's loopback ?
So, without changes to docker the option seems to be to set up another local interface with address range different than 127.0.0.1 and have the dns server listen to that.
And here comes the problem (actually 2)
- the local caching resolver is meant to listen exclusively on
127.0.0.1:53 in the normal case, although I guess docker could be allowed to poke at the configuration. 2. what address are you going to steal ? Just pull one out of the hat like libvirt does for the default VMs network and just take possession of another address in 192.168.X.0/24 ?
Sounds like we should try to define some "standard" network address to do things like this instead, would it make sense to use the IPv4 network some times ago microsoft bought and made available as a local collision domain for these kind of things ? They reserved the network in 169.254.0.0 as a local collision domain where clients can auto-assign themselves an IP address and try to communicate with neighbours in the same collision domain. I wonder if we should perhaps hijack a subnet of that network, so we can avoid stealing another /24 from 192.168 ?
IMHO we should consider approaches including Docker modification.
There has to be an ability to allow communication between containers (Apache in one container and MySQL in second container).
Maybe with some slight modification it could route 127.255.255.254 to it's "hypervisor". It could be even optional...
Other obvious approach is to allow Docker to use different /etc/resolv.conf inside container (but still configured from outside of the container).
(Yes, it doesn't work today. It doesn't mean that it can't work in future.)
[ Dropping devel-announce ]
On Tue, Apr 29, 2014 at 11:15 AM, Alexander Larsson alexl@redhat.com wrote:
Not sure how to fix something like that though...
I think in both cases (host and container) it would be best if the local resolver offered a local-only API (e.g. unix domain sockets, kdbus). Would require teaching glibc how to speak that API though. Then if it was a Unix domain socket, we could bind mount that in from the host, same way as is the plan for other shared services.
On 29.4.2014 17:27, Colin Walters wrote:
[ Dropping devel-announce ]
On Tue, Apr 29, 2014 at 11:15 AM, Alexander Larsson alexl@redhat.com wrote:
Not sure how to fix something like that though...
I think in both cases (host and container) it would be best if the local resolver offered a local-only API (e.g. unix domain sockets, kdbus). Would require teaching glibc how to speak that API though. Then if it was a Unix domain socket, we could bind mount that in from the host, same way as is the plan for other shared services.
It can work only for libraries we are able to modify. Don't forget that there is *a lot* of DNS resolvers. IMHO anything except standard DNS protocol over UDP/TCP is no-go.
On Tue, 2014-04-29 at 17:39 +0200, Petr Spacek wrote:
On 29.4.2014 17:27, Colin Walters wrote:
[ Dropping devel-announce ]
On Tue, Apr 29, 2014 at 11:15 AM, Alexander Larsson alexl@redhat.com wrote:
Not sure how to fix something like that though...
I think in both cases (host and container) it would be best if the local resolver offered a local-only API (e.g. unix domain sockets, kdbus). Would require teaching glibc how to speak that API though. Then if it was a Unix domain socket, we could bind mount that in from the host, same way as is the plan for other shared services.
It can work only for libraries we are able to modify. Don't forget that there is *a lot* of DNS resolvers. IMHO anything except standard DNS protocol over UDP/TCP is no-go.
I have to concur, unix sockets is a dead end, there are tons of libraries that look at resolv.conf and use the server named there, and they only support the standard DNS protocol over IP (TCP and UDP).
Are we going to need a way to "bind-mount" local ports to containers too ?
Simo.
2014-04-29 17:15 GMT+02:00 Alexander Larsson alexl@redhat.com:
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
To install a local DNS resolver trusted for the DNSSEC validation
running on
127.0.0.1:53. This must be the only name server entry in
/etc/resolv.conf.
This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work.
Good point; would it be fair to treat this as a blocker?
(This also assumes that the docker containers will use the same security policy as the host; i.e. that they will be administered by the same entity, no "docker hosting" businesses.) Mirek
----- Original Message -----
= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P pjp@fedoraproject.org, Pavel Šimerda pavlix@pavlix.net, Tomas Hozza thozza@redhat.com
Ops, I was just pinged by Pavlix that the team planned this Change for F22 time- frame but I still live in the flood of F21 Changes and missed it.
So the current state is - this Change targets Fedora 22 but most of the development should land into Fedora 21 - not enabled by default - to get test coverage. To make sure this Change is in the state it could be shipped in the release as default, corner cases has to be identified and worked on, there's also NetworkManager integration that has to happen.
I'm sorry for confusion.
Jaroslav
To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
The automatic name server entries received via dhcp/vpn/wireless configurations should be stored separately, as transitory name servers to be used by the trusted local resolver. In all cases, DNSSEC validation will be done locally.
This change was submitted after the Submission deadline.
== Detailed Description == There are growing instances of discussions and debates about the need for a trusted DNSSEC validating local resolver running on 127.0.0.1:53. There are multiple reasons for having such a resolver, importantly security & usability. Security & protection of user's privacy becomes paramount with the backdrop of the increasingly snooping governments and service providers world wide.
People use Fedora on portable/mobile devices which are connected to diverse networks as and when required. The automatic DNS configurations provided by these networks are never trustworthy for DNSSEC validation. As currently there is no way to establish such trust.
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])
Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous, having a trusted local DNS resolver will not only be imperative but be unavoidable. Because it will perform the most important operation of establishing trust between two parties.
All DNS literature strongly recommends it. And amongst all discussions and debates about issues involved in establishing such trust, it is unanimously agreed upon and accepted that having a trusted local DNS resolver is the best solution possible. It'll simplify and facilitate lot of other design decisions and application development in future. (See: [1], [2], [3])
People:-
- Petr Spacek
- Paul Wouters
- Simo Sorce
- Dmitri Pal
- Carlos O'Donell
== Scope ==
- Proposal owners: Proposal owners shall have to
** define the syntax and semantics for new configuration parameters/files. ** persuade and coordinate with the other package owners to incorporate new changes/workflow in their applications.
- Other developers: (especially NetworkManager and the likes)
** would have to implement the new features/workflow for their applications adhering to the new configurations and assuming the availability of the '''trusted''' local DNS resolver. ** NetworkManager already has features & capability to support local DNS resolvers. Though few details are still under development, but are expected to realize in near future. Please see [4]
- Release engineering:
** would have to ensure that trusted local DNS resolver is available throughout the installation stage and the same is installed on all installations including LiveCDs etc.
- Policies and guidelines:
** the chosen trusted DNS resolver package(ex dnsmasq or dnssec-trigger etc.) would have to ensure that their DNS resolver starts at boot time and works out of the box without any user intervention. ** NetworkManager and others would have to be told to not tamper with the local nameserver entries in '/etc/resolv.conf' and save the dynamic nameserver entries in a separate configuration file.
[1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html [2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html [3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html [4] https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html
devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
On Tuesday 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote:
= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P pjp@fedoraproject.org, Pavel Šimerda pavlix@pavlix.net, Tomas Hozza thozza@redhat.com
To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
On my home LAN, I run my own DNSSEC-enabled server using F20 & bind 9. This local server also is my DHCP and Samba server. As usual, dynamic clients receive the LAN local domain ID and DNS server ID automatically.
How does this proposed change affect my clients, or especially my server (which uses NetworkManager (not Network), and a static IP address?
As nice as unbound may be, documentation and configuration files related to this change should not assume it is the only DNS server for Fedora.
On Wednesday, 30 April 2014 3:18 AM, Al Dunsmuir wrote: On my home LAN, I run my own DNSSEC-enabled server using F20 & bind 9. This local server also is my DHCP and Samba server. As usual, dynamic clients receive the LAN local domain ID and DNS server ID automatically. How does this proposed change affect my clients, or especially my server (which uses NetworkManager (not Network), and a static IP address?
This should work just fine. If you upgrade your F20 machine to say F22, it would have the default resolver running on 127.0.0.1:53 with its entry in '/etc/resolv.conf'. One change you would need to do is to make it listen on 0.0.0.0:53 or the on static IP address of your server. Your clients won't know that they are talking to a different DNS resolver.
If your clients are upgraded to F22, NetworkManager there would make the local resolver talk to the one on your server, because it'll receive that name server configuration via DHCP.
As nice as unbound may be, documentation and configuration files related to this change should not assume it is the only DNS server for Fedora.
Nope, we don't assume that. In fact it's been discussed earlier here -> https://lists.fedoraproject.org/pipermail/devel/2014-April/198620.html
--- Regards -Prasad http://feedmug.com
On 04/30/2014 01:17 AM, P J P wrote:
On Wednesday, 30 April 2014 3:18 AM, Al Dunsmuir wrote: On my home LAN, I run my own DNSSEC-enabled server using F20 & bind 9. This local server also is my DHCP and Samba server. As usual, dynamic clients receive the LAN local domain ID and DNS server ID automatically.
How does this proposed change affect my clients, or especially my server (which uses NetworkManager (not Network), and a static IP address?
This should work just fine. If you upgrade your F20 machine to say F22, it would have the default resolver running on 127.0.0.1:53 with its entry in '/etc/resolv.conf'. One change you would need to do is to make it listen on 0.0.0.0:53 or the on static IP address of your server. Your clients won't know that they are talking to a different DNS resolver.
If your clients are upgraded to F22, NetworkManager there would make the local resolver talk to the one on your server, because it'll receive that name server configuration via DHCP.
I think the parent post is refering to the local domain name, I have read this thread and people talk about not touching ever the resolv.conf file. What about domain and search lines? If NetworkManager will always use 127.0.0.1, it should still modify resolv.conf with the domain name received from DHCP
As nice as unbound may be, documentation and configuration files related to this change should not assume it is the only DNS server for Fedora.
Nope, we don't assume that. In fact it's been discussed earlier here -> https://lists.fedoraproject.org/pipermail/devel/2014-April/198620.html
Regards -Prasad http://feedmug.com
On Wed, 30 Apr 2014, Robert Marcano wrote:
What about domain and search lines? If NetworkManager will always use 127.0.0.1, it should still modify resolv.conf with the domain name received from DHCP
That's actually not always correct from a security point of view.
If you set your system do have domain "nohats.ca", and you "ssh bofh" and then some DHCP changes the domain/search list, you might not be going where you think you are going.
IMHO, DHCP should never touch the domain or search list _unless_ you are connecting to a trusted network - where trusted for practical reasons is defined as "you plug in a wire or use a wifi WPA secret to connect".
No open wifi should ever modify your search list. If it does that now, it is a security bug.
Paul
On Wed, 2014-04-30 at 13:22 -0400, Paul Wouters wrote:
On Wed, 30 Apr 2014, Robert Marcano wrote:
What about domain and search lines? If NetworkManager will always use 127.0.0.1, it should still modify resolv.conf with the domain name received from DHCP
That's actually not always correct from a security point of view.
If you set your system do have domain "nohats.ca", and you "ssh bofh" and then some DHCP changes the domain/search list, you might not be going where you think you are going.
IMHO, DHCP should never touch the domain or search list _unless_ you are connecting to a trusted network - where trusted for practical reasons is defined as "you plug in a wire or use a wifi WPA secret to connect".
Untrusted networks use WPA too, like coffee shops that don't leave the network open, but write the WPA key on the chalkboard menu or print it on standup cards at the tables. I've seen quite a few of these.
There's really no guessing what's trusted/not-trusted unless you're using 802.1x/WPA Enterprise, or if the user has told you explicitly to trust this network.
Dan
On Wed, 30 Apr 2014, Dan Williams wrote:
Untrusted networks use WPA too, like coffee shops that don't leave the network open, but write the WPA key on the chalkboard menu or print it on standup cards at the tables. I've seen quite a few of these.
You are at least consciously logging into that network - it is not that your device accidentally roamed on to it.
There's really no guessing what's trusted/not-trusted unless you're using 802.1x/WPA Enterprise, or if the user has told you explicitly to trust this network.
I'm fine with marking anything untrusted unless otherwise signaled by the user via the NM GUI. But others raised objections that it would break too much. I argued changing the search list already breaks my laptop security.
The problem is people have linked up the DHCP domain option with the resolv.conf domain/search keywords to make "internal only" names visible.
Between usability and security, where do we put the dial?
Paul
On Wed, 2014-04-30 at 12:16 -0430, Robert Marcano wrote:
On 04/30/2014 01:17 AM, P J P wrote:
On Wednesday, 30 April 2014 3:18 AM, Al Dunsmuir wrote: On my home LAN, I run my own DNSSEC-enabled server using F20 & bind 9. This local server also is my DHCP and Samba server. As usual, dynamic clients receive the LAN local domain ID and DNS server ID automatically.
How does this proposed change affect my clients, or especially my server (which uses NetworkManager (not Network), and a static IP address?
This should work just fine. If you upgrade your F20 machine to say F22, it would have the default resolver running on 127.0.0.1:53 with its entry in '/etc/resolv.conf'. One change you would need to do is to make it listen on 0.0.0.0:53 or the on static IP address of your server. Your clients won't know that they are talking to a different DNS resolver.
If your clients are upgraded to F22, NetworkManager there would make the local resolver talk to the one on your server, because it'll receive that name server configuration via DHCP.
I think the parent post is refering to the local domain name, I have read this thread and people talk about not touching ever the resolv.conf file. What about domain and search lines? If NetworkManager will always use 127.0.0.1, it should still modify resolv.conf with the domain name received from DHCP
Why would you care for the domain name as provided by dhcp ?
By default you wouldn't want that as you roam with a fedora laptop on completely untrusted dhcp networks that can push whatever crap as a search path.
Simo.
On Wed, 30 Apr 2014, Simo Sorce wrote:
Why would you care for the domain name as provided by dhcp ?
internal DNS views, eg server.internal.corp.com where the search domain gets set to "internal.corp.com" and "server.corp.com" does not exist.
By default you wouldn't want that as you roam with a fedora laptop on completely untrusted dhcp networks that can push whatever crap as a search path.
Yes, which is why we tentatively came to the conclusion the best compromise for this is "if the user authorizes to connect to this network, allow it". Eg using physical cable or WPA secrets.
Paul
On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
On Wed, 30 Apr 2014, Simo Sorce wrote:
Why would you care for the domain name as provided by dhcp ?
internal DNS views, eg server.internal.corp.com where the search domain gets set to "internal.corp.com" and "server.corp.com" does not exist.
By default you wouldn't want that as you roam with a fedora laptop on completely untrusted dhcp networks that can push whatever crap as a search path.
Yes, which is why we tentatively came to the conclusion the best compromise for this is "if the user authorizes to connect to this network, allow it". Eg using physical cable or WPA secrets.
Note that with NetworkManager, no WiFi connection is ever made (even open) without the user explicitly requesting it. If you have the NetworkManager-config-server RPM installed, then no ethernet connection is ever made without the user explicitly configuring it. So I'm not sure the description quite fits...
Dan
On Wed, Apr 30, 2014 at 1:02 PM, Dan Williams dcbw@redhat.com wrote:
On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
On Wed, 30 Apr 2014, Simo Sorce wrote:
Why would you care for the domain name as provided by dhcp ?
internal DNS views, eg server.internal.corp.com where the search domain gets set to "internal.corp.com" and "server.corp.com" does not exist.
By default you wouldn't want that as you roam with a fedora laptop on completely untrusted dhcp networks that can push whatever crap as a search path.
Yes, which is why we tentatively came to the conclusion the best compromise for this is "if the user authorizes to connect to this network, allow it". Eg using physical cable or WPA secrets.
Note that with NetworkManager, no WiFi connection is ever made (even open) without the user explicitly requesting it. If you have the NetworkManager-config-server RPM installed, then no ethernet connection is ever made without the user explicitly configuring it. So I'm not sure the description quite fits...
Except for that network called "linksys" that everyone has requested at some point.
--Andy
On Wed, Apr 30, 2014 at 01:06:51PM -0700, Andrew Lutomirski wrote:
On Wed, Apr 30, 2014 at 1:02 PM, Dan Williams dcbw@redhat.com wrote:
On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
On Wed, 30 Apr 2014, Simo Sorce wrote:
Why would you care for the domain name as provided by dhcp ?
internal DNS views, eg server.internal.corp.com where the search domain gets set to "internal.corp.com" and "server.corp.com" does not exist.
By default you wouldn't want that as you roam with a fedora laptop on completely untrusted dhcp networks that can push whatever crap as a search path.
Yes, which is why we tentatively came to the conclusion the best compromise for this is "if the user authorizes to connect to this network, allow it". Eg using physical cable or WPA secrets.
Note that with NetworkManager, no WiFi connection is ever made (even open) without the user explicitly requesting it. If you have the NetworkManager-config-server RPM installed, then no ethernet connection is ever made without the user explicitly configuring it. So I'm not sure the description quite fits...
Except for that network called "linksys" that everyone has requested at some point.
If I once connected to an open network called "MyFavoriteCoffeeShop" then later on someone creates a network with the same name but with malicous intent, will NetworkManager connect to it automatically?
On Wed, 2014-04-30 at 16:12 -0400, Chuck Anderson wrote:
On Wed, Apr 30, 2014 at 01:06:51PM -0700, Andrew Lutomirski wrote:
On Wed, Apr 30, 2014 at 1:02 PM, Dan Williams dcbw@redhat.com wrote:
On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
On Wed, 30 Apr 2014, Simo Sorce wrote:
Why would you care for the domain name as provided by dhcp ?
internal DNS views, eg server.internal.corp.com where the search domain gets set to "internal.corp.com" and "server.corp.com" does not exist.
By default you wouldn't want that as you roam with a fedora laptop on completely untrusted dhcp networks that can push whatever crap as a search path.
Yes, which is why we tentatively came to the conclusion the best compromise for this is "if the user authorizes to connect to this network, allow it". Eg using physical cable or WPA secrets.
Note that with NetworkManager, no WiFi connection is ever made (even open) without the user explicitly requesting it. If you have the NetworkManager-config-server RPM installed, then no ethernet connection is ever made without the user explicitly configuring it. So I'm not sure the description quite fits...
Except for that network called "linksys" that everyone has requested at some point.
If I once connected to an open network called "MyFavoriteCoffeeShop" then later on someone creates a network with the same name but with malicous intent, will NetworkManager connect to it automatically?
If it uses the same SSID and compatible security settings, then yes. That's the nature of 802.11. However, if the malicious user doesn't know the password that you have saved on your machine, or the network's CA certificate does not validate, then the attempt will fail.
Furthermore, if the user creates a network of a different type (eg, Ad-Hoc but yours is infrastructure), NM will not attempt to connect to it.
Yes, there are ways to game the system, so you are correct that there are some cases where NetworkManager could automatically attempt to connect to a malicious network that mimics a known network, the same as with most other OSs and phones.
Dan
On Wed, Apr 30, 2014 at 03:55:59PM -0500, Dan Williams wrote:
On Wed, 2014-04-30 at 16:12 -0400, Chuck Anderson wrote:
If I once connected to an open network called "MyFavoriteCoffeeShop" then later on someone creates a network with the same name but with malicous intent, will NetworkManager connect to it automatically?
If it uses the same SSID and compatible security settings, then yes. That's the nature of 802.11. However, if the malicious user doesn't know the password that you have saved on your machine, or the network's CA certificate does not validate, then the attempt will fail.
Right, so NetworkManager shouldn't treat a WIFI network connection as "trusted" by default unless it is using secure credentials. For open networks, it probably shouldn't connect automatically by default at all. It certainly shouldn't update resolv.conf with the domain from DHCP on such a network, and it shouldn't assign such a network to the "trust" zone of the firewall by default (to bring all these threads together...) I'd argue that even a WEP or WPA-PSK network /by default/ should not do those things.
Probably the only networks where it MAY default to the following behavior:
- Connect automatically - Use DHCP provided domain name - Assign network to "trust" zone for firewall or network sharing settings
are these types of networks:
- Wired network - Wi-Fi with WPA-Enterprise where there is mutual authentication going on (supplicant verifies server certificate as trusted)
For other Wi-Fi security types (open, WEP, WPA-PSK), you might be able to remember the BSSID, IP subnet, router MAC address, or other detectable things (like UPnP) to guess that you are on the same network as before, and use that to decide if you should apply that same "trust" settings as before.
Furthermore, if the user creates a network of a different type (eg, Ad-Hoc but yours is infrastructure), NM will not attempt to connect to it.
Yes, there are ways to game the system, so you are correct that there are some cases where NetworkManager could automatically attempt to connect to a malicious network that mimics a known network, the same as with most other OSs and phones.
It seems like a useful concept to simplify the user experience by lumping the above things together in a concept of "trust", while still allowing a user to go in and override the settings if desired.
devel@lists.stg.fedoraproject.org
-
Al Dunsmuir -
Alexander Larsson -
Andrew Lutomirski -
Chuck Anderson -
Colin Walters -
Dan Williams -
Jaroslav Reznik -
Matthew Miller -
Miloslav Trmač -
P J P -
Paul Wouters -
Petr Spacek -
Reindl Harald -
Robert Marcano -
Simo Sorce