DNS Domain Name System Tutorial IETF64 DNS for

  • Slides: 48
Download presentation
DNS (Domain Name System) Tutorial @ IETF-64 DNS for Application Protocol Designers Ólafur Guðmundsson

DNS (Domain Name System) Tutorial @ IETF-64 DNS for Application Protocol Designers Ólafur Guðmundsson OGUD consulting Peter Koch DENIC e. G 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 1

Tutorial Overview • Goal: – Give the audience basic understanding of DNS to be

Tutorial Overview • Goal: – Give the audience basic understanding of DNS to be able to facilitate new uses of DNS • Location of slides: – http: //stora. ogud. com/DNSTutorial. ppt • Tutorial Focus: Big picture - Not software help - DNS != BIND - No gory protocol details 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 2

What is DNS? • DNS is one of the core Internet Protocols required for

What is DNS? • DNS is one of the core Internet Protocols required for operation of the Internet • Routing and DNS are the most important infrastructure protocols as without them nothing else will work • DNS Provides: – Mapping from names to addresses – Mechanism to store and retrieve information in a global data store 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 3

DNS Data Model DNS is global "loosely consistent" delegated database • delegated -> contents

DNS Data Model DNS is global "loosely consistent" delegated database • delegated -> contents are under local control • loosely consistent -> shared information (within constraints) – does not need to match or be up-to date. – operation is global with owners of "names" responsible for serving up their own data. • Data on wire is binary • Domain names are case insensitive for [A-Z][a-z], – case sensitive for others ( exämple. com != exÄmple. com) • Hostname [A. . Z 0. . 9 -] RFC 952 – Restricts names that can be used – IDN provides standard encoding for names in non-US_ASCII 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 4

DNS tree “. ” ORG IETF www 2005 -11 -06 COM ogud ISOC DE

DNS tree “. ” ORG IETF www 2005 -11 -06 COM ogud ISOC DE IS UK XXX DENIC EDU DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 5

DNS Terms • Domain name: any name represented in the DNS format – foo.

DNS Terms • Domain name: any name represented in the DNS format – foo. bar. example. – 32 br. example. (32 == ASCII space binary value) • DNS label: Presentation format – each string between two ". " (unless the dot is prefixed by “”) – i. e. foo. bar is 2 labels foo. bar is 1 label • DNS zone: – a set of names that are under the same authority – example. com and ftp. example. com, www. example. com – Zone can be deeper than one label, like: . us, ENUM • Delegation: – Transfer of authority for a domain • example. org is a delegation from org • the terms parent and child will be used. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 6

More DNS terms • RR: a single Resource Record • RRSet: all RRs of

More DNS terms • RR: a single Resource Record • RRSet: all RRs of same type at a name – Minimum DNS transmission unit – Sample RRSet: Foo. example. 36000 IN TXT “Record #1” Foo. Example. 36000 IN TXT “Record #2” • TTL (Time To Live): The time an RRSet can be cached/reused by a non- authoritative server 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 7

DNS Elements • Resolver – stub: simple, only asks questions – recursive: takes simple

DNS Elements • Resolver – stub: simple, only asks questions – recursive: takes simple query and makes all necessary steps to get the full answer, • Server – authoritative: the servers that contain the zone file for a zone, one Primary, one or more Secondaries, – caching: A recursive resolver that stores prior results and reuses them • Some perform both roles at the same time. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 8

DNS retrieval mode • DNS is a "lookup service" – Simple queries --> simple

DNS retrieval mode • DNS is a "lookup service" – Simple queries --> simple answers • No search • no 'best fit' answers – Limited data expansion capability • DNS reasons for success – Simple • "holy" Q-trinity: QNAME, QCLASS, QTYPE – Clean • Explicit transfer of authority – Parent is authoritative for existence of delegation, – Child is authoritative for contents. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 9

DNS Protocol on the wire • Transport: – UDP 512 bytes Payload, with TCP

DNS Protocol on the wire • Transport: – UDP 512 bytes Payload, with TCP fallback – EDNS 0 (OPT RR) expands UDP payload size by mutual agreement. – TSIG hop by hop authentication and integrity • Retransmission: built in 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | +--+--+--+--+--+--+--+--+ | QDCOUNT == 1 | +--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+ Query section contains: QNAME: <name in domain name format, variable length> QCLASS: 2 bytes QTYPE: 2 bytes. Red fields set by resolver in the query – Resends timed out query to a different server. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 10

