I recently tried to explain the concept of Split-Brain DNS to a colleague, with little success. Unless you are heavily involved in the infrastructure side of IT, the nuances of DNS can be daunting to the uninitiated.

Split-Brain DNS, also known as “Split-Horizon DNS” attempts to solve a problem that arises when any kind of network resource must be accessed from both inside and outside of a network.

For example, let’s say an IP-based video surveillance system has been set up at your workplace. All cameras feed into a device called an NVR, or Network Video Recorder. One feature of devices like this is that you can access the video feed from a computer or a mobile device like a tablet or phone. Just like any network resource like server or printer, to reach the NVR to view the video feed, you must know the address of the NVR. For the purposes of this example, we’ll say that the device address is 192.168.0.50. This is where the problem starts: this address will only work while inside the network. As soon as you leave the premises, no longer connected wired or wirelessly to the internal network, you can no longer reach the NVR by that address, not just because of the firewall, but also because the addresses in the 192.168.0.* network can’t be reached directly from the public internet space.

What many will do, then, is configure multiple profiles: one for internal use, another for outside. But what if you wanted to access the NVR with a single friendly server name, from both inside and outside the network?

Although this involves a little more on the infrastructure side, I’m a strong believer in making things simpler for users and clients. In my experience, a lot of confusion can arise from not being able to access this kind of information from a single profile.

So to understand split brain DNS, I need to delve a little into what Domain Name System (DNS) is and how it works.

DNS is basically a system that correlates an easy to remember name with a not easy to remember IP address. When you type in ” www.google.ca”, a bunch of things happen behind the scenes: your computer asks another computer where www.google.ca is, and eventually in a matter of a few thousandths of a second, the public address of that server is returned. You the user never see what that IP address is unless you know how to look for it, because everything happens invisibly and is handled by your browser and computer. See also my earlier post What is DNS?.

In this example, Google maintains a “DNS zone”, which is basically just a list of servers and server names that are publicly addressable.

Most businesses will have a website, which means that they will have a DNS zone for that domain. To properly configure split brain DNS, all one needs is a domain name, and an internal DNS server.

I will use my own website as an example. My website at www.mcleanit.ca is hosted on a Web server in California. In my DNS zone (mcleanit.ca) there is a server named “WWW”, whose value is the IP address of my Web server. When you look up www.mcleanit.ca, this is where it finds the real IP address and returns it to your computer. But I could have other servers. I might have a billing.mcleanit.ca, or mail.mcleanit.ca.

To continue the earlier example of the video surveillance system, I could make a DNS record called “surveillance” and point it at my (ideally static) public address of my place of business. From there, I would have to open up the relevant ports in the firewall and redirect them to the NVR. This would allow me to access the NVR remotely while outside of the network using surveillance.mcleanit.ca.

Here is where Split-Brain DNS comes in. A private local network can have its own DNS server. Often it is used in larger networks when servers and other network resources need to be addressed by name easily. Maybe an internal tracking system or private intranet website.

On the local DNS server, I could create another DNS zone for mcleanit.ca identical to the first, except for resources that exist on the local network, which I would instead correlate to the internal address. Then I would configure the DHCP server to assign the internal DNS server as the primary DNS provider. So while the real, public DNS record for surveillance.mcleanit.ca would point at my public address, the internal DNS record would override that with the local address for all internal computers (all those configured by DHCP, at least). Attempts to reach surveillance.mcleanit.ca from either inside or outside of the local network will now reach the same destination: the NVR.

The downside is that now both DNS zones will have to be maintained. Changes to the public DNS zone will have to be duplicated on the private one when appropriate.

Implementing a DNS server doesn’t need a big expensive server though. A perfect use-case scenario even for home users is to make a Synology NAS available both inside and outside a network. And even the single-drive units themselves support Synology’s DNS app for an easy-to-use interface.

On any network, as with the Internet, every device needs an address in order to send or receive communication. DHCP is a system that makes this process easier.

DHCP stands for Dynamic Host Configuration Protocol. When configured, it automatically assigns, for a limited time, an address to any (or any approved) network device that asks for one. DHCP commonly operates from the Gateway Router in consumer-grade equipment, but in this post we’ll treat the DHCP server as an abstract service instead of a specific device.

How does DHCP work?

DHCP operates in four stages between the DHCP Server and the DHCP Client. The first stage happens when a client device (when configured to use DHCP) is connected to the network be it a wired interface, or a wireless one.

First, the client broadcasts a DHCPDiscover message. Broadcast, in the context of networks, means that it sends this special message to every device on the network. This special message contains special hardware-identifying information so that the server will know who to respond to – since, of course, the client does not yet have an IP address to reply to.

All available DHCP servers will respond to this message with a DHCPOffer. This message will include an assigned address, the address “lease” time, and some other relevant information. The first DHCPOffer to be received by the client “wins”.

