Private networks and split DNS

This article discusses some of the things that might trip you up when deploying DNS in a private network, alongside publishing your own domain to the world in some public-facing DNS service.
It is closely related to another KB article, which is linked below. That article discusses pros and cons of various choices of domain name for an internal network

A typical use case would be a corporate network, where staff machines (often running Windows) receive private addresses from DHCP and join an Active Directory domain. AD is configured with a DNS domain that is often the one you pay for annually because it's your company's identity in the Internet, so why wouldn't you? Let's say this domain is example.com.

Internally, this domain holds names and addresses of user machines and corporate services, such as printers, storage devices and the AD infrastructure itself. These names and addresses are only relevant to staff and should not be seen in the outside world.

You also host the same domain - example.com - on your (or someone else's) public DNS, so that the world can reach your website, look up where to send mail to your employees and the like. The setup might look something like this:

The problem

The problem with this is that the same domain is being used for different purposes by two independent sets of DNS servers and their clients: the inside ones, serving (say) 10.x.x.x addresses for staff use, and the outside one(s), serving public addresses to allow the rest of the world to find and use your public-facing corporate services.

Why is this a problem?

It isn't, as long as staff never need access to public names in their domain whilst at work, and if the company doesn't provide VPN access to the corporate network for staff working from home.

But what if staff, connected to the work network, also need access to the public website www.example.com and other public names in their own domain? The inside DNS servers are already authoritative for the same domain, so if staff laptops send queries for www.example.com to the internal servers they will receive NXDOMAIN - this name does not exist, when clearly it does; at least for the rest of the world.

Why DNS does this.

It may at first seem like, if a particular DNS server doesn't know an answer to a given question it should simply go and find the answer from somewhere else. This would be true if the DNS servers in question were not authoritative for example.com. But they are, so what is happening?

A bit about family trees.

DNS names exist in a hierarchical namespace, a bit like an ancestral family tree:

This shows the ancestor/descendent relationships between some fictional domains. For example, gamma is a child of beta, which in turn is a child of alpha and so on.

Authority for records existing in a given domain is delegated down from above. The root delegates authority for all names ending alpha. to the people who run the server(s) hosting the green zone. In turn, that delegates responsibility for all names ending beta.alpha. to (perhaps) a different set of people who run the server(s) hosting the blue zone, who then delegate responsibility for names ending gamma.beta.alpha to whoever runs the server(s) hosting the red zone.

Note also that the servers hosting the red zone do not need to know that the servers hosting the blue zone have made a delegation to it. They simply have the zone gamma.beta.alpha. configured as primary. This is how the corporate DNS is working in the network diagram above: it is not aware of having a parent, it is effectively orphaned.

The dilemma

Since both the internal and external DNS server have example.com configured as a primary zone, if either of them receive a query for somename.example.com they will attempt to answer it from the zone data they have loaded. If they can't, they go no further: that's the end of the line.

How to square the circle

A way to look at a combined internal/external DNS setup is to take cues from the DNS hierarchy model itself. Everything starts as generalised as possible, at the root, and becomes more and more specific as you traverse down the namespace tree, getting closer to a domain of interest. In a similar way, the internal DNS setup can be modelled as a set of specific domains, with the Internet and external DNS being the default choice for all other domains.

One approach is to have a single zone internally (say in AD) that is a child of an external zone.
Taking the first picture as a worked example, internal DNS might host the zone internal.example.com instead of example.com, which would, as we have seen above, clash with external DNS. Names for internal devices would then be something like:

• laptop1.internal.example.com
• intra.internal.example.com
• print.internal.example.com
  and so on.

Now, any queries from internal clients for (say) print.internal.example.com or even its parent, internal.example.com will be answered authoritatively by the internal DNS servers and that's that.

Queries for names that are not in the internal zone - e.g. www.example.com - or queries for names that are siblings of the internal zone, for which the internal DNS servers are not authoritative - e.g. somename.external.example.com - are passed from internal DNS to external DNS for resolution, so that they obtain the same answer as anyone in the public Internet would get.

The three big advantages of having an internal domain that is a child of an external domain (which you own) are:

1. DNS resolution just works. Internal DNS doesn't care about othernames.example.com or example.com itself and so obtains answers for them in the same way as any other resolver.
2. A consequence of 1. is that names not in the internal domain give the same answers anywhere so the view is consistent, regardless of the client's starting point.
3. DNSSEC validation for internal clients for names in the internal zone also just works, as long as it's configured properly. The validation path is from the root . to com, to example.com and as long as there is a DS record in example.com for internal.example.com the internal resolving/validating DNS can complete the path with its knowledge of internal.example.com, validate responses and work successfully.

But there's a catch

The configuration outlined above is fine if you have the luxury of starting from scratch, or are in a position to change your existing (example.com) internal zone to (say) internal.example.com. But what if it's already setup and you are not in a position to change it?

In this case things get a little more complicated, but it can still be made to work.
The additional complexity is a result of the priorities assigned to different kinds of DNS responses internally in the DNS server itself.

Essentially, authoritative responses have a higher priority than other kinds of responses because the server has been told, through its configuration, "you own this zone, nobody else does". Whereas a recursive server that does not have such configuration learns information through responses to queries it makes to other servers, so it does not own the data itself and responses it gives have a lower priority, or level of confidence.

What would need to be done is something like this:

The internal DNS service has been split into two components - authoritative only and recursive only.

Authoritative DNS gains several new primary zones such as (in this example) print.example.com, intra.example.com and data1.example.com. Each of these zones contains just the information relevant for its respective service. This may be as little as a single A record or a combination of record types, depending on the service being offered. Importantly, those records are now removed from the parent zone example.com.
Queries for those names still work as they did before, the data has just been shuffled around a bit into child zones, which is necessary for the next part.

The internal recursive DNS has global forwarding enabled to an external recursive DNS, which performs recursion for any name in the Internet, including the external version of the zone example.com.

Also configured in the internal recursive DNS are a set of stub, static stub or secondary zones that match the new, more specific primary zones configured in the internal authoritative DNS and refer to them as the source of data.

Clients (such as laptops) now send their queries to the recursive-only part of the service.

Queries for specific, internal names, for which there is a (static) stub+primary combination, or a secondary zone, will be handled by the recursive server by it making non-recursive queries to the authoritative server and cacheing the results. If secondary zones have been used on the recursive server it will transfer these from the primary then provide authoritative responses itself.

Queries for any other name are sent to the Internet.

The end result is that AD can continue to use example.com, but because only internal names ending with .example.com are resolved locally by the internal resolvers, example.com itself is effectively isolated from the outside world. Clients don't know this and the internal resolvers provide them with a complete view of the world, plus internal exceptions.

This arrangement also works if the company wants to provide VPN services, for employees working from home, or away. The VPN adapter tunnels all traffic, including DNS queries, to the corporate VPN endpoint. The internal DNS resolvers behave just as they do for employees in the office, so from the user's point of view, behaviour is consistent.