DNS RR wire format +---------+------+----+-----------+ + Domain name |type | class| TTL | RDATA

DNS RR wire format +---------+------+----+-----------+ + Domain name |type | class| TTL | RDATA | +---------+------+----+-----------+ <variable> 2 2 4 2 <variable> • Owner name (domain name) – Encoded as sequence of labels • Each label contains – Length (1 byte) – Name ([1. . 63] bytes) – ogud. com 04 ogud 03 com 00 • • • Type : MX, A, AAAA, NS … CLASS: IN (other classes exist but not global) TTL: Time To Live in a cache RL: RD LENGTH: size of RDATA: The contents of the RR – Binary blob, no TLV (Type Length Value). 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 11

DNS Record Types: • DNS Internal types – Authority: NS, SOA, • List names

DNS Record Types: • DNS Internal types – Authority: NS, SOA, • List names of Name Servers and Start Of Authority/zone. – DNSSEC: DS, DNSKEY, RRSIG, NSEC • Used for DNSSEC – Meta types: OPT, TSIG, TKEY, SIG(0) • Meta Types: Not stored in DNS zones, transfer information between DNS nodes – Indirect: CNAME, DNAME • Indirect types, cause Resolver to change direction of search – Server must have special processing code • Terminal RR: – Address records: A, AAAA, – Informational: TXT, HINFO, KEY, SSHFP … • carry information to applications • Non Terminal RR: MX, SRV, PTR, KX, A 6, NAPTR, AFSDB • contain domain names that may lead to further queries. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 12

[jhc] Give example of “longest match” – I presume this is “most labels from

[jhc] Give example of “longest match” – I presume this is “most labels from mostsignificant end”? Got rid of DNS packets are small to avoid arguments and we said that eariler How DNS works • DNS zone is loaded on authoritative servers, Revist Longest match sentence. – servers keep in sync using information in SOA RR via AXFR, IXFR or other means. • DNS caches only store data for a “short” time – defined by TTL on RRSet. • DNS Recursive Resolvers start at “longest match” on query name they have when looking for data, and follow delegations until an answer or a negative answer is received. – DNS transactions are fast if servers are reachable. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 13

DNS query • QNAME: www. ietf. org • QCLASS: IN • QTYPE: A. Ask

DNS query • QNAME: www. ietf. org • QCLASS: IN • QTYPE: A. Ask org NS Root Server Org Server www. ietf. org Ask ietf. org NS Stub resolver www. ietf. org A 65. 256. 255. 51 2005 -11 -06 Ietf. org Server Recursive Resolver www. ietf. org A 65. 256. 255. 51 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 14

DNS Wildcards: The area of most confusion: FACTS • Match ONLY non existing names

DNS Wildcards: The area of most confusion: FACTS • Match ONLY non existing names • Expansion is terminated by existing names – Do not expand past zone boundaries – Empty non-terminal name • No RRSets present at this name • But the name exists 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 15

DNS wildcards: The area of most confusion: MYTHS • Record: *. example MX 10

DNS wildcards: The area of most confusion: MYTHS • Record: *. example MX 10 mail. example – matches any name in zone example !! – supplies RR type to names present that are missing MX RRs • Is added to MX RRSet at a name – expands only one label • www. *. example will expand 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 16

Wildcard Match • Contents of a zone: *. example. TXT "this is a wildcard"

Wildcard Match • Contents of a zone: *. example. TXT "this is a wildcard" www. example. A 192. 0. 2. 1 jon. doe. example. A 192. 0. 2. 5 example • Name “doe. example” exists w/o any RRtypes empty nonterminal • Name “jane. doe. example. ” will not be expanded from wildcard • Name: “jane. eod. example. ” Matched. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 17

DNS rough corners • UDP Packet size: – 512 for standard DNS, 4 K+

DNS rough corners • UDP Packet size: – 512 for standard DNS, 4 K+ for EDNS 0 • Keeping RRSets small is good practice. • Lame delegations: – Parent and children must stay in sync about name servers. – Secondary servers must keep up-to date with Primary. • problems areas: permissions, transfer protocol not getting through, clock synchronization, old/renumbered primary/secondary, etc. • Data integrity: Cache Poisoning – DNS answer can be forged, in particular if query stream is visible • use protected channel to recursive resolvers. – TSIG, IPSEC, local host • Broken/old DNS Software: – Small percentage, but persistent base 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 18

