Development of the Domain Name System

Kevin Dunlap, Paul Mockapetris

Mehwish AhtashamCOEN 317

May 18, 2005

BACKGROUND• Recall we discussed the Domain Name

Service (DC2)• A distributed name database• Rapidly resolves domain names to IP

addresses• Basic DNS algorithm for name resolution:

domain name -> IP number• Look for name in the local cache• Try a superior DNS server which responds

with: Another recommended DNS Server (Iterative

Name Resolution) The IP address (Recursive Name Resolution)

ROADMAP• Introduction

• DNS Design

• Implementation Status

• Surprises

• Successes

• Shortcomings

• Conclusion

INTRODUCTION• DNS initially designed in 1983.

• In 1982, people realized that the HOST.TXT system for publishing the mapping between host names and addresses was headed for problems.

What is HOST.TXT?• A simple text file which is centrally

maintained on a host at the SRI Network Information Center (SRI-NIC) and distributed to all hosts in the Internet via file transfers.

• Problems: File size becoming too large Costs of its distribution too high Moving towards distributed management of

the Internet Much larger than linear increase in the number

of hosts, organizations, and transfers of file

INTRODUCTION (cont.)• Organizations were being forced into

management of local network addresses, gateways, etc., Need to partition the database and allow

local control of local name and address spaces.

A distributed naming system was needed.

• Existing distributed naming systems were not suitable for the DARPA Internet a new design was begun

DNS DESIGN• Base Requirements for the DNS:

Must provide at least all of the same information as HOSTS.TXT

Allow the DB to be maintained in a distributed manner

Have no obvious size limits for names, data, etc.

Interoperate across the DARPA Internet and as many other environments as possible

Provide Tolerable performance

DNS DESIGN• Constraints:

Cost of implementing the system could only be justified if it provided extensible services.

Avoid any constraints on the system due to outside influencesAvoid trying to force a single OS,

architecture, or organizational style onto users.

DNS DESIGN• Store data other than name-to-address

mappings.• Hierarchical name space needed

(distribution and size requirements)• Allow DB information to be buffered

between the client and source of the data (interoperability and performance requirements)

• Initial design was a balance between very lean and completely general DB Some functions omitted so the system could

be leanNo dynamic update of DB, voting, and backupSystem would be too complex if these features were

added.

DNS DESIGN• Architecture

Name ServersRepositories of informationAnswer queries using whatever information

they have

ResolversInterface to client programsFind a name server that has the information

that the client needs

DNS DESIGN• The Name Space

Internal name space is a variable-depth tree where each node in the tree has an associated label.

Domain name of a node is the concatenation of all labels on the path from the node to the root of the tree.

Labels are variable length strings of octets. Each octet can be any 8-bit value (zero length is for the root).

No standard printing rule for the internal name format. Have character strings separated by dots, but applications are free to do otherwise.

DNS DESIGN• The Name Space

Structure of the tree is decoupled from any implicit semantics.

Recommended name space for hosts, users, and applications is one that mirrors the structure of the organization controlling the local domain.

Made the top levels of tree correspond to country codes or broad organization types (ex: EDU for education, UK for Great Britain).

DNS DESIGN• Data Attached to Names

DNS puts no constraint on the data that applications can attach to a name, but they needed to specify some structure.

Data for each name is organized as a set of resource records (RRs).Each RR carries a well-known type and

class field, followed by application data.Types represent abstract resources or

functions. (Ex: host addresses & mailboxes)Class filed is meant to divide the database

orthogonally from type and specifies the protocol family or instance.

DNS DESIGN• Data Distribution

Two mechanisms for transferring data from its ultimate source to ultimate destinationZonesCaching

Both mechanisms are invisible to the user who should see a single database

DNS DESIGN• Data Distribution

ZonesSections of the system-wide DB which are

controlled by a specific organizationOrganization controlling a zone is

responsible for maintenance of the zone’s data and providing redundant servers for the zone.

Zone transfers are typically initiated by changes to the data in the zone.

DNS DESIGN• Data Distribution

CachingData acquired in response to a client’s

request can be locally stored for future requests.

A TTL field is attached to each RR.A low TTL is desirable because it minimizes

inconsistency.A high TTL minimizes traffic and allows

caching to mask periods of server unavailability.

Recommended TTL value for host names is 2 days.

IMPELMENTATION STATUS (1988)• DNS was in use throughout the DARPA

Internet• HOSTS.TXT was still used by older hosts,

but DNS became the recommended mechanism 5,500 host names were in HOSTS.TXT Over 20,000 host names available via DNS

• Domain name space was partitioned into roughly 30 top level domains

