The modern world of spliced together multi-layer DNS resolution

May 8, 2014

In the beginning most people's DNS resolution was relatively simple. You might be directly on the Internet and only dealing with other things there, or your organization might have directly exposed internal IPs in general DNS, or at the least your machine was fully inside your organization on a straightforward network. As yesterday's entry on using Unbound to do split DNS resolution implicitly points out, today's world is often not anywhere near that simple any more. Today's DNS resolution is increasingly assembled by splicing together multiple DNS namespaces, sometimes ones that dynamically appear and disappear.

On clients you can have the basic external DNS resolution obtained from whatever base network you're connected to at the moment (which can change), plus your own names for things like local virtual machines, plus some number of VPNs (you may have more than one depending in what you're doing). The VPNs may both introduce new names and override DNS resolution for existing 'public' (general Internet) names, due to things like split horizon DNS. The local names for eg virtual machines might be on your own client machine or they might be on a server on the local network but not part of the regular 'normal' DNS infrastructure for various reasons.

(We have groups here that want to do a bunch of stuff with virtual machines without constantly bugging us to add and remove DNS entries in our own DNS servers. Sometimes they want to do this VM work on a separate unrouted subnet. In theory these groups could run local caching DNS servers and splice in their own virtual machines but in practice this runs into all sorts of problems, especially if we provide DHCP for their regular client machines. We're perhaps at the height of baroque peculiarity here.)

You have quite similar situations with (organizational) caching DNS servers. Your DNS view can be a composite of zones you actually transfer from internal primaries, data queried from the outside world, and zones (internal or external) that must be explicitly delegated or forwarded to other DNS servers (perhaps because they have to be dynamically updated, perhaps because groups want to run their own DNS servers). You may even want to cascade some or all of your remaining 'general Internet' queries through other servers instead going straight to the root zone and walking downwards.

As Unbound illustrates, modern DNS servers can do this but they don't necessarily do it gracefully. Especially they probably don't deal gracefully with bits of the namespace surgery changing on the fly, with DNS resolution for some names either mutating or just disappearing. Speaking as someone who deals with this both on clients and on caching DNS servers, it would be nice if DNS servers were better at this.

(My optimistic hope is that the increase emphasis on having a local resolver in order to do end to end DNSSEC validation will start pushing people on at least the client side of this.)

Written on 08 May 2014.
« How I use Unbound on Fedora 20 to deal with the VPN DNS issue
Operating systems cannot be hermetically sealed environments »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu May 8 00:05:47 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.