1 / 13

DNS Tutorial

DNS Tutorial. Randy H. Katz CS 294-4: NetRADS Network-oriented Reliable Adaptive Distributed Systems. Domain Name System Motivation. Directory services are essential in any network system, provide a name-to-address mapping service Name of resource: what we seek Address: where it is

vashon
Download Presentation

DNS Tutorial

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DNS Tutorial Randy H. Katz CS 294-4: NetRADS Network-oriented Reliable Adaptive Distributed Systems

  2. Domain Name SystemMotivation • Directory services are essential in any network system, provide a name-to-address mapping service • Name of resource: what we seek • Address: where it is • Route: how to get there • Delayed binding: look-up address when you need it • History: • Hosts.txt: Explicit file containing the mappings suitable for the early days of the ArpaNet (up to several hundred nodes) • Names: unstructured strings up to 30 characters • Maintained by the Network Information Center (NIC), but difficult to keep up-to-date as the Internet grew • Xerox Clearinghouse predates DNS

  3. Domain Name SystemHistory • Early 1980s: RFC 1034, 1123: • Consistent and variable depth hierarchy for names • Distributed maintenance, controlled by the database itself • Connectionless service using UDP (though TCP also supported) • Cached entries, cache aging, cache removal • Spartan features for database update and data structuring • Organized as an overlay “database” on top of the Internet • Post 1995 Commercialization • IANA: Internet Assigned Number Authority • http://www.iana.org/domain-names.htm • Multiple Name Top Level Name Registries: e.g., VeriSign authoritative directory provider for .com, .cc, .net, .tv (10 billion interactions per day!) • 65 million registered domains in late 2004

  4. Domain Name SystemStructure Single point of failure! Actually 13 roots (A – M) but one root file! London, Japan, Sweden, 10 US 7 HW platforms, 8 OSs, 5 vendors • 13 Roots • 48 hour TTL • DOS attack October 2002: Pinging roots • Top-level domains • CC: US, CA, CH, … • G: COM, EDU, NET, MIL, GOV, ORG, … • Domain Name Tree • Name is ordered list, from node to root • Sahara.cs.Berkeley.edu • DNS Abstract Database • Resource Records (RRs) associated with names • Type: Network Address (A), Name Server (NS), MX (Mail Exchange), … • Class: Internet (IN) • TTL: data validity, 32-bits, seconds • Delegated NS authority • NS RR + “Glue” A RR to defer name resolution for a subzone to another NS • Glue chasing resolution process if no glue record is found Root . Top-level domain Edu g, ccTLD Zone Berkeley Subzone CS Sahara.cs.Berkeley.edu <A, IN, IP address>

  5. Domain Name SystemQuery & Response • Query • Query (Name, Type, Class) • Specific, Partial, Any Match • Response • Set of resource records (0 or more) • Order may be important • Errors • Name does not exist • Temporary error: “try again later” caused by network disconnection or other temporary condition • Essential to rate limit the “try again”

  6. Domain Name SystemClient-Server • Resolvers (clients) contact Name Servers (servers) to translate names • Local Configuration Information • Identify location of other name servers • No requirement that local information is correct • Full Resolvers • Root name servers, local name servers, ability to recover from errors • Manage caches • Small TTLs if volatile, large TTLs if stable • Failures cached as well • Stub Resolvers • Sufficient functionality only to talk to nearby recursive NS

  7. Domain Name SystemName Servers • Name Server: Internet host capable of processing DNS requests, e.g., BIND • Primary vs. Secondary NSs • Zone transfer: complete copy of primary’s RR DB to secondary • Query Response • Name server can return referral to better NS • Recursive: follow down naming tree, caching entries on the way • Authoritative Answer: came from NS’s actual DB, not from its cache

  8. Domain Name SystemRFC 1123 • DNS Health Considerations • Resolver must implement rexmit controls to avoid b/w waste; impose finite bounds on resources consumed in response to any request • After a query has been rexmit several times w/o response, give up and return error to application • DNS name servers and resolvers should cache temp failures with a timeout O(minutes)—prevents apps from immediately retrying, thus generating excessive DNS traffic • Cache negative responses indicating that specified name does not exist • UDP-based retry attempts constrained by exponential back-off algorithms with upper/lower bounds • Source Quench for resolver/server issuing query: take steps to reduce querying rate, e.g., by sending next query to alternative server

  9. Domain Name SystemHealth Survey • Domain Health Survey (Feb 2003): http://www.menandmice.com/6000/61_recent_survey.html • 68.4% of .COM Zones Misconfigured • 27.4% of .com zones have all name servers on the same subnet; 6.7% of .com zones have only one authoritative name server • DNS administrators most commonly make delegation configuration errors in their zone setup, resulting in lame delegations: 18.4% had lame delegations • 16.4% had non-responding authoritative name servers resulting in web site lookup failures • 43.3% of zones block zone transfer from all name servers; has no effect on the security of the zone data itself, provides "security by obscurity".

  10. Domain Name SystemDNS Spoofing • “Malicious cache poisoning” • Send recursive query to target for zone owned by attacker • Target references attacker’s server, which responds with an authoritative record for a third party’s domain name • Target caches a bogus record • Recent investigations indicate that 25-30% of DNS servers on the Internet are spoofable • Solution: TSIGs—transaction signatures

  11. jp net uk ca bar.foo.com. NS ns1.bar.foo.com. bar.foo.com. NS ns3.bar.foo.com. bar.foo.com. NS ns2.bar.foo.com. bar.foo.com. MX mail.bar.foo.com. www.bar.foo.com. A 10.10.10.10 Zone: Occupies a continues subspace Served by the same nameservers bar resource records name servers DNS Operation com foo buz bar bar1 bar2 bar3

  12. answer: www.bar.foo.com A 10.10.10.10 caching server referral: com NS RRs com A RRs root zone referral: foo NS RRs foo A RRs referral: bar NS RRs bar A RRs com zone foo zone bar zone asking for www.bar.foo.com client

  13. foo.com. NS ns1.foo.com. foo.com. NS ns2.foo.com. foo.com. NS ns3.foo.com. ns1.foo.com. A 1.1.1.1 ns2.foo.com. A 2.2.2.2 ns3.foo.com. A 3.3.3.3 foo.com. NS ns1.foo.com. foo.com. NS ns2.foo.com. foo.com. NS ns3.foo.com. ns1.foo.com. A 1.1.1.1 ns2.foo.com. A 2.2.2.2 ns3.foo.com. A 3.3.3.3 Infrastructure RRs • NS Resource Record: • Provides the names of a zone’s authoritative servers • Stored both at the parent and at the child zone com • A Resource Record • Associated with a NS resource record • Stored at the parent zone (glue A record) foo.com

More Related