dns tutorial

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

Upload: vashon

Post on 05-Jan-2016

29 views

Category:

Documents


3 download

DESCRIPTION

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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: DNS Tutorial

1

DNS Tutorial

Randy H. Katz

CS 294-4: NetRADS

Network-oriented Reliable Adaptive Distributed Systems

Page 2: DNS Tutorial

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

Page 3: DNS Tutorial

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

Page 4: DNS Tutorial

4

Domain Name SystemStructure

• 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

.

Edu

Berkeley

CS

<A, IN, IP address>

Sahara.cs.Berkeley.edu

Top-leveldomain

Zone

Root

Subzone

Single point of failure!Actually 13 roots (A – M) but one root file!London, Japan, Sweden, 10 US7 HW platforms, 8 OSs, 5 vendors

g, ccTLD

Page 5: DNS Tutorial

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”

Page 6: DNS Tutorial

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

Page 7: DNS Tutorial

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

Page 8: DNS Tutorial

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

Page 9: DNS Tutorial

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".

Page 10: DNS Tutorial

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

Page 11: DNS Tutorial

11

net com uk ca jp

foo

buz bar

bar1 bar2 bar3

Zone:Occupies a continues subspace Served by the same nameservers

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

bar

name servers

resource records

DNS Operation

Page 12: DNS Tutorial

12

caching server

client

bar zone

foo zone

com zone

root zone

asking for www.bar.foo.com

answer:www.bar.foo.com A 10.10.10.10

referral:com NS RRscom A RRs

referral:foo NS RRsfoo A RRs

referral:bar NS RRsbar A RRs

Page 13: DNS Tutorial

13

Infrastructure RRs

foo.com. NS ns1.foo.com.foo.com. NS ns2.foo.com.foo.com. NS ns3.foo.com.

foo.com. NS ns1.foo.com.foo.com. NS ns2.foo.com.foo.com. NS ns3.foo.com.

foo.com

comns1.foo.com. A 1.1.1.1ns2.foo.com. A 2.2.2.2ns3.foo.com. A 3.3.3.3

ns1.foo.com. A 1.1.1.1ns2.foo.com. A 2.2.2.2ns3.foo.com. A 3.3.3.3

•NS Resource Record:–Provides the names of a zone’s authoritative servers

–Stored both at the parent and at the child zone

•A Resource Record–Associated with a NS resource record

–Stored at the parent zone (glue A record)