280 likes | 288 Views
Learn about the Domain Name System (DNS) architecture, protocols, and how it resolves names to IP addresses. This lecture covers recursive and iterative queries, caching, and the different types of DNS servers.
E N D
CS 5565Network Architecture and Protocols Lecture 7 Godmar Back
Announcements • PS 1 handed out, due Mon Feb 14 • Project 1A handed out, due Wed Feb 16 • Hardcopies of ALF paper in grad mailroom • ECE Students: • make sure you have a CS lab account CS 5565 Spring 2005
People: many identifiers: SSN, name, passport # Internet hosts, routers: IP address (32 bit) - used for addressing datagrams “name”, e.g., www.yahoo.com - used by humans Q: map between IP addresses and name ? Domain Name System: distributed database implemented in hierarchy of many name servers application-layer protocol host, routers, name servers to communicate to resolvenames (address/name translation) – not built into the network! DNS: Domain Name System CS 5565 Spring 2005
Resource Types CS 5565 Spring 2005
Root DNS Servers org DNS servers edu DNS servers com DNS servers poly.edu DNS servers umass.edu DNS servers pbs.org DNS servers yahoo.com DNS servers amazon.com DNS servers Distributed, Hierarchical Database Client wants IP for www.amazon.com; 1st approx: • Client queries a root server to find .com DNS server • Client queries .com DNS server to get amazon.com DNS server • Client queries amazon.com DNS server to get IP address for www.amazon.com CS 5565 Spring 2005
List published at ftp://ftp.internic.net/domain/named.cache See http://www.root-servers.org/ Replicated using IP anycast See Links section at website for more information DNS: Root Name Servers a Verisign, Dulles, VA c Cogent, Herndon, VA (also Los Angeles) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 11 locations) 13 root name servers worldwide k RIPE London (also Amsterdam, Frankfurt) i Autonomica, Stockholm (plus 3 other locations) m WIDE Tokyo e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 17 other locations) b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA CS 5565 Spring 2005
TLD and Authoritative Servers • Top-level domain (TLD) servers: responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp, .... • Network solutions maintains servers for com TLD • Educause for edu TLD • Authoritative DNS servers: organization’s DNS servers, providing authoritative hostname to IP mappings for organization’s servers (e.g., Web and mail). • Can be maintained by organization or service provider CS 5565 Spring 2005
Caching and Local Name Servers • Q: do we want every (of the 280 million) Internet hosts be contacting a dozen or so root servers all the time? • A: No. Caching is needed • Local Name Servers bundle queries by clients they serve and cache their results CS 5565 Spring 2005
Local Name Server • Does not strictly belong to hierarchy • When a host makes a DNS query, query is sent to its local DNS server • Acts as a proxy, forwards query into hierarchy. • Each ISP (residential ISP, company, university) has one (or more.) • Also called “default name server” or resolver • Contacted by resolver library (libresolv.so, or part of libc – provides such functions as gethostbyname(), getaddrinfo() etc. – more on this later CS 5565 Spring 2005
Once (any) name server learns mapping, it caches mapping cache entries time out (disappear) after some time 86,400 seconds per day TLD servers typically cached in local name servers Thus root name servers not often visited Aside: Local Name Server crucial resource Proper cache management required See Bernstein’s comments on caching in BIND (Berkeley Internet Name Domain) Caching Records CS 5565 Spring 2005
Types of Queries • Many constellations: • Client’s resolver library talks to local name server • Or secondary • Local name server talks to other name servers: root server, TLD servers, … • Beauty of DNS Protocol: can be used for either • Two types of queries: • Recursive: “please resolve this name for me and send me the result” • Good for client, harder for server • Iterated: “please tell me what you know (about some part) of the name and then I’ll ask the next server in hierarchy” • Easy for server, harder for client CS 5565 Spring 2005
Host at gback.cs.vt.edu wants IP address for godmar.stanford.edu Sends recursive query to voodoo Voodoo performs iterative queries local DNS server voodoo.slo.cs.vt.edu root DNS server a.root-servers.net Recursive vs. Iterated Queries 2 TLD DNS server a3.nstld.com 3 4 5 6 7 1 8 authoritative DNS server Argus.stanford.edu requesting host gback.cs.vt.edu godmar.stanford.edu CS 5565 Spring 2005
Currently done outside the protocol Manually or using server-specific or organization-specific facilities Update/notify mechanisms under design by IETF RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html Updating Records CS 5565 Spring 2005
RR format: (name, value, type, ttl) DNS Resource Records DNS: distributed DB storing resource records (RR) • Example (dig output format) a.root-servers.net. 79612 IN A 198.41.0.4 name ttl in secs class IN=Internet type value CS 5565 Spring 2005
DNS protocol :queryand reply messages, both with same message format DNS Message Header msg header • identification: 16 bit # for query, reply to query uses same # • flags: • query or reply • recursion desired • recursion available • reply is authoritative • status code CS 5565 Spring 2005
DNS Message Body Name, type fields for a query RRs in response to query records for authoritative servers additional “helpful” info that may be used CS 5565 Spring 2005
The dig Command $ dig cs.vt.edu mx ; <<>> DiG 9.2.3 <<>> cs.vt.edu mx ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1535 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;cs.vt.edu. IN MX ;; ANSWER SECTION: cs.vt.edu. 14235 IN MX 10 stinger.cs.vt.edu. cs.vt.edu. 14235 IN MX 0 infernus.cs.vt.edu. ;; ADDITIONAL SECTION: stinger.cs.vt.edu. 14235 IN A 128.173.40.26 infernus.cs.vt.edu. 14235 IN A 128.173.40.25 ;; Query time: 1 msec ;; SERVER: 192.168.200.25#53(192.168.200.25) ;; WHEN: Mon Feb 7 10:59:08 2005 ;; MSG SIZE rcvd: 108 CS 5565 Spring 2005
dig (2) $ dig @nomen.cns.vt.edu cs.vt.edu ns ; <<>> DiG 9.2.3 <<>> @nomen.cns.vt.edu cs.vt.edu ns ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27887 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;cs.vt.edu. IN NS ;; AUTHORITY SECTION: vt.edu. 14400 IN SOA lacewing.cns.vt.edu. hostmaster.vt.edu. 200502032 3600 900 604800 14400 ;; Query time: 2 msec ;; SERVER: 198.82.247.37#53(nomen.cns.vt.edu) ;; WHEN: Mon Feb 7 15:24:57 2005 ;; MSG SIZE rcvd: 87 CS 5565 Spring 2005
dig vt.edu ns (1) $ dig vt.edu ns ; <<>> DiG 9.2.3 <<>> vt.edu ns ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59631 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5 ;; ANSWER SECTION: vt.edu. 13872 IN NS nomen.cns.vt.edu. vt.edu. 13872 IN NS milo.cns.vt.edu. vt.edu. 13872 IN NS ns1-auth.sprintlink.net. vt.edu. 13872 IN NS ns2-auth.sprintlink.net. vt.edu. 13872 IN NS ns3-auth.sprintlink.net. ;; ADDITIONAL SECTION: nomen.cns.vt.edu. 14394 IN A 198.82.247.37 milo.cns.vt.edu. 14394 IN A 198.82.247.98 ns1-auth.sprintlink.net. 86394 IN A 206.228.179.10 ns2-auth.sprintlink.net. 86394 IN A 144.228.254.10 ns3-auth.sprintlink.net. 86394 IN A 144.228.255.10 CS 5565 Spring 2005
dig vt.edu ns (2) $ dig vt.edu ns ; <<>> DiG 9.2.3 <<>> vt.edu ns ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20014 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5 ;; ANSWER SECTION: vt.edu. 13870 IN NS milo.cns.vt.edu. vt.edu. 13870 IN NS ns1-auth.sprintlink.net. vt.edu. 13870 IN NS ns2-auth.sprintlink.net. vt.edu. 13870 IN NS ns3-auth.sprintlink.net. vt.edu. 13870 IN NS nomen.cns.vt.edu. ;; ADDITIONAL SECTION: milo.cns.vt.edu. 14392 IN A 198.82.247.98 ns1-auth.sprintlink.net. 86392 IN A 206.228.179.10 ns2-auth.sprintlink.net. 86392 IN A 144.228.254.10 ns3-auth.sprintlink.net. 86392 IN A 144.228.255.10 nomen.cns.vt.edu. 14392 IN A 198.82.247.37 CS 5565 Spring 2005
dig vt.edu ns (3) $ dig vt.edu ns ; <<>> DiG 9.2.3 <<>> vt.edu ns ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54899 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5 ;; ANSWER SECTION: vt.edu. 13869 IN NS ns1-auth.sprintlink.net. vt.edu. 13869 IN NS ns2-auth.sprintlink.net. vt.edu. 13869 IN NS ns3-auth.sprintlink.net. vt.edu. 13869 IN NS nomen.cns.vt.edu. vt.edu. 13869 IN NS milo.cns.vt.edu. ;; ADDITIONAL SECTION: ns1-auth.sprintlink.net. 86391 IN A 206.228.179.10 ns2-auth.sprintlink.net. 86391 IN A 144.228.254.10 ns3-auth.sprintlink.net. 86391 IN A 144.228.255.10 nomen.cns.vt.edu. 14391 IN A 198.82.247.37 milo.cns.vt.edu. 14391 IN A 198.82.247.98 CS 5565 Spring 2005
Security in DNS • Discussion • Why is DNS not secure? • What vulnerabilities can you identify? CS 5565 Spring 2005
Security in DNS • No authentication of content (-> DNSSEC) • Questions: • When should you trust additional information sent? • in- vs. out-of-bailiwick information: • Trust vt.edu nameserver only for hosts that end in vt.edu • How does client know reply comes from server? • Id must match (1 in 65536 chance) • attacker must also know port number client used to send request to send answer CS 5565 Spring 2005
DNS Poisoning • Actual DNS entry $ dig @b.ns.ketil.froyn.name bad.ketil.froyn.name ns ; <<>> DiG 9.2.3 <<>> @b.ns.ketil.froyn.name bad.ketil.froyn.name ns ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23382 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;bad.ketil.froyn.name. IN NS ;; AUTHORITY SECTION: bad.ketil.froyn.name. 259200 IN NS www.example.com. ;; ADDITIONAL SECTION: www.example.com. 259200 IN A 217.144.230.27 ;; Query time: 128 msec ;; SERVER: 129.240.166.41#53(b.ns.ketil.froyn.name) CS 5565 Spring 2005
Protocols & Security • Many Internet protocols were designed assuming cooperating peers • Guards against implementation bugs • Defense against security-related attacks often afterthought CS 5565 Spring 2005
DNS Redirection for CDNs • Coral P2P Content Distribution Network • Use DNS Redirection to find closest peer willing to serve request • See [Freedman 2004]. • Try out • http://www.cs.vt.edu.nyud.net:8090/ • Notice that www.cs.vt.edu.nyud.net -> CNAME’d to www.cs.vt.edu.http.L2.L1.L0.nyucd.net • Redirection is also used by akamai.net CS 5565 Spring 2005
Summary Application Protocols • Request/Reply pattern pervasive • Persistent vs. Nonpersistent Connections • Simplicity! • Few states, if any • Stateless protocols are used where possible • Human-readable message formats often preferred (despite overhead) CS 5565 Spring 2005
Resolution of Quiz • http://2158835401/ : • gethostname() interprets decimals as 32-bit big-endian integers for IP addresses • Aka “dotless decimal IP address” • 2158835401 = 80AD36C9 128 * 1<<24 + 173 * 1<<16 + 54 * 256 + 201 • 128.173.54.201 = gback.cs.vt.edu • Host: header is used by http • DNS is not involved at all CS 5565 Spring 2005