Development of the Domain Name System

1
Development of the Domain Name System

• Kevin Dunlap, Paul Mockapetris

Mehwish Ahtasham COEN 317 May 18, 2005
2
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 -gt 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)

3
ROADMAP

• Introduction
• DNS Design
• Implementation Status
• Surprises
• Successes
• Shortcomings
• Conclusion

4
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.

5
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

6
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

7
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

8
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 influences
• Avoid trying to force a single OS, architecture,
  or organizational style onto users.

9
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
  lean
• No dynamic update of DB, voting, and backup
• System would be too complex if these features
  were added.

10
DNS DESIGN

• Architecture
• Name Servers
• Repositories of information
• Answer queries using whatever information they
  have
• Resolvers
• Interface to client programs
• Find a name server that has the information that
  the client needs

11
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.

12
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).

13
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.

14
DNS DESIGN

• Data Distribution
• Two mechanisms for transferring data from its
  ultimate source to ultimate destination
• Zones
• Caching
• Both mechanisms are invisible to the user who
  should see a single database

15
DNS DESIGN

• Data Distribution
• Zones
• Sections of the system-wide DB which are
  controlled by a specific organization
• Organization controlling a zone is responsible
  for maintenance of the zones data and providing
  redundant servers for the zone.
• Zone transfers are typically initiated by changes
  to the data in the zone.

16
DNS DESIGN

• Data Distribution
• Caching
• Data acquired in response to a clients 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.

17
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

18
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.

19
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.

20
SURPRISES

• When DNS came in use, several issues came as
  surprises to the developers
• Refinement of semantics
• Performance
• Negative Caching

21
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.

22
SURPRISES

• Negative Caching
• DNS provides two negative responses to queries
• The name in question does not exist name might
  be misspelled
• The 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 responses
• Many 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

23
SUCCESSES

• Variable depth hierarchy
• Organizational structuring of names
• Datagram access
• Additional section processing
• Caching
• Mail address cooperation

24
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.

25
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.

26
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.

27
SUCCESSES

• Caching
• Caching works well for DNS.
• Problems
• TTL values
• Security 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.

28
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.

29
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.

30
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.

31
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.

32
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.

33
CONCLUSION

• Whats 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.

34
THE END!