Development of the Domain Name System Joey Brown David Margolies
Introduction DNS provides name service for the Internet 1982 - HOSTS.TXT Centrally maintained Too large Too costly to distribute Organizations manage their own network Allow local control of local name and address spaces Hierarchical name space Typed data at nodes
Example hosts file on Fedora Linux
DNS Design GOALS 1. HOST.TXT 2. Distributed Database 3. No Obvious Size Limits 4. Operate in Many Environments 5. Performance CONSTRAINTS 1. Independent of network topology 2. Independent of OS, architechture, organizational style Several functions one might expect in a stateof-the-art database were omitted.
Design: Architecture Name Servers Repositories of information Answer queries using whatever information they possess Resolvers Interface to client programs Embody the algorithms necessary to find a name server with desired information
Design: Name Space Variable-depth tree wlu.edu cs.wlu.edu There is a limit to length Similar to file system hierarchy Network Solutions is in charge of maintaining the COM domain Maintains whois database
Design: Data Attached to Names Data for each name is organized as a set of record resources Type field and class field Ex. Host Address At time of paper, 15 That number has more than doubled Class How DNS is being used Ex. IN class = internet
Design: Database Distribution Zones Sections of system-wide database controlled by a specific organization Zones begin by persuading a parent organization to delegate a sub-zone Zones can grow without involvement of parent Example: WLU.EDU Caching Resolvers and Name Servers cache responses for later use Store for a specific length of time: time-tolive High TTL Low TTL
Current Implementation Status As of paper writing (1988) 20,000 host names approximately 30 top level domains Today 205.3 million host names 280 delegated top level domains
Root Servers Resolver searches "downward" "Hints" point to root node and top level of local domain Can access all domains with access to a root server Resolvers cache information so access to root servers decreases 1 query/second at root servers changes based on implementation algorithms timeout tuning Authors estimate half of root server traffic could be eliminated with less aggressive retransmission and better caching
Berkeley Provided UNIX support for DNS Berkeley Internet Name Domain (BIND) server written by 4 grad students first to have all machines solely dependent on DNS forced adoption of domain-style mail addresses 1986-1987 - added 735 hosts in 250 working days
Surprises The network design made DNS perform slow The new mechanisms performed as good or better than the old mechanisms. Why would DNS, a complicated database perform better than the simple HOSTS.TXT lookup table? Negative Caching Classical caching stored only successful name resolutions Why might negative caching be desirable? "This feature will probably become standard in the future" It is now standard
Successes Variable depth hierarchy Allows for organization within organizations Large and small organizations have different needs Standardized name syntax for non DNS systems Organization structuring of names Names independent of network or location Political decisions needed for changes in organization Datagram access Requests sent over UDP limited to 512 bytes Responses sent over UDP unless >512 bytes (otherwise TCP) Originally performed better than a pure TCP model Retransmission strategies had to be developed
Successes (continued) Additional section processing Name servers can attach more response data as long as it fits Allows anticipation of next logical request Ex: include the address when asked for the name of a host (cuts query traffic in half) Caching Essential to success given the unexpectedly bad performance Problem: administrators think TTL is a priority Pick shorter than necessary TTL Mail address cooperation Agreement on structure of e-mail addresses
Shortcomings Network applications were using the HOSTS.TXT file, so they had to be reconfigured to use DNS It would be better than HOSTS.TXT, but not until enough people started using it... Almost all software at the time considered class and types as compile-time constraints They had to recompile to deal with new types Designers of network applications seemed to read only examples TTL values which mapped to an hour were always copied, even though text stated that it should be a few days
Conclusions Could modifications to HOSTS.TXT have been postponed? Caching should include negative responses as well as positive ones Adding functionality is easier than removing it Implementors lose interest once their system works as expected as long as they are using others' resources Variation in implementation is good, but variation in service is not
Future DNS exists to encapsulate other name spaces. Solutions to growing complexity of naming will be needed. How will the upgrade from IPv4 to IPv6 probably be handled by DNS?