DNS Historic problems and solutions: Static data • DNS Update (RFC 2136): – adds

DNS Historic problems and solutions: Static data • DNS Update (RFC 2136): – adds the ability to change DNS contents of the fly used a lot. • Difficult to add/modify data due to operator – DNS Secure Update (RFC 3007) specifies how to securely delegate capability to update DNS names or name/type(s) 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 19

DNS Historic problems and solutions: Unknown RR types • Early DNS implementation hard coded

DNS Historic problems and solutions: Unknown RR types • Early DNS implementation hard coded RR types. – Unknown RR were/are dropped by some resolvers – Unknown RR were not served by authoritative servers • Implication: takes long time to introduce New RR types. • Solution: – RFC 3597 defines that all DNS servers and resolvers MUST • support unknown RR types and rules for defining them. • suggests a common encoding in presentation format for them. • Deployment: – BIND-9, BIND-8. 2. 2, ANS, CNS, MS DNS-2003, DNSCache, NSD, Power. DNS, Net: : DNS, DNSJava, DNSPython. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 20

Current DNS Infrastructure problems • Old implementations still around as authoritative/caching servers – Protocol

Current DNS Infrastructure problems • Old implementations still around as authoritative/caching servers – Protocol has evolved over the last 20 years. • Middle boxes have old/bad DNS software that is broken. – Some Load balancers do stupid things, – Firewalls apply yesterday’s DNS rules. – Applications interfaces refuse to ask for unknown types • Majority of the infrastructure – is RFC 3597 enabled. – has EDNS 0 support • TCP DNS queries are frequently blocked. • "Are you affected" Simple test: – http: //stora. ogud. com/DNSSEC/unknown/index. html • Right now shell scripts, soon a java applet. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 21

DNS Operational problems • Low TTL: if TTL is low, RRSet is cached for

DNS Operational problems • Low TTL: if TTL is low, RRSet is cached for short time and frequent lookups are required: – negative effects: Do. S on self and infrastructure, slower connections – positive effects: Highly dynamic and allows primitive load balancing • Bad delegations: – NS out of date in parent – NS contains random data to overcome registry requirements • Old Software still in use after vendor recommends retirement 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 22

DNS Operational Excuses • Opposition to placing data in DNS is sometimes based on

DNS Operational Excuses • Opposition to placing data in DNS is sometimes based on “arguments” like: • Not supported by our software – Provisioning, Authorative servers, resolvers, firewalls, middleboxes, » take your pick. • Do not feel like it – Turf war, politics …. – …. . 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 23

DNS API issues • Whole or none of RRSet will arrive, – in non

DNS API issues • Whole or none of RRSet will arrive, – in non determined order. • DNS Resolver API should – Return known weighed DNS RRSet in weighed order – other RRSets in “random” order. • DNS data should reside in one place and one place only – at name, or at <prefix>. name – zone wide defaults • there are no zone wide defaults, since the "zone" is an artificial boundary for management purpose – Some applications have said that if RR does not exist at name then look for zone default at apex, • Zone cut is hard to find by stub resolvers, • hierarchy in naming does not necessarily imply hierarchy in network administration. • Data at apex are also bad due to "apex overload“ – Tree climbing == BAD 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 24

DNS API qualities and Good Tools • API should – – Be simple and

DNS API qualities and Good Tools • API should – – Be simple and expandable, Return good/appropriate error codes Allow server selection and query for any type. Seamlessly provide ENDS and TSIG • Good Stub Resolver tool kits: – – – Perl: Net: : DNS and Net: : DNS: : SEC, Java: DNSJava, Python: dnspython C: not aware of any C++: we do not know 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 25

DNS Sub Typing ISSUE • Some RR types are "containers", e. g. – KEY

DNS Sub Typing ISSUE • Some RR types are "containers", e. g. – KEY – NAPTR – TXT (the original) (with the RFC 1464 convention) • DNS responses MUST consist of complete RRSets – You cannot query for partial matches (only holy Q-Trinity: QNAME, QTYPE, QCLASS) • Resolver cannot ask for a subset of an RRSet, e. g. – at most eight address records (A RRs) for a given name or – only those MX RRs with priority of less than 100 – all TXT RRs containing "money". • Applications (or specialized API) will have to select their RRs from the response, potentially dumping larger parts of the RRSet, depending on one or more secondary qualifiers buried within RDATA 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 26

Sub. Typing side effects • Subtyping results in larger responses – Multitude of different

