Table of Contents DNS. Short history of DNS (1) DNS and BIND. Specification and implementation. A short history of DNS.

Transcription

1 Table of Contents Specification and implementation DNS dr. C. P. J. Koymans Informatics Institute University of Amsterdam September 14, 2009 A short history of DNS Root servers Basic concepts Delegation Lookups DNS on the wire Limitations and extras DNS and BIND Short history of DNS (1) DNS (Domain Name System) concepts theory BIND (Berkeley Internet Name Domain) implementation Other implementations: djbdns (TinyDNS), PowerDNS, NSD,... practice December 1973 HOSTS.TXT (RFC 606) November 1983 DNS invented (RFC 882) October 1984 TLDs defined (RFC 920)

2 Short history of DNS (2) Short history of DNS (3) October 1984 gtlds established.arpa (temporary).gov,.edu,.com,.mil,.org January 1985 SRI runs DNS service.net (forgotten in RFC 920) July 1985 cctlds established.us (February 15, 1985).UK,.GB (July 24, 1985).AU (March 5, 1986).NL (April 25, 1986).JP (August 5, 1986) Short history of DNS (4) Short history of DNS (5) November 1987 DNS Specification STD 13, RFC 1034, RFC 1035 November 1988.INT domain established April 1993 InterNIC starts, operated by NSI (Network Solutions Inc.) June 1994 Commercial use becomes dominant September 1995 Charging for domain name registration starts

3 Short history of DNS (6) Short history of DNS (7) 1997 Start planning for competition On July 1, 1997, as part of the Administration s Framework for Global Electronic Commerce, the President directed the Secretary of Commerce to privatize the management of the domain name system (DNS) in a manner that increases competition and facilitates international participation in its management. Source: MoU (Memorandum of Understanding; November 1998) November 1998 Start of ICANN (Internet Corporation for Assigned Numbers and Names) Responsibilities IP address assignment, via ASO Internet domain names, via GNSO and ccnso Protocol parameters and port numbers, supported by IANA DNS structure Root servers Hierarchical tree root is unnamed ( unlabeled ) Top Level Domains (TLDs) generic TLDs (gtlds) country code TLDs (cctlds) Distributed database Status in 2001, according to ICANN official Michael Roberts 13 root servers Most of them located in the US (10)

4 Root servers map Root server list (part 1) A NSI (Verisign) Herndon VA (Dulles VA) B USC-ISI Marina del Rey CA C PSInet (Cogent Communications) Herndon VA (*) D University of Maryland College Park MD E NASA (Ames) Mountain View CA F Internet Software Consortium (ISC) Palo Alto CA (*) G DISA (US DOD NOC) Vienna VA H US Army Research Lab (ARL) Aberdeen MD Map provided by ICANN Root server list (part 2) Anycast I NORDUnet (Autonomica) Stockholm (*) J NSI (Verisign) Herndon (Dulles VA) (*) K RIPE (NCC) London (*) L ICANN Marina del Rey (Los Angeles CA) (*) M WIDE Tokyo (*) (*) These nameservers use anycast Overloading of IP address Route to nearest instance (BGP metric) Global or local significance

5 k root server presence Anycasted root servers map Map provided by RIPE Map (2007) provided by Patrik Fältström DNS concepts Domain names Domain Name Space Resource Records Name Servers Resolvers Nodes (internal and leaf) have a label root label is empty (not ) non-root labels must be non-empty A domain name is a sequence of labels separated by. (dot) A domain is a domain name together with all domain names below

6 To slash or not to slash To dot or not to dot Compare domain names to pathnames in a filesystem Labels (filenames) separated by / (slash). Absolute versus relative pathnames Absolute domain (FQDN) mail.serv.os3.nl. Relative domain mail mail.serv machine.cs can (could?) give problems (Why?) Resource Records (RR s) A record owner (domain name) type (A, CNAME, MX, NS, PTR, SOA,... ) class (IN, CH) ttl (time to live (in cache)) resource data (depends on type) Address record translates domain name to IP address mail.serv.os3.nl Multihomed hosts have several A records Routers have multiple A records

7 CNAME record MX record Canonical name record defines an alias info4u.os3.nl. No other RR s are allowed Does not work for subdomains DNAME record proposed for that Mail exchanger record defines for a domain mail servers for that domain and the order of their preference lower precedence is preferred MX must not point to a CNAME NS record PTR record Name server record defines a cut (zone) Must list at least two name servers Makes DNS distributed Delegates responsibility NS record must not point to a CNAME A pointer record literally points to an arbitrary point Mostly used for reverse lookup mail.serv.os3.nl. But lookup works via in-addr.arpa in-addr.arpa.

