With so much going on in today’s digital world, it’s hard to know where to begin with DNS.  So, let’s take a step back and look at the history of DNS.

First Generation DNS

Here’s a little bit of history. The term “Domain Name System” refers to two things.  First, the term refers to the protocol used today to convert, for the most part, human-readable labels (such as computer hostnames) into numeric addresses.  The second is the world-wide activity to build a service using that protocol to enable communications.

In this first post, we will set the stage by looking at the definition of the protocol and cover its early history.

After some early attempts to make it easier to reach hosts across the Internet, a collection of engineers created a description of the Domain Name System. This work was done within the Internet Engineering Task Force (IETF) and with documents published in a Request For Comment (RFC) series .

Two documents within that RFC series — RFC 1034 and RFC 1035 — are considered by most to be the start of the DNS definition. These documents describe a fully functional protocol and include some early data types to be carried.  At the time, Internet mail was also being defined and there were attempts to let mail make great use of DNS.  Although other attempts followed to add application-specific features in DNS, none stuck because, in retrospect, it wasn’t a very good idea to hook other applications too deeply into DNS.

About 10 years passed before the first major update to the DNS protocol was published.  What was the update?  An addition of a more dynamic way to keep servers up to date by use of mechanisms called NOTIFY and Incremental Zone Transfer (IXFR).

In the first generation of DNS, the best way to provide for “continuity” was to have multiple servers answering multiple queries.  One server was called a master, while the the rest were slave servers.  Each of the slaves had instructions to check with the master periodically to determine whether the data had changed.

The Second Generation

NOTIFY was the first “game changer.”  Instead of a master having to wait until a slave came to check, the master could send a NOTIFY message to the slaves, prompting them to acquire the new data.  IXFR, meanwhile, made a marked change in the way data was communicated.  If just one record out of hundreds had changed, the original specification would send hundreds of messages.  IXFR changed the sytem, enabling only the changes to be sent.

The Third Generation

The next turning point in the evolution of the DNS came when dynamic updates were defined in RFC 2136.  In the first generation, to change even just one record an administrator would have to go to the master server, edit a file, and then get the master to reload the file (before waiting for slaves to update).

However, dynamic updates enabled an administrator to edit the live zone, even from across the network.  Administrators no longer needed to log into the master.  This might not sound like a huge win, but the greater impact was this: dynamic updates reused the original message format for another purpose.  Moreover, succeeding efforts to update the DNS were not afraid to redefine fields in the protocol, such as the Extension Mechanisms for DDS (EDNS) in RFC 2671, which defined extensions that added further modernization.

After the addition of NOTIFY, IXFR, and dynamic updates, the evolution of the DNS protocol began to unravel. Code was added here and there, but no one gave the protocol a good review for “structural integrity.”  This period came to be documented in RFC 2181 and RFC 2308.  RFC 2181 was simply titled “Clarifications to the DNS Specification” and dealt with some overlooked data issues.  RFC 2308 covered answers that said “no” and helped document terminology still used today.

After the “reforms” of RFC 2308 and RFC 2181 were finalized, DNS security became the next top focus of DNS modifications, and would remain so for many years to come.

Stay tuned for the next installment, when we’ll cover the vulnerabilities associated with DNS.