Sub. Typing side effects • Subtyping results in larger responses – Multitude of different ENUM services using NAPTR • Subtyping can be avoided by – dedicated types instead of type/subtype – selector prefixes (see SRV) • Method of choice depends on number and nature of subtypes expected and the necessity to deal with wildcards 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 27

DNSSEC: Data integrity and authentication for DNS • Full Name: DNS Security Extensions –

DNSSEC: Data integrity and authentication for DNS • Full Name: DNS Security Extensions – RFCs 4033, 4034, 4035 • Role: Protect DNS and the data it carries – How done: view from 10 km. • DNS RRSet is signed by the zone it belongs to. • zone DS RRSet is vouched for by parent zone. • What DNSSEC does not do: – Make data in DNS any more correct. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 28

DNSSEC: More details • Data protections – Each DNS RRSet has a special RRSIG

DNSSEC: More details • Data protections – Each DNS RRSet has a special RRSIG containing a signature by the zone private key, for a certain time period • Existence proof: – Chain of NSEC records lists all names in a zone and their RR types. (authentic proof/denial of existence) • Parent signs a fingerprint of child's Key Signing DNSKEY (DS RR) – allows transition from a secure parent zone to a secure child zone. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 29

DNSSEC: impacts • Zones – become larger – need periodic maintenance – have to

DNSSEC: impacts • Zones – become larger – need periodic maintenance – have to deal with key management • Resolvers need to know Secure Entry Points to signed sub trees. – Changes over time, needs updating. • Implementations supporting DNSSEC: – BIND-9, DNSJava, Net: : DNS: : SEC, NSD, ANS, CNS 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 30

What does DNSSEC provide to applications? 1. DNS answer with verifiably signed RRSet(s) is

What does DNSSEC provide to applications? 1. DNS answer with verifiably signed RRSet(s) is known to be identical to what zone published. 2. Widely deployed DNSSEC allows application to place more important data in DNS • unsigned keying info • • • 2005 -11 -06 IPSECKEY, SSHFP spoof proof service location other. . . DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 31

SRV (Se. RVice) Record • Provides a mechanism to place a service on named

SRV (Se. RVice) Record • Provides a mechanism to place a service on named host(s) at specified port. • Used extensively in MS Active Directory – Also used by some IM application like Jabber. • recurring task: given (new) service named COOL, need to offer it – old solution: aliases "ftp", "www", . . . – problem: needs well known port, no exceptions; • single target (server) or approximately evenly distributed across multiple addresses 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 32

Generalize MX: that COOL SRV • COOL service in example. org _cool. _tcp. example.

Generalize MX: that COOL SRV • COOL service in example. org _cool. _tcp. example. org SRV 0 0 5133 SRV 10 20 9876 SRV 10 20 3456 SRV 10 40 6738 srv 55. mega. example srv 33. mega. example. srv 44. mega. example. srv 66. mega. example. “_” avoids conflicts with hostnames • Services need to be registered – currently under discussion: separate registry – this is not too good for local service location (-> tree climbing) 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 33

When to use SRV • SRV works best if you have a TCP or

When to use SRV • SRV works best if you have a TCP or UDP service and want to be able to delegate and distribute • SRV is widely deployed and supported • See RFC 2782 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 34

NAPTR • Other common task: Map name to URL • SRV doesn‘t help –

NAPTR • Other common task: Map name to URL • SRV doesn‘t help – No local part – No variable scheme • Naming Authority Pointer: NAPTR – – – order preference flags service regexp replacement 2005 -11 -06 16 bit value character-string domain-name DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 35

NAPTR and beyond: DDDS • NAPTR is embedded in a complete framework • DDDS

NAPTR and beyond: DDDS • NAPTR is embedded in a complete framework • DDDS == Dynamic Delegation Discovery System • Used in ENUM and ONS (the RFID name space) – These create their own name spaces 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 36

S-NAPTR • SRV and NAPTR combined (RFC 3958) • Avoids application specific DDDS overhead

S-NAPTR • SRV and NAPTR combined (RFC 3958) • Avoids application specific DDDS overhead • NAPTR leads to more NAPTR or SRV • SRVs lead to A (or AAAA) 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 37

Design Choices for placing new information in DNS. • New class – You need

Design Choices for placing new information in DNS. • New class – You need to supply the root servers for it • New Suffix – Talk to ICANN • Reuse TXT (or some other type) • <prefix>. name • New Type 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 38

