Domain Name System. CS 571 Fall 2006. 2006, Kenneth L. Calvert University of Kentucky, USA All rights reserved

Domain Name System CS 571 Fall 2006 2006, Kenneth L. Calvert University of Kentucky, USA All rights reserved

DNS Specifications Domain Names Concepts and Facilities RFC 1034, November 1987 Introduction to the system and its components Explains the concept of the Domain Name Space and zones Domain Names Implementation and Specification RFC 1035, November 1987 Details of protocols and algorithms 2

Domain Name System Structure Probably the world's largest distributed database system Purpose: map human-readable names to other information (especially addresses) Major components: Domain Namespace Resource Records (RRs) Resolvers Name Servers 3

Domain Name Space Tree-structured namespace with a single root The root's name is "" (the empty string) Tree structure provides: Scalability (in the usual way) Distributed authority: control over subtrees can be delegated Each Fully-Qualified Domain Name (FQDN) is a node in the tree Each branch in the tree has a label (e.g. "com") Labels no more than 64 bytes long currently subset of ASCII-only FQDN represented by sequence of labels from node to root: e.g. "protocols.netlab.uky.edu." 4

Domain Name Space com edu net org gov mil arpa int... ad al... zw "generic" Top-level Domains (gtld's) 2-letter ISO standard ountry codes 5

Domain Name Space com edu net org gov mil arpa int... ad al... zw uky netlab cs cslab ozark rose 6

Delegation of Naming Authority For each node in the namespace tree there is one (and only one) authority The authority controls what goes in the subtree A subtree for which authority has been delegated is called a zone The boundary between the containing zone and the subzone is called a "cut" E.g. netlab.uky.edu zone is delegated from uky.edu The authority for a zone is responsible for: Maintaining the authoritative database information (RRs) that describe the zone Providing for at least two independent nameservers 7

Resource Records (RRs) The database is viewed as a logical set of Resource Records Each RR defines a binding between a FQDN and some other information Each RR has a TYPE according to the kind of information in the binding A: the information is a four-byte IPv4 Address NS: the information is the FQDN of a Name Server MX: the information is the FQDN of a server that accepts mail for the domain SOA: the information marks the beginning and end of a ZONE etc. FQDN (variable) Type (2) Class (2) TTL (4) Data Len (2) Type-specific info 8

Resource Records (RRs) The standard defines details of representation of the information in the RR's (i.e. how it is stored in the database)! This ensures it is simple to go back and forth between database and wire format Example: A record has 32-bit IP address in network byte order ozark.netlab.uky.edu A IN TTL 4 128 163 140 219 9

General DNS Message Format Query ID Flags etc. # Questions # Answer RRs # Authority RRs # Add'l Info RRs Query/Answer flag Opcode Authoritative Answer flag Recursion Desired flag Recursion available flag Return code Questions Answers Authorities (NS RRs for above Answers) Additional Info (A records for Nameserver RRs) 10

DNS Zone RRs - Example netlab.uky.edu SOA tosh.netlab.uky.edu [marks beginning of zone] serial = 2006110301 ttl = 3600... netlab.uky.edu NS tosh.netlab.uky.edu netlab.uky.edu NS peter.netlab.uky.edu netlab.uky.edu NS ncc.uky.edu netlab.uky.edu NS nic.net.uky.edu tosh.netlab.uky.edu A 128.163.140.42 peter.netlab.uky.edu A 128.163.140.33 ncc.uky.edu A 128.163.1.6 nic.net.uky.edu A 128.163.3.10 protocols.netlab.uky.edu CNAME yosemite.netlab.uky.edu yosemite.netlab.uky.edu A 128.163.140.43 yosemite.netlab.uky.edu MX mail-protocols.netlab.uky.edu emulab.netlab.uky.edu NS peter.netlab.uky.edu emulab.netlab.uky.edu NS ns1.emulab.netlab.uky.edu peter.netlab.uky.edu A 128.163.140.33 ns1.emulab.netlab.uky.edu A 128.163.140.99 netlab.uky.edu SOA [marks end of zone] 11

Model of Operation - Iterative Host in "netlab.uky.edu" domain application 1 "munnari.oz.au, A" resolver x 2 cache DNS Query: domain: munnari.oz.au type: A 3 5 DNS Response: domain: munnari.oz.au type: A Answer: (nothing) Authority:. (root) NS C.ROOT-SERVERS.NET Additional Info: C.ROOT-SERVERS.NET A 192.33.4.12 nameserver 4 x DB tosh.netlab.uky.edu 128.163.140.42 12

Model of Operation - Iterative Host in "netlab.uky.edu" domain application resolver "munnari.oz.au, A" cache 6 7 DNS Response: Domain: munnari.oz.au type: A Answer: (nothing) Authority: au NS dns1.telstra.net Add'l Info: dns1.telstra.net A 203.50.5.200 nameserver DNS Query: Domain: munnari.oz.au type = a DB root C.ROOT-SERVERS.NET 192.33.4.12 13

Model of Operation - Iterative Host in "netlab.uky.edu" domain application "munnari.oz.au, A" 8 resolver cache DNS Query: Domain: munnari.oz.au type = a DNS Response: Domain: munnari.oz.au type: A Answer: (nothing) Authority: oz.au NS au2ld.csiro.au Add'l Info: au2ld.csiro.au A 130.116.2.21 9 nameserver DB au DNS1.TELSTRA.NET 203.50.5.200 14

Model of Operation - Iterative Host in "netlab.uky.edu" domain application 10 "munnari.oz.au, A" 11 resolver cache DNS Query: Domain: munnari.oz.au type = a DNS Response: Domain: munnari.oz.au type: A Answer: munnari.oz.au A 202.12.74.196 Authority: oz.au NS au2ld.csiro.au Add'l Info: au2ld.csiro.au A 130.116.2.21 nameserver DB oz.au au2ld.csiro.ua 130.116.2.21 15