10:47 a.m.
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
11:01 a.m.
On Wed, 20 Jun 2012 11:47:17 -0400
Simo Sorce <simo(a)redhat.com> 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
11:05 a.m.
On Wed, 2012-06-20 at 10:01 -0600, Kevin Fenzi wrote:
On Wed, 20 Jun 2012 11:47:17 -0400
Simo Sorce <simo(a)redhat.com> 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
11:19 a.m.
On Wed, 20 Jun 2012 12:05:57 -0400
Simo Sorce <simo(a)redhat.com> 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
6:09 p.m.
On Wed, 2012-06-20 at 10:19 -0600, Kevin Fenzi wrote:
On Wed, 20 Jun 2012 12:05:57 -0400
Simo Sorce <simo(a)redhat.com> 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
6:45 p.m.
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 <ips> 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
7:12 p.m.
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 <ips> 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
8:32 a.m.
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
10:14 a.m.
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
2:46 a.m.
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
7:10 p.m.
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
3:27 p.m.
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
3:42 p.m.
New subject: 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
9:44 a.m.
New subject: 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?
10:24 a.m.
New subject: 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-----
3:31 p.m.
New subject: DNS handling
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.
I installed DNSsec-trigger a few months ago and tried it out in a few
networks. It seemed to work as advertised in all cases. A hotspot run by a
nearby shopping center turned out to be a very hostile network where pretty
much everything except HTTPS was blocked or mangled, and DNSsec-trigger
correctly detected that it had to mask DNS as HTTPS.
The only problem I found was in how the local DNS cache interacts with
internal domains on NATed networks. I have a DNS server at home that
translates names in my own domain to private IPv4 addresses. Some of those
names are also visible publicly, but then they all point to my one public IPv4
address. When I moved from my own network to another Unbound still remembered
the private addresses, which were of course not reachable from the other
network, and when I moved back to my own network Unbound remembered the public
address, which is the wrong address to use there. (With IPv6 I don't have this
problem but IPv6 isn't exactly available in every hotspot...)
I'm not sure there is anything that DNSsec-trigger can do to work around this
if you want it to be able to work from the cache when even HTTPS is blocked.
Perhaps dual-view setups like mine should simply use a short TTL to minimize
the problem.
Björn Persson
4:05 p.m.
New subject: DNS handling
On Thu, 21 Jun 2012, Björn Persson wrote:
I installed DNSsec-trigger a few months ago and tried it out in a few
networks. It seemed to work as advertised in all cases. A hotspot run by a
nearby shopping center turned out to be a very hostile network where pretty
much everything except HTTPS was blocked or mangled, and DNSsec-trigger
correctly detected that it had to mask DNS as HTTPS.
Great! Let me know how dnssec-trigger 0.11 works, with the additional
hotspot port 80 manglign detection.
The only problem I found was in how the local DNS cache interacts
with
internal domains on NATed networks. I have a DNS server at home that
translates names in my own domain to private IPv4 addresses. Some of those
names are also visible publicly, but then they all point to my one public IPv4
address. When I moved from my own network to another Unbound still remembered
the private addresses, which were of course not reachable from the other
network, and when I moved back to my own network Unbound remembered the public
address, which is the wrong address to use there. (With IPv6 I don't have this
problem but IPv6 isn't exactly available in every hotspot...)
I'm not sure there is anything that DNSsec-trigger can do to work around this
if you want it to be able to work from the cache when even HTTPS is blocked.
Perhaps dual-view setups like mine should simply use a short TTL to minimize
the problem.
Openswan deals with this because it gets the domain from the IKE
protocol, so it can flush the domain and everything under it from the
cache. Currently there is no way to signal this with NM. However, if
your domain is the "search prefix" in your home network, then perhaps it
would be enough if NM/dnssec-trigger would flush everything of the
previous "search domain" from the cache.
Using TTL=0 or something fairly short should help you in your case though.
Paul
Björn Persson
11:15 a.m.
New subject: DNS handling
Paul Wouters wrote:
Let me know how dnssec-trigger 0.11 works, with the additional
hotspot port 80 manglign detection.
I'm afraid my laptop isn't all that usable right now –
https://bugzilla.redhat.com/show_bug.cgi?id=832723 – but I'll see what I can
do.
Björn Persson
11:21 a.m.
Simo Sorce (simo(a)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
11:57 a.m.
On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote:
Simo Sorce (simo(a)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
12:06 p.m.
On 06/20/2012 09:57 AM, Adam Williamson wrote:
On Wed, 2012-06-20 at 12:21 -0400, Bill Nottingham wrote:
> Simo Sorce (simo(a)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 <name> and
it'll try <name>.localdomain and I can also do <name>.<subname>
and
it'll find it at <name>.<subname>.workdomain. A+
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
2:34 p.m.
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 <name> and
it'll try <name>.localdomain and I can also do <name>.<subname>
and
it'll find it at <name>.<subname>.workdomain. A+
Double-plus awesome!
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================
10:36 a.m.
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 (simo(a)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 <name> and
it'll try <name>.localdomain and I can also do <name>.<subname>
and
it'll find it at <name>.<subname>.workdomain. A+
Setup? Do I need to setup dnsmasq to start @boot, or will NM start it?
10:40 a.m.
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 (simo(a)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 <name> and
> it'll try <name>.localdomain and I can also do
<name>.<subname> and
> it'll find it at <name>.<subname>.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.
10:54 a.m.
On 07/06/2012 08:40 AM, Neal Becker wrote:
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.
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.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
3:36 p.m.
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 arequipeno(a)gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================
10:53 a.m.
On 07/06/2012 08:36 AM, Neal Becker wrote:
Setup? Do I need to setup dnsmasq to start @boot, or will NM start
it?
NM appears to start it for me. I just edited the NetworkManager config
file, restarted the NM service and off it went!
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
1:28 p.m.
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.
3:24 p.m.
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
6:14 p.m.
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
6:06 a.m.
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?
2:39 a.m.
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
4319
days inactive
4336
days old
31 comments
14 participants
participants (14)
-
Adam Williamson -
Bill Nottingham -
Björn Persson -
Dan Williams -
Dan Winship -
Ian Pilcher -
Jesse Keating -
John Ellson -
Kevin Fenzi -
Neal Becker -
Nicolas Mailhot -
Paul Wouters -
Simo Sorce -
Stephen Gallagher