DNS + DNSSEC: System Operation,Resource Records & Packet Formats

Computer Science 742, 2014

Nevil Brownlee

DNS COMPSCI 742, 2014 – p. 1/26

Domain Name System (revision)

Distributed database, maps domain names to IP addresses

RFC 1034, 1035 and lots of other RFCs

Local resolvers send DNS queries to name servers

Top of DNS tree are root servers, A..MRoot servers resolve country-code domains, e.g. .nz, .de

Generic Top Level Domain (gTLD) servers A..M resolveother top-level domains, e.g. .com, .net

Servers can be authoritative or non-authoritativeServers can also be primary or secondary (updated atregular intervals by primary)

DNS COMPSCI 742, 2014 – p. 2/26

DNS: looking up a domain name

DNS looks up a Fully Qualified Domain Name (FQDN)

A client sends a lookup query to a nameserver, e.g. usingdig or nslookup. Nameserver will try to answer queryfrom its own records. If it can’t, it will start either a recursiveor a non-recursive query

Recursive query: DNS server will query higher-levelnameservers on behalf of the client and return the result‘Higher-level’ normally means walking down the tree from itsroot, but it may also mean asking the ‘next-higher’nameserver

DNS servers usually cache (temporarily store) recordsretrieved from other DNS servers – this reduces lookuptraffic

Cached records are ‘non-authoritative,’ original records are‘authoritative’ if they came from an authoritative nameserver

DNS COMPSCI 742, 2014 – p. 3/26

DNS: Nameserver Hierarchy

root (trailing .) assumed at end of FDQN

DNS COMPSCI 742, 2014 – p. 4/26

DNS: Root Servers

There are 13 root servers, A-M; e.g. f.root-servers.net,run by various different organisations

There are also 13 gTLD servers, A-M, run by Verisign

Many of the root servers are anycastAll instances use the same IP address and AS numberThe global (BGP) routing system finds the ‘best’ instancefor each userFor example, F root has 56 instances. Our closest one is atAPE, floor 54 of the SkyTowerLikewise, I and J roots have an instance in Wellington

Anycast servers share the query load, and make the DNSmore resilient against attacks

More info at http://www.root-servers.org/

DNS COMPSCI 742, 2014 – p. 5/26

Configuring a Nameserver

Nameserver configuration is commonly stored in a zone file

A zone file is a set of DNS Resource Records (RRs), eachwith several parts, separated by spaces ..

Label host or subdomain name (no trailing .)

Class network: IN = Internet

Type acronym indicating resource

Data varies according to Type

Comment starts with a semicolon

Values and Identifiers for the RR fields are set out inhttp://www.bind9.net/dns-parameters

An RRset is a group of RRs with the sameLabel, Class and Type

You can inspect configurations using dig, theDomain Information Groper

DNS COMPSCI 742, 2014 – p. 6/26

Examining Resource Records (1)

Zone file starts with an SOA RR, Start Of Authority

SOA sets the default TTL for everything in the zone,and parameters describing this nameserver

We can ask dig for a particuar RR type, e.g. SOA ..

Note that dig looks up FQDNs, and prints a trailing dot afterthem

; <<>> DiG 9.4.3-P1 <<>> www.auckland.ac.nz SOA; (1 server found);; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29502;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:;www.auckland.ac.nz. IN SOA

;; ANSWER SECTION:www.auckland.ac.nz. 1800 IN CNAME www-vip.auckland.ac.nz.

;; AUTHORITY SECTION:auckland.ac.nz. 1800 IN SOA dns3.auckland.ac.nz.

soa.auckland.ac.nz. 2010080922 10800 3600 2419200 1800

DNS COMPSCI 742, 2014 – p. 7/26

Examining Resource Records (2)

dig www.auckland.ac.nz

; <<>> DiG 9.4.3-P1 <<>> www.auckland.ac.nz;; global options: printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60397;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 4

;; QUESTION SECTION:;www.auckland.ac.nz. IN A

;; ANSWER SECTION:www.auckland.ac.nz. 1800 IN CNAME www-vip.auckland.ac.nz.www-vip.auckland.ac.nz. 1800 IN A 130.216.11.141