• Two good examples of DNS use: Root servers Berkley subdomain

IMPELMENTATION STATUS (1988)• Root Servers

Redundant name servers that support the top levels of the domain name space.

Access to root and other top level zones is important. Seven redundant name servers scattered across the backbone networks of the Internet.

Typical traffic rate at each root server is a query/sec.

Estimated that root server traffic could be reduced by 50% if resolvers use less aggressive retransmission and better caching.

IMPELMENTATION STATUS (1988)• Berkeley

Due to growth in the campus network, they developed BIND (Berkeley Internet Name Domain) server.

With BIND, Berkeley became the first organization on the DARPA Internet to bring up machines with all their network applications solely dependent on DNS for doing network host and address resolution.

The entire campus had to adopt domain-style mail addresses.

SURPRISES• When DNS came in use, several

issues came as surprises to the developers: Refinement of semantics Performance Negative Caching

SURPRISES• Refinement of semantics

made an assumption that the form and content of the information in DNS was well known.

• Performance Performance of the underlying network was

much worse than the original design expected. Gateway mechanisms could not keep track of

connectivity due to growth in the number of networks.

Growth in load plus the addition of many lower speed links led to longer delays.

Difficult to do performance measurements because measurements were swamped by unrelated effects due to gateway changes, new DNS software releases, etc.

SURPRISES• Negative Caching

DNS provides two negative responses to queriesThe name in question does not exist: name might be

misspelledThe name in question exists but the requested data

does not: query asked for the host type of a mailbox or the mailing list members of a host

These responses were expected to be rare. But initially there was a very high percentage

(20-60%) of these responsesMany of these queries were generated by programs

using old-style host names. Expected negative responses to go down, but

they stayed in the 10 – 50% range. Decided they needed caching for negative

results as well.Feature added later on

SUCCESSES• Variable depth hierarchy

• Organizational structuring of names

• Datagram access

• Additional section processing

• Caching

• Mail address cooperation

SUCCESSES• Variable depth hierarchy

Used a great deal and was a success for several reasons:Organizations participating in the Internet

needed to organize within themselves.Organizations were of different size and

needed different number of organizational levels.

Variable depth hierarchy makes it possible to encapsulate any fixed level or variable level system.

SUCCESSES• Organizational structuring of names

Names are independent of network, topology, etc. was popular.

• Datagram access Datagrams used to access name

servers was successful because of the bad performance of the DARPA Internet.

Drawback: need to develop and refine retransmission strategies.

SUCCESSES• Additional section processing

When a name server answers a query, it is free to add any additional information it sees fit as long as the data fits in a single datagram.

Can answer a request before it was asked.

Cuts query traffic in half.

SUCCESSES• Caching

Caching works well for DNS. Problems:

TTL valuesSecurity and reliability problems caused by

indiscriminate caching.

• Mail address cooperation Different Internet communities agreed

to use organizationally structured domain names for mail addressing and routing.

SHORTCOMINGS• Difficult to have type and class growth

Initial design was criticized because the class data fields were 8 bits, but not many classes or types are being added.

Difficult to make new definitions.Need to clearly design and publish their semantics.Create applications to use them.Reach consensus to use the new system across the

Internet.New types face a series of technical and political

hurdles.

Guidelines needed to aid the design of new types.

SHORTCOMINGS• Not easy to upgrade applications

Converting network applications to use the DNS is not a simple task.

Applications need to deal with the fact that a distributed naming system has periods that it can not access particular information

Access to the naming system needs to be integrated into the operating system to a much greater degree than providing system call to the resolver.

SHORTCOMINGS• Distribution of control vs. distribution of

expertise or responsibility Distributing authority for a DB does not

distribute a corresponding amount of expertise.

Organizations should have been required to have redundant servers with real data before they were given a domain.

Documentation should always be written with the assumption that only the examples are read.

Questions about software versions and parameters should be accessible via the protocol.

CONCLUSION

Was the DNS a good idea?

Modifications to the HOSTS.TXT scheme could have postponed the need for a new system, but the need to distribute functionality was crucial.

CONCLUSION• Things they wished they had known

earlier: Caching works well, but need to include

caching for negative responses as well. It is more difficult to remove functions

from systems than it is to get a new function added.

Optimizations are not considered if the system performs at the expected level. Distributed software should include a version number and table of parameters which can be cross-examined .

Allowing variations in the provided service causes problems.

CONCLUSION• What’s Happening with DNS now?

Version 9.3.0 was released on 23-Sep-2004 with IPv4/IPv6 dual stack support.

Version 9.3.1 of BIND was released on 12-Mar-2005.

A total of 134 DNS related RFC (Requests for Comments) documents.

THE END!