Development of DNS(P.V.Mockapetris, K.J.Dunlap)

Anirban Kundu

Contents

• What is DNS

• How and why did DNS come about

• Implementation of DNS

• Pitfalls and Successes

• Things Learned

History of DNS

• What is DNS– Name resolution from human readable (FQDN) to

computer mapping (IP)

• Hosts.txt file– File too large– Cost of distributing– Ever changing

• NCP based ARPANET -> TCP/IP based network– Large timesharing systems -> Large system plus

multiple workstations– Control based on domains/organizations rather than

single location.

History of DNS (contd)

• RFC 882 & RFC 883• DNS principles

– Hierarchical name space• Name space with typed data at the nodes• Control of database and nodes located within

organizations

– Flexible addition of new data types

• Not all DNS principles initially implemented

DNS design (proposed)• Atleast same functionality as hosts.txt file

• Database of mappings should be stored in a distributed fashion.

• No distinct size limitations for names or any other data associated with names.

• Interoperate with DARPA Internet and other non TCP/IP projects

• Performance matrices defined on how well DNS should perform.

DNS Design (contd)• Independence of

– Network topology– Handling multiple different types of name spaces– OS independent

• Hierarchical design– Distribution & size requirements

• Main Goal: Lean but Distributed– Lean – more implementation & quick availability

• Lead to removal of dynamic update of db with related atomicity, voting and backup considerations

– General design = more applications, increase functionality and increase the number of environments under which DNS is deployed.

DNS Architecture

• Name servers– Repositories of information– Answer queries

• Resolvers– Interface with client programs– Algorithms to contact name servers

• Resolvers can be inside name servers

DNS Architecture (contd)

• Name Space– Variable depth tree– Each node has a case-insensitive label

• Labels are variable length 8-bit octets. Max = 63 octets

• Name = 256 octets (character strings separated by dots)

• Tree structure allows overloading of names across different sub-trees.

– Empty label = root• Alpha.beta.com(.*)

DNS Architecture (contd)

• No defined naming system (encourage existing formats and different formatted names) (need not be IP addresses)

• Recommended name space is to follow organization’s structure

• Top level domains are for country or broad organizational codes (uk, com, edu, etc)

• DNS cannot fix the data format completely (no constrain on data of name)

DNS Architecture (contd)Have to return relevant, expected information -RR

(Resource record)• Type

– Abstract resources or functions (hostnames, mailboxes, MX, NS, etc.)

– Multiple values of same type = Multiple RRs» Simpler dynamic update» Limited size datagram (UDP) – dont have to deal with

breaking up maximum sized packet

• Class field– Divide database orthogonally from type. (Internet, DARPA,

CHAOS, ISO, etc)

• Application data

– Sample RR types• [TTL] [class] type RDATA • [class] [TTL] type RDATA • class ttl MX preference exchange-dname (look up MX

record)

DNS (data storage &distribution)• Hierarchical distributed data storage and

retrieval (zones & caching) – invisible to end-user

– Zones

• Controlled by a specific organization

• Contiguous description of tree space and “pointer” information for other relevant contiguous zones.

• Could be an entire sub-tree or just a node.

• Distribute several copies to several servers to handle requests by clients.

• Creation

– Begins with request to parent zone to delegate a sub-node

– Grow as a tree within the node

– Parent records in RRs that zone records for particular node have a zone division and point to new zone holder.

– Parent should not be involved henceforth.

DNS (data distribution) (contd)– Zones (contd)

• Organization maintains zones and distributes zones appropriately

• Master file distributed to all users manually or DNS based distribution algorithm – zone refresh.

– Serial number based– TCP based

• Creation of redundant servers to handle requests

• Single name server can handle multiple zones (master/slave)

– ISPs (buddy storage of data)

– Geographical distribution of data

• Data retrieved from zone data = authoritative.

DNS (data distribution) (contd)

– Caching• Store data (RRs) locally till it expires thru TTL.

• 0 = no caching.

• Administrator controlled

DNS (finding the data)• “Downward Search”

– Resolvers can figure out domains underneath them

– Point to some root server – or server midway to the root.

• Queries to root server (in the beginning) – not driven by growth – but by changing algorithms and (incorrect) usage of DNS.

• Estimated 50% of requests could have been decreased with better request patterns, requests and caching.

DNS (finding the data) contd.

DNS (first implementations)

• Berkeley Internet Name Domain Server(BIND)– Painful transition from old DARPA based

network to DNS based system• Old habits die hard (look up mailing lists)

– Hosts growth was significant• 1986->1988 (267 hosts -> 1991, 14->86 subnets, 0-

5 subdomains)

DNS (Surprises)

• Performance issues– Growth– Bad usage– Large numbers of low speed links– Poor or no implementation of caching– Hard to measure perfomance

• Too many changing parameters (network changes, new DNS software)

DNS (hmm …)

• Many servers perform better with fewer page faults as load increases = not ideal behavior

• Larger more complicated Database needed to support large data set and more clients. (initially take the heat)

• Negative caching (store bad responses)– Non-existent name– Name exists but remaining request doesn’t. (mailing list –

check if mail server exists – goes all the way to the root server (not desirable)) 25% of requests were of this type

DNS (hmm …)• Infinite TTL (very long TTL)• Variable depth hierarchy = GOOD!!!

– Huge number of workstations lead to organizations better organizing themselves – instead of single flat file

– Organizations are of different sizes – depth should be of different levels

• Poor network – so UDP (datagrams) were a better choice – better than TCP because the OS doesn’t have to manage connections – but have to setup some sort of retransmission policy.

• Small defined datasize better because OS resources don’t have to allocate large buffer chunks.

DNS (hmm …)• Anticipate next request – and fit as much as

possible within the same request. Pass name along with address on request rather than just name

• Caching– Works extremely well– Incorrect setups/bad TTLs defined might cause

problem– Possible security violation

• Not enough type specifiers• Built in compile time constants for type – rather

than user dynamically defined ones.• People have different needs and assumptions and

thus coming to a consensus is a problem in itself.

DNS (hmm …)

• People don’t like changes– Old naming format – allowed for mail user lookup –

DNS doesn’t = application change and reluctance– Hosts.txt file -> DNS == transient failures (since its

distributed)• Needs to be handled by the application (SMTP)

• Too many domains – not properly administered – backed up = too many failed lookups

• No diminished headaches in managing DNS vs. Hosts.txt – just more distributed

DNS (mistakes learnt on a usability engineering POV)

• People who use your product are going to abuse it (play outside the boundaries) – bad inputs

– Laziness

– If it works – fail to optimize - System designers should anticipate that maintainers and administrators will only do the least possible to show the system working – rather than go all the way – so the system should be self-controlling and self-adhering.

• DNS network optimizations on the client side not done (especially in UDP packet management) -> developers lost interest.

DNS (mistakes learnt on a usability engineering POV)

• Lack of anticipation of growth

• Much easier to change the implementation of a concept than to change the interface or workings of a property.

• Documentation should have lots of examples and assumed to be the only ones that are going to be read.

• External software parameters like revision numbers should be easily gathered and accessible from the protocol.

• Lot harder to remove functionality than to add functionality.

• Do not allow variations provided service – only in service implementations.