;; AUTHORITY SECTION:auckland.ac.nz. 1800 IN NS dns1.auckland.ac.nz.auckland.ac.nz. 1800 IN NS dhcp2.tmk.auckland.ac.nz.auckland.ac.nz. 1800 IN NS dhcp1.tmk.auckland.ac.nz.auckland.ac.nz. 1800 IN NS dns2.auckland.ac.nz.auckland.ac.nz. 1800 IN NS pubsec.domainz.net.nz.

;; ADDITIONAL SECTION:dns1.auckland.ac.nz. 1800 IN A 130.216.1.2dns2.auckland.ac.nz. 1800 IN A 130.216.1.1dhcp1.tmk.auckland.ac.nz. 1800 IN A 130.216.207.1dhcp2.tmk.auckland.ac.nz. 1800 IN A 130.216.207.2

;; Query time: 18 msec;; SERVER: 130.216.35.35#53(130.216.35.35);; WHEN: Mon Aug 9 13:26:21 2010;; MSG SIZE rcvd: 253

DNS COMPSCI 742, 2014 – p. 8/26

RFC 1035: DNS Message Specifications

+---------------------+| Header |+---------------------+| Question | the question for the name server+---------------------+| Answer | RRs answering the question+---------------------+| Authority | RRs pointing toward an authority+---------------------+| Additional | RRs holding additional information+---------------------+

All five fields above have 16 bitsHeader begins every DNS Message, it points to the fourfollowing sections

Next four fields are counts, giving the number of question,answer, authority and additional RRs

A count will be zero if there are no RRs of that type

DNS COMPSCI 742, 2014 – p. 9/26

DNS Header Format (1)

1 1 1 1 1 10 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| ID |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+|QR| Opcode |AA|TC|RD|RA| Z | RCODE |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| QDCOUNT |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| ANCOUNT |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| NSCOUNT |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| ARCOUNT |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

ID A 16 bit identifier assigned by the program thatgenerates any kind of query. This identifier is copiedthe corresponding reply and can be used by the requesterto match up replies to outstanding queries.

QR A one bit field that specifies whether this message is aquery (0), or a response (1).

OPCODE Query type. 0 = Standard Query

AA Authoritative Answer.

TC TrunCation - specifies that this message was truncated.

DNS COMPSCI 742, 2014 – p. 10/26

DNS Header Format (2)

RD Recursion Desired - this bit may be set in a query andis copied into the response. If RD is set, it directsthe name server to pursue the query recursively.

RA Recursion Available - this be is set or cleared in aresponse, and denotes whether recursive query support isavailable in the name server.

QDCOUNT unsigned 16 bit integer, nbr entries in questions section.

ANCOUNT unsigned 16 bit integer, nbr entries in answers section.

NSCOUNT unsigned 16 bit integer, nbr entries in ns-records section.

ARCOUNT unsigned 16 bit integer, nbr entries in ’additional’ section.

RCODE Response code - this 4 bit field is set as part ofresponses. The values are:

0 No error condition

1 Format error - Name server couldn’t interpret the query.

2 Server failure - Nsme server was unable to process query.

3 Name Error - Meaningful only for responses from anauthoritative name server, this code signifies that thedomain name referenced in the query does not exist.

DNS COMPSCI 742, 2014 – p. 11/26

RR Format Definitions (1)

1 1 1 1 1 10 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| |/ // NAME /| |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| TYPE |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| CLASS |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| TTL || |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+| RDLENGTH |+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|/ RDATA // /+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

NAME an owner name, i.e., the name of the node to which thisresource record pertains.

TYPE two octets containing one of the RR TYPE codes.

A(1) = address, NS(2) = authoritative name server,MX(15) = mail exchange, AAAA(28) = IPv6 address

CLASS IN(1) = Internet

DNS COMPSCI 742, 2014 – p. 12/26

RR Format Definitions (2)

TTL a 32 bit signed integer that specifies the time intervalthat the resource record may be cached before the sourceof the information should again be consulted. Zerovalues are interpreted to mean that the RR can only beused for the transaction in progress, and should not becached.

Resolvers cache looked-up names, with lifetimes (TTLs)specified by the nameserver

Setting a short lifetime is sometimes used as a form ofserver load balancing. This is not a good idea

RDLENGTH an unsigned 16 bit integer that specifies the length inoctets of the RDATA field.

