Re: default DNS caching name server on Fedora ?
On 07/06/2012 10:54 AM, Jesse Keating wrote: > If dnsmasq is already running, NM will probably not mess with it. Try > disabling it from start at boot and allow NM to manage the process. If dnsmasq is running and listening on 127.0.0.1, the dnsmasq instance started by NetworkManager will fail to start, and NetworkManager will operate normally. (I.e. it won't use the dnsmasq plugin.) If you want to run an instance of dnsmasq for some other purpose (to provide DNS and DHCP for a virtual network, for example) you need to make sure that it isn't listening on 127.0.0.1. -- Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
Neal Becker wrote: > Jesse Keating wrote: > >> On 06/20/2012 09:57 AM, Adam Williamson wrote: >>> On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote: Simo Sorce (s...@redhat.com) said: > Of course for this to work properly we need some level of integration > between Network Manager and the DNS caching server so that the dynamic > configurations can be pushed in/out when the related networks come > up/down. > > Discuss. man NetworkManager.conf: ... dns=plugin1,plugin2, ... List DNS plugin names separated by ','. DNS plugins are used to provide local caching nameserver functionality (which speeds up DNS queries) and to push DNS data to applications that use it. Available plugins: dnsmasq this plugin uses dnsmasq to provide local caching name‐ server functionality. ... (Note: haven't tried this.) >>> >>> See also: >>> >>> http://blogs.gnome.org/dcbw/2010/09/23/dont-try-to-run-honey/ >>> >>> Been there since 2010. >>> >> >> So I just gave this a try. Already had dnsmasq installed so I just >> edited the config file and restarted the NetworkManager service. Then >> connected to my VPN. >> >> It. Just. Works. Amazing! Not only does it just work for resolution, >> but it also works for multiple search domains. I can ping and >> it'll try .localdomain and I can also do . and >> it'll find it at ..workdomain. A+ >> >> > > Setup? Do I need to setup dnsmasq to start @boot, or will NM start it? > I just tried it. Install dnsmasq, configure to start @boot. Add dns=dnsmasq. /etc/resolv.conf does NOT say 127.0.0.1 as I would expect. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
Jesse Keating wrote: > On 06/20/2012 09:57 AM, Adam Williamson wrote: >> On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote: >>> Simo Sorce (s...@redhat.com) said: Of course for this to work properly we need some level of integration between Network Manager and the DNS caching server so that the dynamic configurations can be pushed in/out when the related networks come up/down. Discuss. >>> >>> man NetworkManager.conf: >>> >>> ... >>> dns=plugin1,plugin2, ... >>>List DNS plugin names separated by ','. DNS plugins are used >>>to >>>provide local caching nameserver functionality (which speeds >>>up DNS queries) and to push DNS data to applications that use >>>it. >>> >>>Available plugins: >>> >>>dnsmasq >>> this plugin uses dnsmasq to provide local caching >>> name‐ server functionality. >>> ... >>> >>> (Note: haven't tried this.) >> >> See also: >> >> http://blogs.gnome.org/dcbw/2010/09/23/dont-try-to-run-honey/ >> >> Been there since 2010. >> > > So I just gave this a try. Already had dnsmasq installed so I just > edited the config file and restarted the NetworkManager service. Then > connected to my VPN. > > It. Just. Works. Amazing! Not only does it just work for resolution, > but it also works for multiple search domains. I can ping and > it'll try .localdomain and I can also do . and > it'll find it at ..workdomain. A+ > > Setup? Do I need to setup dnsmasq to start @boot, or will NM start it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
Dan Williams wrote: > On Wed, 2012-06-20 at 16:24 -0400, Paul Wouters wrote: >> On Wed, 20 Jun 2012, Simo Sorce wrote: >> >> > There are at least 2 situations where it is needed, and they are common >> > or will be common enough. >> > >> > The 2 use cases for which a properly configurable and dynamically >> > changeable caching DNA name server would be really useful are: >> > - DNSSEC verification >> > - Clients using VPNs into private networks. >> >> This already works out of the box using unbound, dnssec-trigger and >> openswan. I use it every day to connect to the red hat vpn, even >> if I'm at a hotspot place. > > NM has also done this for a couple years when you use the dnsmasq DNS > plugin for NM. It'll also set up the reverse address mappings so that > reverse lookups work, which I found necessary for some stuff (krb5 I > think?). It's not hard to create a new plugin, one could be created for > dnssec-trigger and even for unbound by itself. > > NM will ask plugins to handle DNS from any source it receives the > information from, be that static configuration, DHCP, VPNs, PPP, mobile > broadband, etc. If no plugin is registered, or if those plugins fail to > handle it, NM falls back to writing /etc/resolv.conf, where, of course, > you don't get nice split DNS because glibc is simple. > > Dan > Where dould I find this dnsmasq DNS plugin for NM? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On 06/20/2012 12:06 PM, Jesse Keating wrote: > So I just gave this a try. Already had dnsmasq installed so I just > edited the config file and restarted the NetworkManager service. Then > connected to my VPN. > > It. Just. Works. Amazing! Not only does it just work for resolution, > but it also works for multiple search domains. I can ping and > it'll try .localdomain and I can also do . and > it'll find it at ..workdomain. A+ Double-plus awesome! -- Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 2012-06-20 at 19:45 -0400, Paul Wouters wrote: > On Wed, 20 Jun 2012, Dan Williams wrote: > > > I spent some time looking at this today. NM already has plugins for > > dnsmasq and a long-since-dead one for bind. We can certainly add a > > plugin for dnssec-trigger or even unbound itself as well. The mechanism > > by which dnssec-trigger currently interfaces with NM (dispatcher script) > > is not optimal for a DNS plugin, and it requires setting resolv.conf > > immutable which is a hack. > > It is. Which is something I would like to address. Let me explain a > little of why the resolv hackery. The goals are to 1) provide the user > with DNSSEC security and have them decided when to disable it, and 2) to > try and use the DHCP obtained forwards where-ever possible as to not to > destroy the DNS caching hierarchy on the internet. > > Sometimes we need to allow forged DNS to get past hotspots. We do not > want any of these answers to get cached. So we take the unbound cache > "offline". Depending on circumstances, resolv.conf will either be filled > in with the DHCP obtained DNS entries (as obtained from nm) which we call > "insecure mode" or it will point it to 127.0.0.1 where unbound listens. > If we cannot do DNSSEC and the user has opted not to go insecure, > then unbound forwards to 127.0.0.127 (while resolv.conf still points to > 127.0.0.1) causing new DNS to die (but cached DNS to work, plus it uses > pre-fetching so there is still a good chance lots of dns works properly). > > > You can envision a system where NM just sends out dbus signals that > > registered handlers like dnsmasq or dnssec-trigger would listen for, or > > a script-based system like the dispatcher scripts but specifically for > > DNS, but both these have some robustness concerns. > > Ideally, I would like NM to trigger the hotspot and dns detection before > any application is aware we are on a new network. If we detect a hotspot, > fire up a sandboxed browser login to get passed the hotspot, this might > require some of our DNS magic (dnssec-trigger hotspot mode). Then when > we detected we're no longer sandboxed, reprobe the dns situation, then > let the applications know we have a new network. A lot of this logic is > now in dnssec-trigger, and might be better elsewhere. One of the reasons > this is a daemon is that it keeps probing DNS/HTTP when in hotspot/insecure > mode to see if it can switch back to secure mode. Yeah, that's basically what we should be doing. NM's connectivity detection should figure out whether we're on a hotspot and handle the sandboxing/login, since we need to start parsing stuff like WISPR here. We'd be sandboxed until we know we're logged in an get a unintercepted response from the upstream DNS servers. Dan > > The situation I do *not* want to get into at any point is where DNS is > > broken. > > While I agree, my goal goes further. I want my DNS to work, with DNSSEC > security, and only go insecure when given permission to do so, without > getting locked out by wrong DNS or various hotspot technologies. > > > That's what we currently run into with various hacks like > > openresolv/resolvconf, immutable /etc/resolv.conf, etc. That's why NM > > attempts to monitor these services and takes a very hands-on approach. > > The more processes we run, the more possibilities there are for things > > to get misconfigured or fall through cracks. Which is why I'm a bit > > concerned about the chain of NM -> dnssec-trigger -> unbound... > > I'd love a better integration, I was just not yet aware of plans for > hotspot detection in NM. The hotspot and DNS issues are very entwined. > This was a relative easy way to get a decent proof of concept going. The > reason I voted against making this setup the default was exactly the > lack of integration with NM. > > As a first step, we could get rid of the hook and NM could just call > dnssec-trigger-control submit while it keeps a connection open > to dnssec-trigger-control results to get informed of probing updates > from dnssec-triggerd. And we could add an option to dnssec-triggerd to > not rewrite resolv.conf and let NM handle that part based on its > interpretation of the "results". > > > (also, an aside: why the heck do resolvconf and dnssec-trigger require > > an interface name??? DNS information has nothing do with network > > interfaces, despite some DNS info coming from interface-specific sources > > like DHCP...) > > Speaking for dnssec-trigger it does not care as far as I know. It only > uses nmcli to get the list of DHCP obtainted DNS servers from NM, and > I have noticed the syntax seems broken on some versions of NM (eg F16). > I'd be happy to hear the best way of obtaining the DHCP DNS servers from > NM on various fedora/rhel versions. > > Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Fri, 2012-06-22 at 09:46 +0200, Nicolas Mailhot wrote: > Le Jeu 21 juin 2012 01:09, Dan Williams a écrit : > > I spent some time looking at this today. NM already has plugins for > > dnsmasq and a long-since-dead one for bind. We can certainly add a > > plugin for dnssec-trigger or even unbound > > Which is a mess. How many DNS services do we need on a single box? > > Please make NM work well with one full-featured DNS service (any one I don't > care which one) and make this DNS service the default in Fedora so there is no > situation like NM wants to launch DNS 1, admins needs DNS 2 because DNS 1 is > missing features, IPA or samba wants to run DNS 3 because that's what it > integrates with, etc It is. But apparently nobody is writing the One DNS Local Caching Nameserver To Rule Them All. dnsmasq has features unbound apparently doesn't and the other way around. To do useful DNSSEC you need seem to need dnssec-trigger + unbound. etc. It is a mess. But I certainly can't solve it. Dan > This is getting as bad as the spellchecker situation a few years ago. > > -- > Nicolas Mailhot > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
Le Jeu 21 juin 2012 01:09, Dan Williams a écrit : > I spent some time looking at this today. NM already has plugins for > dnsmasq and a long-since-dead one for bind. We can certainly add a > plugin for dnssec-trigger or even unbound Which is a mess. How many DNS services do we need on a single box? Please make NM work well with one full-featured DNS service (any one I don't care which one) and make this DNS service the default in Fedora so there is no situation like NM wants to launch DNS 1, admins needs DNS 2 because DNS 1 is missing features, IPA or samba wants to run DNS 3 because that's what it integrates with, etc This is getting as bad as the spellchecker situation a few years ago. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
Le Mer 20 juin 2012 17:47, Simo Sorce a écrit : > The 2 use cases for which a properly configurable and dynamically > changeable caching DNA name server would be really useful are: > - DNSSEC verification > - Clients using VPNs into private networks. 3. ISP has junk DNS services and bypassing them with its own cache just works 4. Provide DNS for home network and cache external DNS -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DNS handling was Re: default DNS caching name server on Fedora ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/21/2012 10:44 AM, Stephen Gallagher wrote: > On Wed, 2012-06-20 at 16:42 -0400, Paul Wouters wrote: >> Install dnssec-trigger, start the dnssec-trigger panel >> application and please give me feedback! Especially when you >> experience dns failures at hotspots. There are so many different >> kinds of broken dns out there, I'm sure we need to do more >> inventive things to make it work for everyone. > > [sgallagh@sgallagh520 ~]$ dnssec-trigger Gtk-Message: Failed to > load module "pk-gtk-module" Jun 21 10:42:34 > dnssec-trigger-panel[12742] fatal error: cannot setup ssl context: > Error setting up SSL_CTX client key and cert error:02001002:system > library:fopen:No such file or directory > > This was after a 'sudo yum install dnssec-trigger > --enablerepo=rawhide' on a Fedora 17 x86_64 system. Are there other > configuration steps I should be aware of? It looks like the dnssec-triggerd-keygen.service (and after that dnssec-triggerd.service) were not started yet. Either start these using systemctl or reboot. Paul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJP4zyTAAoJEISzragz8T5uLhQH/1kPLgY9g34/AAsVwXiMx7tV rCfLJf9Zdo7c+Jfh6ZcHsahMh9uDdZDbSBfKlqNahQ5u7xFxvVAQ9j81192Xx/a3 eGXNM9RWAaKELcjpkxyuLayicO8QU6d6si/OzsgUBH75hsH0Wfz3IUxxTR/Ppm6e vVZQQeWYTPhfrujNLXBOO09dzQEjBSDhfHyFY+TNjD0cxrsC6XgvNOFFux35sdCL cKHXu6lV4csigmqpOOaobQKVs5a6p23d7cOpKo6dtJIPhAxOVwzsy3MygiMfxYj0 SS7fRxfMAl43nijo4cvnDgTy0cmjjP+TZLOrK7EsN/SRgcc8hD1pENBO3vRLiME= =h6eH -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Thu, 2012-06-21 at 09:32 -0400, Dan Winship wrote: > On 06/20/2012 07:09 PM, Dan Williams wrote: > > (also, an aside: why the heck do resolvconf and dnssec-trigger require > > an interface name??? DNS information has nothing do with network > > interfaces, despite some DNS info coming from interface-specific sources > > like DHCP...) > > resolvconf requires an interface name for the same reason NMDnsManager > does, because it behaves in exactly the same way as NMDnsManager. (It > keeps track of multiple DNS configurations, merges them together into a > single resolv.conf, and lets you add new ones and remove old ones in any > order.) The NM resolvconf plugin is broken in how it uses resolvconf. NMDnsManager only uses one because it has to pass it to either resolvconf or netconf, or for logging, or for IPv6 LL address formatting. We don't need it for anything else. The problem with resolvconf is that it uses the interface for priority rules which you can modify via config files, so that say "eth0" is always preferred above wlan0. The problem with that is that the DNS information is coming from a *network*, not an interface, and the network which an interface is connected to can change. So we don't want to talk about *interfaces* here, we want to talk about networks instead. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DNS handling was Re: default DNS caching name server on Fedora ?
On Wed, 2012-06-20 at 16:42 -0400, Paul Wouters wrote: > Install dnssec-trigger, start the dnssec-trigger panel application and > please give me feedback! Especially when you experience dns failures at > hotspots. There are so many different kinds of broken dns out there, I'm > sure we need to do more inventive things to make it work for everyone. [sgallagh@sgallagh520 ~]$ dnssec-trigger Gtk-Message: Failed to load module "pk-gtk-module" Jun 21 10:42:34 dnssec-trigger-panel[12742] fatal error: cannot setup ssl context: Error setting up SSL_CTX client key and cert error:02001002:system library:fopen:No such file or directory This was after a 'sudo yum install dnssec-trigger --enablerepo=rawhide' on a Fedora 17 x86_64 system. Are there other configuration steps I should be aware of? signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On 06/20/2012 07:09 PM, Dan Williams wrote: > (also, an aside: why the heck do resolvconf and dnssec-trigger require > an interface name??? DNS information has nothing do with network > interfaces, despite some DNS info coming from interface-specific sources > like DHCP...) resolvconf requires an interface name for the same reason NMDnsManager does, because it behaves in exactly the same way as NMDnsManager. (It keeps track of multiple DNS configurations, merges them together into a single resolv.conf, and lets you add new ones and remove old ones in any order.) The NM resolvconf plugin is broken in how it uses resolvconf. -- Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 20 Jun 2012, Dan Williams wrote: I spent some time looking at this today. NM already has plugins for dnsmasq and a long-since-dead one for bind. We can certainly add a plugin for dnssec-trigger or even unbound itself as well. The mechanism by which dnssec-trigger currently interfaces with NM (dispatcher script) is not optimal for a DNS plugin, and it requires setting resolv.conf immutable which is a hack. It is. Which is something I would like to address. Let me explain a little of why the resolv hackery. The goals are to 1) provide the user with DNSSEC security and have them decided when to disable it, and 2) to try and use the DHCP obtained forwards where-ever possible as to not to destroy the DNS caching hierarchy on the internet. Sometimes we need to allow forged DNS to get past hotspots. We do not want any of these answers to get cached. So we take the unbound cache "offline". Depending on circumstances, resolv.conf will either be filled in with the DHCP obtained DNS entries (as obtained from nm) which we call "insecure mode" or it will point it to 127.0.0.1 where unbound listens. If we cannot do DNSSEC and the user has opted not to go insecure, then unbound forwards to 127.0.0.127 (while resolv.conf still points to 127.0.0.1) causing new DNS to die (but cached DNS to work, plus it uses pre-fetching so there is still a good chance lots of dns works properly). You can envision a system where NM just sends out dbus signals that registered handlers like dnsmasq or dnssec-trigger would listen for, or a script-based system like the dispatcher scripts but specifically for DNS, but both these have some robustness concerns. Ideally, I would like NM to trigger the hotspot and dns detection before any application is aware we are on a new network. If we detect a hotspot, fire up a sandboxed browser login to get passed the hotspot, this might require some of our DNS magic (dnssec-trigger hotspot mode). Then when we detected we're no longer sandboxed, reprobe the dns situation, then let the applications know we have a new network. A lot of this logic is now in dnssec-trigger, and might be better elsewhere. One of the reasons this is a daemon is that it keeps probing DNS/HTTP when in hotspot/insecure mode to see if it can switch back to secure mode. The situation I do *not* want to get into at any point is where DNS is broken. While I agree, my goal goes further. I want my DNS to work, with DNSSEC security, and only go insecure when given permission to do so, without getting locked out by wrong DNS or various hotspot technologies. That's what we currently run into with various hacks like openresolv/resolvconf, immutable /etc/resolv.conf, etc. That's why NM attempts to monitor these services and takes a very hands-on approach. The more processes we run, the more possibilities there are for things to get misconfigured or fall through cracks. Which is why I'm a bit concerned about the chain of NM -> dnssec-trigger -> unbound... I'd love a better integration, I was just not yet aware of plans for hotspot detection in NM. The hotspot and DNS issues are very entwined. This was a relative easy way to get a decent proof of concept going. The reason I voted against making this setup the default was exactly the lack of integration with NM. As a first step, we could get rid of the hook and NM could just call dnssec-trigger-control submit while it keeps a connection open to dnssec-trigger-control results to get informed of probing updates from dnssec-triggerd. And we could add an option to dnssec-triggerd to not rewrite resolv.conf and let NM handle that part based on its interpretation of the "results". (also, an aside: why the heck do resolvconf and dnssec-trigger require an interface name??? DNS information has nothing do with network interfaces, despite some DNS info coming from interface-specific sources like DHCP...) Speaking for dnssec-trigger it does not care as far as I know. It only uses nmcli to get the list of DHCP obtainted DNS servers from NM, and I have noticed the syntax seems broken on some versions of NM (eg F16). I'd be happy to hear the best way of obtaining the DHCP DNS servers from NM on various fedora/rhel versions. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 2012-06-20 at 16:24 -0400, Paul Wouters wrote: > On Wed, 20 Jun 2012, Simo Sorce wrote: > > > There are at least 2 situations where it is needed, and they are common > > or will be common enough. > > > > The 2 use cases for which a properly configurable and dynamically > > changeable caching DNA name server would be really useful are: > > - DNSSEC verification > > - Clients using VPNs into private networks. > > This already works out of the box using unbound, dnssec-trigger and > openswan. I use it every day to connect to the red hat vpn, even > if I'm at a hotspot place. NM has also done this for a couple years when you use the dnsmasq DNS plugin for NM. It'll also set up the reverse address mappings so that reverse lookups work, which I found necessary for some stuff (krb5 I think?). It's not hard to create a new plugin, one could be created for dnssec-trigger and even for unbound by itself. NM will ask plugins to handle DNS from any source it receives the information from, be that static configuration, DHCP, VPNs, PPP, mobile broadband, etc. If no plugin is registered, or if those plugins fail to handle it, NM falls back to writing /etc/resolv.conf, where, of course, you don't get nice split DNS because glibc is simple. Dan > > A good name caching server would forward all .redhat.com DNs request top > > the DNS addresses provided by the VPN connection, all my .home addresses > > to my local DNS server (provided by dhcp) and perhaps all other > > addresses to a configurable 'default DNS server'. > > openswan does this based on the XAUTH informationn received. It receives > the domain (redhat.com) and the name server IPs, and reconfigured > unbound on the fly to forward those. When the tunnel is brought down, > the DNS records are flushed so the external view becomes visible again. > > Please give it a shot, or ping me if you want to check your > configuration. But it should be out of the box (apart from the openswan > ipsec.conf) > > Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 2012-06-20 at 10:19 -0600, Kevin Fenzi wrote: > On Wed, 20 Jun 2012 12:05:57 -0400 > Simo Sorce wrote: > > > Yes this is all good 'n' nice. > > > > The point is, can we/should we/want we make this the default ? > > (And work on integrating NM -> unbound automatic configuration ?) > > I'd be in favor of that. ;) > > I don't want to speak for the feature owner/unbound/dnssec maintainer > tho. I spent some time looking at this today. NM already has plugins for dnsmasq and a long-since-dead one for bind. We can certainly add a plugin for dnssec-trigger or even unbound itself as well. The mechanism by which dnssec-trigger currently interfaces with NM (dispatcher script) is not optimal for a DNS plugin, and it requires setting resolv.conf immutable which is a hack. NM also has a "priority" for these plugins, so one gets asked to set up DNS first, and if that fails for whatever reason, we go on to the second one. That's all done by editing NetworkManager.conf (see the manpage). The plugins attempt to be robust to failure, such that if dnsmasq quits or the configuration is invalid (which happened once when a new version of dnsmasq came out), NM will either respawn the plugin or fall back to writing resolv.conf to ensure that there is some network connectivity. You can envision a system where NM just sends out dbus signals that registered handlers like dnsmasq or dnssec-trigger would listen for, or a script-based system like the dispatcher scripts but specifically for DNS, but both these have some robustness concerns. The situation I do *not* want to get into at any point is where DNS is broken. That's what we currently run into with various hacks like openresolv/resolvconf, immutable /etc/resolv.conf, etc. That's why NM attempts to monitor these services and takes a very hands-on approach. The more processes we run, the more possibilities there are for things to get misconfigured or fall through cracks. Which is why I'm a bit concerned about the chain of NM -> dnssec-trigger -> unbound... (also, an aside: why the heck do resolvconf and dnssec-trigger require an interface name??? DNS information has nothing do with network interfaces, despite some DNS info coming from interface-specific sources like DHCP...) Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
DNS handling was Re: default DNS caching name server on Fedora ?
People have might missed it before, but Fedora does a lot now with handling the various DNS manglings it can encounter in the wild. If you install dnssec-trigger from rawhide, then your DNS will be automatically configured using DNSSEC and with as much security as possible, while detecting hotspots and telling you when you are temporarilly using insecure DNS (eg to authenticate a hotspot) dnssec-trigger uses two web pages run by the fedora infrastructure team to do this. One page to trigger redirects on port 80, and one page to detect port 80 mangling. Upon connecting to a new network, dnssec-trigger performs a full test of the DNS server supplied by the DHCP server. If it supports DNSSEC, it is used to forward all queries. If not, then a free port 53 is probed to see if unbound should do all recursing itself. If that is broken or blocked, it will attempt to talk raw DNS over port 80, or DNS wrapped in SSL over port 443 to three DNS resolvers run by Fedora (you can see these configurations in /etc/dnssec-trigger/dnssec-triggerd.conf). If that also fails, then it will warn you and give you a choice between going insecure or only using already cached DNS. It will also try to connect to fedoraproject.org/static/hotspot.html and detect if you are hotspotted. It will popup a warning for you to login to the hotspot with a new browser window. Once the hotspot.html page looks "normal", we know you authenticated (clicked OK, or paid) and DNS is reprobed to see if we now can do DNSSEC. We are trying to work under a lot of different scenario's, including hotspots that break DNS, hotspots intercepting all port 53, hotspots counting in you doing port 80 traffic to do an http redirect, etc etc. This is currently mostly done by dnssec-triggerd, which reconfigures unbound on the fly. When going "insecure", it rewrites resolv.conf to point to the DHCP obtained DNS, but when it is secure, it will point DNS to 127.0.0.1 where unbound will answer. And as I said in my previous email, when you bring up a VPN using openswan, it deals with the specific domain and its name servers for you dynamically as well. But vpnc does not yet support this. What I would like to do next is to tie network manager and dnssec-trigger more closely together, so we don't have to do tricks like making resolv.conf immutable to prevent others from bypassing DNSSEC security by rewriting that file. Install dnssec-trigger, start the dnssec-trigger panel application and please give me feedback! Especially when you experience dns failures at hotspots. There are so many different kinds of broken dns out there, I'm sure we need to do more inventive things to make it work for everyone. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 20 Jun 2012, Kevin Fenzi wrote:
Connect your vpn, etc.
Then tell unbound what you want it to do:
unbound-control forward_add redhat.com x.x.x.x y.y.y.y
unbound-control forward_add yourdomain z.z.z.z
(unbound-control gives you a lot of control, you can flush cache, setup
forward, see it's man page or help for all the options).
I'm not sure how hard/possible it is for dnssec-trigger to get this
info from the vpn/NM and just set it for you.
You need to do a little more, see /usr/lib/ipsec/_updown.netkey which
is where openswan handles this:
updateresolvconf() {
if [ -n "$PLUTO_CISCO_DNS_INFO" ]; then
if [ -n "`pidof unbound`" -a -n "$PLUTO_CISCO_DOMAIN_INFO" ];
then
echo "updating local nameserver for $PLUTO_CISCO_DOMAIN_INFO with
$PLUTO_CISCO_DNS_INFO"
/usr/sbin/unbound-control forward_add $PLUTO_CISCO_DOMAIN_INFO
$PLUTO_CISCO_DNS_INFO
/usr/sbin/unbound-control flush_zone $PLUTO_CISCO_DOMAIN_INFO
return
fi
fi
restoreresolvconf() {
if [ -n "$PLUTO_CISCO_DNS_INFO" ]; then
if [ -n "`pidof unbound`" ]; then
echo "flushing local nameserver of $PLUTO_CISCO_DOMAIN_INFO"
/usr/sbin/unbound-control forward_remove
$PLUTO_CISCO_DOMAIN_INFO
/usr/sbin/unbound-control flush_zone
$PLUTO_CISCO_DOMAIN_INFO
fi
return
fi
The flush_zone is needed so you can access the domain again using the
public view DNS.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 20 Jun 2012, Simo Sorce wrote: There are at least 2 situations where it is needed, and they are common or will be common enough. The 2 use cases for which a properly configurable and dynamically changeable caching DNA name server would be really useful are: - DNSSEC verification - Clients using VPNs into private networks. This already works out of the box using unbound, dnssec-trigger and openswan. I use it every day to connect to the red hat vpn, even if I'm at a hotspot place. A good name caching server would forward all .redhat.com DNs request top the DNS addresses provided by the VPN connection, all my .home addresses to my local DNS server (provided by dhcp) and perhaps all other addresses to a configurable 'default DNS server'. openswan does this based on the XAUTH informationn received. It receives the domain (redhat.com) and the name server IPs, and reconfigured unbound on the fly to forward those. When the tunnel is brought down, the DNS records are flushed so the external view becomes visible again. Please give it a shot, or ping me if you want to check your configuration. But it should be out of the box (apart from the openswan ipsec.conf) Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
Simo, For the VPN scenario I've been happily using "dnrd" for some time. I use it to steer DNS requests for "mycompany.com" to the company's DNS servers, and all other DNS requests to the external servers. Unlike just adding the company DNS servers to /etc/resolv.conf, this never uses the company's DNS for external domain resolution, even if the primary ISP's DNS servers are down. I also use routing to steer company traffic to the VPN, and the rest to my default route. John On 06/20/2012 11:47 AM, Simo Sorce wrote: Ok, I guess this topic has been brought up before, but I think some things changed recently that would warrant seriously considering adding a default caching name server in fedora installs. There are at least 2 situations where it is needed, and they are common or will be common enough. The 2 use cases for which a properly configurable and dynamically changeable caching DNA name server would be really useful are: - DNSSEC verification - Clients using VPNs into private networks. The first case is already in the works, and the reason it needs a caching DNS name server is the complexity of dealing with DNSSEC verification. I won't spend time on that except for saying this effort should be part of a unified solution. The second case is what is really hurting me. I have my own DNS server at home that resolves address only for my private network, and forwards any other request. When I connect to my employer VPN however I need to use their DNS server to resolve their internal machines, the same happens to pretty much any other VPN service I have used. Also I do not need to route all DNS traffic in the VPN for all web sites, mostly for performance reasons, but also for privacy reasons. This could be easily solved if we have a caching DNS server that can be dynamically change to forward DNS requests to the proper DNS server only for the private domains they provide. A good name caching server would forward all .redhat.com DNs request top the DNS addresses provided by the VPN connection, all my .home addresses to my local DNS server (provided by dhcp) and perhaps all other addresses to a configurable 'default DNS server'. Of course for this to work properly we need some level of integration between Network Manager and the DNS caching server so that the dynamic configurations can be pushed in/out when the related networks come up/down. Discuss. Simo. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On 06/20/2012 09:57 AM, Adam Williamson wrote: On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote: Simo Sorce (s...@redhat.com) said: Of course for this to work properly we need some level of integration between Network Manager and the DNS caching server so that the dynamic configurations can be pushed in/out when the related networks come up/down. Discuss. man NetworkManager.conf: ... dns=plugin1,plugin2, ... List DNS plugin names separated by ','. DNS plugins are used to provide local caching nameserver functionality (which speeds up DNS queries) and to push DNS data to applications that use it. Available plugins: dnsmasq this plugin uses dnsmasq to provide local caching name‐ server functionality. ... (Note: haven't tried this.) See also: http://blogs.gnome.org/dcbw/2010/09/23/dont-try-to-run-honey/ Been there since 2010. So I just gave this a try. Already had dnsmasq installed so I just edited the config file and restarted the NetworkManager service. Then connected to my VPN. It. Just. Works. Amazing! Not only does it just work for resolution, but it also works for multiple search domains. I can ping and it'll try .localdomain and I can also do . and it'll find it at ..workdomain. A+ -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote: > Simo Sorce (s...@redhat.com) said: > > Of course for this to work properly we need some level of integration > > between Network Manager and the DNS caching server so that the dynamic > > configurations can be pushed in/out when the related networks come > > up/down. > > > > Discuss. > > man NetworkManager.conf: > > ... >dns=plugin1,plugin2, ... > List DNS plugin names separated by ','. DNS plugins are used to > provide local caching nameserver functionality (which speeds up > DNS queries) and to push DNS data to applications that use it. > > Available plugins: > > dnsmasq > this plugin uses dnsmasq to provide local caching name‐ > server functionality. > ... > > (Note: haven't tried this.) See also: http://blogs.gnome.org/dcbw/2010/09/23/dont-try-to-run-honey/ Been there since 2010. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
Simo Sorce (s...@redhat.com) said: > Of course for this to work properly we need some level of integration > between Network Manager and the DNS caching server so that the dynamic > configurations can be pushed in/out when the related networks come > up/down. > > Discuss. man NetworkManager.conf: ... dns=plugin1,plugin2, ... List DNS plugin names separated by ','. DNS plugins are used to provide local caching nameserver functionality (which speeds up DNS queries) and to push DNS data to applications that use it. Available plugins: dnsmasq this plugin uses dnsmasq to provide local caching name‐ server functionality. ... (Note: haven't tried this.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 20 Jun 2012 12:05:57 -0400 Simo Sorce wrote: > Yes this is all good 'n' nice. > > The point is, can we/should we/want we make this the default ? > (And work on integrating NM -> unbound automatic configuration ?) I'd be in favor of that. ;) I don't want to speak for the feature owner/unbound/dnssec maintainer tho. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 2012-06-20 at 10:01 -0600, Kevin Fenzi wrote: > On Wed, 20 Jun 2012 11:47:17 -0400 > Simo Sorce wrote: > > > Ok, I guess this topic has been brought up before, but I think some > > things changed recently that would warrant seriously considering > > adding a default caching name server in fedora installs. > > ...snip... > > > > > Discuss. > > You can already (all be it somewhat manually) do this with > dnssec-trigger. > > yum install dnssec-trigger > > reboot or: > > /bin/systemctl restart dnssec-triggerd.service > /bin/systemctl restart dnssec-triggerd-keygen.service > > Connect your vpn, etc. > > Then tell unbound what you want it to do: > > unbound-control forward_add redhat.com x.x.x.x y.y.y.y > unbound-control forward_add yourdomain z.z.z.z > > (unbound-control gives you a lot of control, you can flush cache, setup > forward, see it's man page or help for all the options). > > I'm not sure how hard/possible it is for dnssec-trigger to get this > info from the vpn/NM and just set it for you. Yes this is all good 'n' nice. The point is, can we/should we/want we make this the default ? (And work on integrating NM -> unbound automatic configuration ?) Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default DNS caching name server on Fedora ?
On Wed, 20 Jun 2012 11:47:17 -0400 Simo Sorce wrote: > Ok, I guess this topic has been brought up before, but I think some > things changed recently that would warrant seriously considering > adding a default caching name server in fedora installs. ...snip... > > Discuss. You can already (all be it somewhat manually) do this with dnssec-trigger. yum install dnssec-trigger reboot or: /bin/systemctl restart dnssec-triggerd.service /bin/systemctl restart dnssec-triggerd-keygen.service Connect your vpn, etc. Then tell unbound what you want it to do: unbound-control forward_add redhat.com x.x.x.x y.y.y.y unbound-control forward_add yourdomain z.z.z.z (unbound-control gives you a lot of control, you can flush cache, setup forward, see it's man page or help for all the options). I'm not sure how hard/possible it is for dnssec-trigger to get this info from the vpn/NM and just set it for you. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
default DNS caching name server on Fedora ?
Ok, I guess this topic has been brought up before, but I think some things changed recently that would warrant seriously considering adding a default caching name server in fedora installs. There are at least 2 situations where it is needed, and they are common or will be common enough. The 2 use cases for which a properly configurable and dynamically changeable caching DNA name server would be really useful are: - DNSSEC verification - Clients using VPNs into private networks. The first case is already in the works, and the reason it needs a caching DNS name server is the complexity of dealing with DNSSEC verification. I won't spend time on that except for saying this effort should be part of a unified solution. The second case is what is really hurting me. I have my own DNS server at home that resolves address only for my private network, and forwards any other request. When I connect to my employer VPN however I need to use their DNS server to resolve their internal machines, the same happens to pretty much any other VPN service I have used. Also I do not need to route all DNS traffic in the VPN for all web sites, mostly for performance reasons, but also for privacy reasons. This could be easily solved if we have a caching DNS server that can be dynamically change to forward DNS requests to the proper DNS server only for the private domains they provide. A good name caching server would forward all .redhat.com DNs request top the DNS addresses provided by the VPN connection, all my .home addresses to my local DNS server (provided by dhcp) and perhaps all other addresses to a configurable 'default DNS server'. Of course for this to work properly we need some level of integration between Network Manager and the DNS caching server so that the dynamic configurations can be pushed in/out when the related networks come up/down. Discuss. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
