Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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, 05 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.