The client then replies to all DHCP servers with a DHCPRequest message, which notifies them which server “won” and formally accepts the offer. This allows the other DHCP servers to return their offers to the pool of available addresses to await the next request.

The final message comes from the winning DHCP server, in one of the following two forms:

• DHCPAck, which acknowledges the address and may sometimes include more network configuration information to finalize the process
• DHCPNAck, (DHCP Not Acknowledged) which indicates that the address offered is no longer available or the client computer has moved

The “lease” time is the period of time before the address needs to be renewed. At the end of the lease, if the computer is no longer connected to the network, like for example if you had a temporary houseguest connect to your network, the address lease simply expires and goes back into the pool of addresses ready to be reassigned. In places with high-client-turnover such as a convention centre, a hotel, or a café, the lease time may be shortened to as little as a few minutes to ensure addresses are recycled efficiently and/or a larger pool of addresses may be configured – the common consumer-grade wireless router will usually come preconfigured with a pool of 254 addresses.

What would life be like without DHCP?

If the DHCP server were to fail, or otherwise be unavailable, computers are designed to fall back to a self-addressing protocol, called APIPA or Automatic Private IP Addressing. APIPA self-configures a computer with an address somewhere between 169.254.0.1 and 169.254.255.254. If those numbers seem odd or arbitrary, they’re just a range of 65534 addresses (a number reached thanks to some binary math voodoo), and have been reserved specifically for the purposes of APIPA.

What this means is if you were to connect two computers to a switch but no DHCP server, they could still technically communicate with one another, but with some limitations. You could never rely on a network printer or server when using APIPA because it would be prone to change (since nothing is there to manage the assignment). DHCP provides additional information like the Internet Gateway address, which tells clients through what device one can access the internet – without it, you would have to configure the gateway manually, and that would assume you know precisely what that address was. When you connect a wireless network, DHCP configures your computer for that network automatically and without any further intervention.

Without DHCP, you would have to manually configure each address on each device on each network you connect to. Even if you’re familiar with the concepts and process, this would be prohibitive in enterprise environments when there are possibly hundreds, or even hundreds of thousands of network devices. DHCP allows us to “plug and play”, or in the case of wireless, connect without any further configuration.

In the beginning, the earliest functional iteration of a large scale network was funded by Defense Advanced Research Projects Agency (DARPA) and it created a link between UCLA and Stanford Research Institute in October 1969. By December of the same year, two more universities were added to the network: the University of Utah, and the University of California. At that time, it was known as the ARPANET.

With these networks growing so quickly, a problem eventually became apparent. There was no central global address book.

Computers communicate much the same way as the global Postal systems work. On an envelope, a sender will include both their originating address and the destination address. A computer will do likewise, but first it must know the destination address. And this isn’t just for email — it’s for everything. Every act you perform on the internet is just a series of messages back and forth. And at that time, unlike our friendly-named streets and cities, computers relied on mathematical formulas and strange binary information to form their addresses (they still do, but now also have DNS). So these universities had to manually keep a special text file on each of their computers that listed the IP address and name of every other computer on the network. If someone wanted to add a new system to the network each computer would need to add it manually. So you can see how this would quickly be found burdensome. Imagine if every time a new website opened, we needed to look up the information and then put it in a massive text file. Manually. Billions of times.

At it’s core, what DNS does is match up the un-friendly binary IP address information with more friendly names. So instead of browsing Google by going to http://173.194.123.34 (which works, incidentally, at the time this post was written), you can simply type in “google.com” and then DNS checks who google.com is, and it goes from there. This is why you hear websites and IT people talking about a “Domain Name” — the friendly-name portion of the Domain Name System or, DNS. By the 80’s DNS was pretty mainstream.

Another use for DNS is that it tells incoming communications which server to use to deliver things like Email, which is called a Mail eXchange (MX) record, because most large enterprises have a vast number of servers, each with a specific purpose, so it is not practical to have one address that does everything.

So who controls who gets what Domain Name? That would be the Internet Corporation for Assigned Names and Numbers (ICANN) who, in turn, delegate authority to other organizations to maintain it. You don’t ever really own a Domain Name, you merely lease it for a period of time. You can keep it for as long as you continue to renew it, or decide to sell it.

The virtue of DNS is the fact that the friendly alias is easy to remember. The simpler the name, the easier it is for people to remember, and theoretically the more visitors one can expect. Because Domain Names are so relatively inexpensive, this has led to Domain Name hoarding, which is why so many new web platforms have odd misspelled names. All the normal dictionary words are already taken, often by people looking to make money on selling them to the highest bidder. The names themselves have a perceived value — the most expensive domain name to date was Insurance.com, purchased for $35.6 Million in 2010.