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.
> A good name caching server would forward all .redhat.com DNs
> 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