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 -> 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 zone’s 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 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.

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

34. THE END!