8 SOA record Numerical SOA params (recommended values) Start Of Authority record administrates important zone parameters hostname of master server ns1.os3.nl. address (in dot form) of responsible person hostmaster.os3.nl. numerical parameters The SOA record itself can have a low TTL (for instance 3600 = 1 hour) Serial (YYYYMMDDnn) Refresh (86400 = 1 day) Retry (7200 = 2 hours) Expire ( = 1000 hours 40 days) Minimum ( = 2 days, but... ) Numerical SOA params (OS3 example) Minimum These values are quite low (during IP migration) Serial ( ) Refresh (3600 = 1 hour) Retry (1800 = 30 minutes) Expire (21600 = 6 hours) Minimum (3600 = 1 hour, but... ) Different interpretations Minimal TTL allowed (never used this way) Default TTL, if TTL not specified (BIND 8) TTL for caching negative replies (BIND 9) BIND 9 uses global $TTL for default TTL

9 Resource Record sets (RRsets) Name servers and zones Grouping of a set of RRs with the same owner, class and type All RRs in an RRset must have the same TTL DNSSEC signs complete RRsets with RRSIG RRs which might make the RRSIG RR an exception to the item before :) Zones are created by cuts (delegations) Cuts are defined by NS records inside parent zone non-authoritative by definition Glue A records sometimes needed When name servers for the delegation are in bailiwick Or in the more general case when name servers have circular dependencies and create bailiwick loops Bootstrap issues Name server types Hint file for root RR s Glue for child zones Glue NS records (stub server) Glue A records (for servers inside the child zone) Glue data is not authoritative unless the parent is also a slave server Non-authoritative data should be replaced by authoritative data Master (primary) Slave (secondary) Stub (limited secondary) Stealth (secondary that is not listed) Caching-only (never authoritative) Forward-only (using forwarders )

10 Recursion and iteration Resolver Recursive behaviour Server follows referrals itself and Often doesn t have authoritative data Iterative behaviour Server answers with authoritative data or Server passes referrals back to clients Library doing domain name lookup Uses /etc/resolv.conf Contacts a recursive nameserver Does not follow referrals itself Caching Common mistakes Necessary for performance Negative caching adds more functionality See RFC 2308 Lots of subtleties See RFC 1912 and also RFCs 2181 and 4697 Using CNAMEs in MX and NS records Forgetting the final. Lame delegation Lack of human coordination

11 DNS Message packet format DNS packet header Header section Question section Answer section Authority section Additional section ID Flags QDCOUNT ANCOUNT NSCOUNT ARCOUNT DNS header fields ID Flags QDCOUNT ANCOUNT NSCOUNT ARCOUNT Transaction Identifier See next slide Number of questions Number of answers Number of authority records Number of additional records DNS header flags Bit(s) Mnemonic Meaning 0 QR Query or Response 1-4 OPCODE Kind of Query 5 AA Authoritative Answer 6 TC TrunCation or Truncated Response 7 RD Recursion Desired 8 RA Recursion Available 9 - Reserved 10 AD Authentic Data (DNSSEC) 11 CD Checking Disabled (DNSSEC) RCODE Result Code (bits 12-15)

12 DNS result codes DNS opcodes 0 Query Standard query 1 IQuery Inverse Query (obsolete) 2 Status Status query (not standardized) 4 Notify Change of master data 5 Update Dynamic update Value Mnemonic Meaning 0 NoError No Error 1 FormErr Format Error 2 ServFail Server Failure 3 NXDomain Non-Existent Domain 4 NotImp Not Implemented 5 Refused Query Refused >15... Extended result codes (EDNS0) Queries Label types In most cases QDCOUNT is 1 Query consists of QNAME (sequence of labels, coded with length/value) QTYPE (2 bytes) QCLASS (2 bytes, almost always IN (==1)) First two bits of the length byte denote the label type A label length may not exceed 63 octets (6 bits needed) 00: Normal label length 11: Compressed label: 6+8 bits used as pointer 01: Extended label type (EDNS0) : Binary labels (for use with IPv6 PTR types)

13 Answers, Authorities and Additionals (1) Answers, Authorities and Additionals (2) Each of these are a list of resource records NAME, TYPE, CLASS (as in queries) TTL (4 bytes) RDLENGTH (2 bytes) RDATA (RDLENGTH bytes) Answers Answers the question(s) Special treatment of CNAMEs Authorities Adds NS records as referral information Additionals Courtesy information Dangerous... if accepted too easily especially if the information is not related to the question DNS limitations Message Authentication DNS is usually based on UDP RFC 1035 maximum size is 512 bytes of DNS content Option to use TCP was present from the start but was not recommended for ordinary use DNS has weak security DNS packets can easily be spoofed Initially no support for message authentication except for a clear text Transaction ID TSIG mechanism added in RFC 2845 calculates HMAC-MD5 over the complete DNS packet adds this as a pseudo -TSIG-RR uses secret keys may use a pseudo -TKEY-RR for key exchange (RFC 2930) SIG(0) mechanism added in RFC 2931 uses public keys uses DNSSEC mechanisms extends DNSSEC to cover complete DNS packets

14 Extension Mechanisms for DNS EDNS0 Specified in RFC 2671 Necessary for DNSSEC Extends maximum size of UDP-based requests and responses Extends possible flags, result codes and label types Uses a pseudo -OPT-RR Used by DNSSEC for DO (DNSSEC OK) extended flag