Number of bytes in RDATA, i.e. the field followingRDLENGTH

Every RR has an RDATA field, carrying data specific to thattype of RR

DNS COMPSCI 742, 2014 – p. 13/26

FQDN format in Questions and Answers

A domain name is represented as a sequence of labels,where each label consists of a length octet followed bythat number of octets. The domain name terminates withthe zero length octet for the null label of the root.Note that this field may be an odd number of octets; nopadding is used.

Example: 0x3 w w w 0x8 a u c k l a n d 0x2 a c 0x2 n z 0x0

TLD = .nz

DNS COMPSCI 742, 2014 – p. 14/26

DNS Query-Response Times (RTTs)

A 742 assignment in 2008 gave students a trace file of DNSpackets, and asked them to plot distributions of the RTTs forthree TLDs, .nz, .au and .comThe data covers servers all over the world ..

RTTs are strongly influenced by ‘speed-of-light’ propogationalso by buffering (congestion) delays in routersand (less so) by delays in nameserversRTT for Sydney is ∼20ms, US West Coast ∼110ms,US East Coast ∼170ms, Europe ∼300ms

We used gnuplot to make the plotsNeed to be careful when choosing plot axis scales –a bad choice makes it a lot harder to see ‘interesting’ things!

DNS COMPSCI 742, 2014 – p. 15/26

RTT distributions: Plotted with log y scale

0.001

0.01

0.1

1

10

100

0 50 100 150 200 250 300 350 400 450

DNS RTTs for three TLDs at U Auckland, April 2008%

Request/Response time (ms)

.au

.nz.com

DNS COMPSCI 742, 2014 – p. 16/26

Comments on the RTT plots

All three TLDs show the same sort of distributionspikes at RTTs corresponding to continentsgaps at RTTs corresponding to oceans

.com has nameservers on all continents, highestconcentration on US West Cost.au has its highest concentration of nameservers in Australia

.nz has lots of nameservers in New Zealand, but its highestconcentration is in the US!

that’s because it’s cheaper for NZ content providers to havetheir servers outside New Zealand

DNS COMPSCI 742, 2014 – p. 17/26

Problem: How to Extend the DNS Protocol?

RFC 1035 said: DNS max record size is only 512 bytes –too small these days!

each reply brings back an RRsetthe number of nameservers for a domain has continued toincrease (why?)if the response size is > 512 bytes, the nameserver wouldtruncate it (and set the Reply header’s TC bit)

DNS can use UDP or TCP as its transport protocola resolver could always retry the query using TCPthat removes the size limitationit also increases the overhead (at least 5 packets instead of 2),which increases the RTT

There are no free bits in the DNS header, and the DNSprotocol has no built-in extension mechanism

RFC 2671, “Extension Mechanisms for DNS (EDNS0),”Paul Vixie, August 1999

DNS COMPSCI 742, 2014 – p. 18/26

EDNS: Extension Mechanisms for DNS

Rationale (from RFC 2671):DNS messages are fixed in many ways

their limits are too small for emerging usesthere is no way to advertise a nameserver’s capabilities

Existing clients must continue to work

EDNS puts new information into an OPT Pseudo-RR, which:pertains to a transport-level message,not to any actual DNS datashall never be cached, forwarded, etc.

OPT RR is sent in a query’s Additional section

OPT RR format:Field Name Field Type Description------------------------------------------------------NAME domain name empty (root domain)TYPE u_int16_t OPTCLASS u_int16_t sender’s UDP payload sizeTTL u_int32_t extended RCODE and flagsRDLEN u_int16_t describes RDATARDATA octet stream attribute,value pairs

DNS COMPSCI 742, 2014 – p. 19/26

Three DNS References

“Hardening the Internet: The impact and importance ofDNSSEC,” SURFnet B.V., 2009http://www.surfnet.nl/Documents/DNSSSEC-web.pdfA clear explanation of how DNS and DNSSEC actually work

“A short history of DNSSEC”http://www.nlnetlabs.nl/projects/dnssec/history.htmlDevelopment and deployment history of DNSSEC

The DNS root domain was signed (at last) in July 2010

“What DNS is Not,” Paul Vixie, 5 Nov 2009, acmqueue,http://queue.acm.org/detail.cfm?id=1647302A thought-provoking essay on how people use DNS

