Download Development of DNS

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.