Placing New information in DNS: Reuse existing Type • TXT may appear as the

Placing New information in DNS: Reuse existing Type • TXT may appear as the obvious choice – No semantics – RFC 1464 subtyping – prefixing could help, but has its own problems – TXT wastes space, this is still important – If new RRSet is large you want EDNS 0 support • Modern software does this and unknown types as well!!!! – MORAL: Fight for local upgrades, do not force the whole Internet to work around your local issues. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 39

Placing New information in DNS: Name prefix, magic name • Selector put in front

Placing New information in DNS: Name prefix, magic name • Selector put in front of (underneath) domain name: – – _axfr. example. org APL 1: 192. 0. 2. 3 May interfere with zone maintainer’s naming policy Prefix may end up in a different zone Wildcards will not work like expected, i. e. _prefix. *. example. org does not expand – No registry for prefixes • Magic name, e. g. www – Overloading of multiple names in single application server – May conflict with naming policy 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 40

New RR Type Benefits • Full control over contents • Application centered semantics •

New RR Type Benefits • Full control over contents • Application centered semantics • Simpler for applications to parse – If your specification is simple: KISS • No collisions, smaller answers 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 41

New RR Type Phase-in • When you design the new RR type to be

New RR Type Phase-in • When you design the new RR type to be used with the existing namespace • What does the absence of the type at a name mean? • Specify: – Feature not available – Feature not supported – Use application default • Do not overdo the problem! 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 42

How to get a new DNS RR type • Technical Rules (see RFC 3597)

How to get a new DNS RR type • Technical Rules (see RFC 3597) 1. No additional section processing 2. No name compression of embedded domain names 3. Clean definition, no overly complicated structure • Process: (being simplified RFC 2929 bis) 1. Write an ID, get review by people that understand your protocol, update draft. 2. Ask DNS experts (DNS WG chairs) for quick review, update ID 3. Ask DNS WG(s) for review 4. Submit to IESG, you get type code from IANA after IESG processes 5. Advertise new type code 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 43

How to enable the use of a new type? • Make sure your –

How to enable the use of a new type? • Make sure your – software is “modern" – middle-ware boxes do not get in the way, • Fight for site updates. • Provide tools to – convert new RR type from textual format to RFC 3597 portable format for zone inclusion, – Use dynamic update to provision new type RRSets • Good tools: Perl NET: : DNS, DNSJava, • Modern Servers: – BIND-9, MS DNSServer 2003, NSD, Power. DNS, ANS, CNS 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 44

Optimization considered evil • Problem: – Frequently Non-terminal records proposed demand that terminal records

Optimization considered evil • Problem: – Frequently Non-terminal records proposed demand that terminal records be returned in answer ==> Additional section processing • Facts: 1. Additional section processing is done in servers 2. Before updated servers are deployed RR type aware resolvers need to do all work. 3. Not all authoritative servers may have the necessary additional records 4. Additional records may not fit 5. Recursive resolver may have data already 6. Roundtrips are cheap, 7. Lasy resolver writer will ASSUME additional section processing is done • Result: – Recursive Resolver has to be able to do work forever, • Moral: Do not attempt to optimize DNS, it causes problems. 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 45

RFC starting reading list • DNS related RFC 100+ – Many obsoleted • Important

RFC starting reading list • DNS related RFC 100+ – Many obsoleted • Important ones – 1034, 1035 Original specification – 4033, 4034, 4035 DNSSEC – 1123, 2181 Clarifications – 3597, 2136, 1995, 3007 Major protocol enhancements – 3833 Threat Analysis for DNS 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 46

Pointers to more information • IETF working groups – DNS EXTensions: http: //www. dnsext.

Pointers to more information • IETF working groups – DNS EXTensions: http: //www. dnsext. org – DNS Operations: http: //www. dnsop. org • Individual sites – http: //www. dns. net/dnsrd – http: //www. dnssec. net 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 47

More resources • DNS book list – http: //www. networkingbooks. org/dns • DNS Software

More resources • DNS book list – http: //www. networkingbooks. org/dns • DNS Software tools: – – – - BIND 9: http: //www. isc. org DNSJava: http: //www. dnsjava. org Perl: http: //www. net-dns. org Nominum: ANS, CNS http: //www. nominum. com Python: http: //www. dnspython. org NSD http: //www. nlnetlabs. nl/nsd/ 2005 -11 -06 DNS Tutorial @ IETF-64 ogud@ogud. com & pk@denic. de 48