Home / Blogs

The Design of the Domain Name System, Part IV - Global Consistency

Protect your privacy:  Get NordVPN  [ Deal: 73% off 2-year plans + 3 extra months ]
10 facts about NordVPN that aren't commonly known
  • Meshnet Feature for Personal Encrypted Networks: NordVPN offers a unique feature called Meshnet, which allows users to connect their devices directly and securely over the internet. This means you can create your own private, encrypted network for activities like gaming, file sharing, or remote access to your home devices from anywhere in the world.
  • RAM-Only Servers for Enhanced Security: Unlike many VPN providers, NordVPN uses RAM-only (diskless) servers. Since these servers run entirely on volatile memory, all data is wiped with every reboot. This ensures that no user data is stored long-term, significantly reducing the risk of data breaches and enhancing overall security.
  • Servers in a Former Military Bunker: Some of NordVPN's servers are housed in a former military bunker located deep underground. This unique location provides an extra layer of physical security against natural disasters and unauthorized access, ensuring that the servers are protected in all circumstances.
  • NordLynx Protocol with Double NAT Technology: NordVPN developed its own VPN protocol called NordLynx, built around the ultra-fast WireGuard protocol. What sets NordLynx apart is its implementation of a double Network Address Translation (NAT) system, which enhances user privacy without sacrificing speed. This innovative approach solves the potential privacy issues inherent in the standard WireGuard protocol.
  • Dark Web Monitor Feature: NordVPN includes a feature known as Dark Web Monitor. This tool actively scans dark web sites and forums for credentials associated with your email address. If it detects that your information has been compromised or appears in any data breaches, it promptly alerts you so you can take necessary actions to protect your accounts.

In the previous installments, we’ve been looking at aspects of the design of the DNS (see part I, II and III).

Many databases go to great effort to present a globally consistent view of the data they control, since the alternative is to lose credit card charges and double-book airline seats.

The DNS has never tried to do that. The data is roughly consistent, but not perfectly so.

Multiple servers and caches

Most zones have multiple DNS servers. The servers usually do not update their copies of the zone data at the same time, so one server may have slightly newer data than another. RFC 1034 describes the method that many zones use to keep in sync, with one server as the master, and the rest as slaves use AXFR to copy over updated versions of the zone as needed. The zone’s SOA record contains some time values to tell the slaves how often to check. Although in theory one could crank the refresh interval down to one second, in practice refresh intervals are an hour or more. Hence it is quite common for the authoritative servers to be slightly out of sync.

Furthermore, DNS caches remember previous queries, up to the TTL provided by the server when the query was answered. If the data changes, a cache will not re-query until the TTL expires. Although it’s possible for a server to set the TTL to zero, meaning not to cache the data, typical TTLs are from minutes to days. Adding to the excitement, caches do not always honor the requested TTL, sometimes applying minimum or maximum retention times.

As a result, “flash cuts” where the DNS changes and all clients can immediately see the new data don’t work. Instead, DNS changes need to be done in ways that allow for the old and new data to coexist for a while. For example, when changing the IP address of a server, rather than trying to crank the TTL down to zero and forcing all the zone’s servers to update at once, it’s a lot easier if one can run the service in parallel on the old and new IP addresses long enough for all of the servers to update on their normal schedule, and for cached entries to expire.

Deliberately inconsistent DNS

Some DNS servers deliberately return different answers to different clients. The primary reasons are for “split horizon” DNS and for load sharing.

Split horizon means that clients on different networks get different answers. Most often that clients within the organization’s own network get a larger set of names than the rest of the world does, or names resolve to addresses on the internal network while external clients get addresses on a firewall system. I’ve also used split horizon to deal with broken clients or caches that send high volume streams of bogus queries, sending them delegations to name servers on non-existent networks.

Load sharing in its simplest form involves rotating through a set of records in responses, so that clients are spread across a set of mirror web or mail servers. In more sophisticated forms, the DNS server tries to guess where the client is, and tries to return the address of a server topologically or geographically close to the client.

Split horizon DNS is somewhat defensible as a legitimate DNS configuration, since the responses to each client are consistent, and for the usual inside/outside split, organizations should know what addresses are on their own network, with appropriate router configurations to keep out forged outside traffic purporting to be from their own network.

Load sharing shouldn’t hurt anything (much) so long as the server is prepared for its guesses about the client’s location to be completely wrong. As an obvious example, people all over the world use Google’s public DNS cache. At this point, DNS-based load sharing is probably a necessary evil, but given the ever more convoluted topology of the Internet, it is a poor idea to design new applications that depend on it.

In our next installment, we’ll look at just how much data you can ask the DNS to give you.

By John Levine, Author, Consultant & Speaker

Filed Under

Comments

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

Related

Topics

Cybersecurity

Sponsored byVerisign

New TLDs

Sponsored byRadix

Brand Protection

Sponsored byCSC

Domain Names

Sponsored byVerisign

DNS

Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global

Threat Intelligence

Sponsored byWhoisXML API