DNS COMPSCI 742, 2014 – p. 20/26

Attacks on the DNS

Cache Poisoningan attacker can intercept a DNS request, thenreply quickly with address of bogus serverresolver cache now has bad address for that domainthe real server replies later; that reply is discarded

Kaminsky Attackglue records – every answer includes

Answer to the query (can be empty if the query can’t be answered)Authority RRs (who is authoritative for the domain being queried)Additional information (addresses of the authoritative servers)

attacker poisons cache, inserting a bogus NS recordcan do this at any time, just query for a non-existent domain(don’t have to wait for a real name to time out)only have to get the Request ID number correct, easy if theresolver simply increments ID for each requestnow attacker can direct queries to lots of subdomains!

DNS COMPSCI 742, 2014 – p. 21/26

Kaminsky’s Patch

Essentially makes resolver choose random Request IDs,and random source ports for each request – that increasesthe number of bits an attacker must guess from 16 (ID) to 32(ID + source port)

However, it’s an arms race. SURFnet says"unpatched servers can be poisoned in as little as 3 s,and a fully patched server can be poisoned within 11 h"

Would SSL reduce the risk?no, attacker can set up an SSL Proxy

Idea is to intercept the SSL setup request, so that resolver makesits SSL session with the proxy.The proxy then sets up another SSL session with the targetednameserver, and passes the messages both waysBut the proxy can then see (and modify) the clear-text messagesin either direction

So . . . need a better solution.

DNS COMPSCI 742, 2014 – p. 22/26

DNSSEC

Provides cryptographic authentication of answers to DNSqueries, using digital signatures

Only proves that a reply is genuine, does not keep theresponse hidden

Each RRset in a zone is signed using the zone’s private key,and authenticated using the zone’s public key

Starting from the DNS root, one can walk down DNS treechecking replies at each level. Each zone contains thepublic key for the zones below it

DNSSEC calls the sequence of certificates (for each level)a “chain of trust”The root zone provides the DNSSEC “trust anchor”

There may be some unsigned zones in a lookup path, thesebreak the chain, creating “islands of trust”

DNS COMPSCI 742, 2014 – p. 23/26

RFC 4034: Four new DNSSEC RRs

DNSKEYpublic key for a zone, used by resolver to validate(authenticate) signatures for the zone’s RRsets

RRSIGsignature for an RRset with a particular name, class and type

NSEC (Next SECure)next owner name containing authoritative data or a delegationpoint NS RRset, and the set of RR types present at the NSECRR’s owner name. Used in handling wild-card DNS requests.

DS (Delegation key Signer)inserted at a delegation point, indicates that the delegatedzone is digitally signed, and recognises the indicated key as avalid zone key. An explicit statement about the delegation.(RFC 3658)

DNS COMPSCI 742, 2014 – p. 24/26

Implementing DNSSEC in a Zone

References:http://www.dnssec.net/practical-documents

Summary of: “DNS in 6 minutes,” Alan Clegg, ISC . . .

Use the DNSSEC maintenance tools,don’t try to do it “by hand”

Create keys:ZSK, 1024-bit RSASHA1: DNSSEC Zone Signing KeyKSK, 4096-bit RSASHA1: DNSSEC Key Signing Key

Sign the zone, i.e.add RRSIG, NSEC and DNSKEY RRs to the zone (using tool)must re-sign the zone EVERY time you modify it!keys need to be maintained (protect against compromise, etc)

Notify parent zone of DNSSEC –parent zone needs a DS RR to create the trust chain

DNS COMPSCI 742, 2014 – p. 25/26

‘dotless’ domains

ICANN has decided to allow new TLDs, e.g. a big companycould have ‘bigcompany’ as an FQDN – is this a good idea?

RSSAC (Root Servers Advisory Committee)condisidered operational aspects for TLD nameservers

SSAC (Security and Stability Advisory Committee)have warned of security implications

IAB (Internet Architecture Board)have advised that dotless domains break IETF Standards

The issue: DNS search listsa DNS Administrator can configure a list of domains to besearched for any queryfor example, www could be tried in cs.auckland.ac.nz,then in auckland.ac.nzdotless FQDNs should not use a search listcurrently a hot topic!

DNS COMPSCI 742, 2014 – p. 26/26