Post on 15-Jan-2016
transcript
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.