introduction to dnssec: principles and practicepeople.ds.cam.ac.uk/fanf2/dns/nws42/notes.pdf ·...

Introduction to DNSSEC: Principles and Practice

Tony Finch〈[email protected]〉〈[email protected]〉

Tuesday 1st April 2014

Abstract

This talk is a quick introduction to DNSSEC, the Domain Name System Securityextensions. DNSSEC is interesting because it does more than just add tamper-proofing to the DNS: it is also a new public-key infrastructure.

The talk will describe the security features that DNSSEC adds (and does notadd) to the DNS, and how the DNSSEC PKI can support other protocols such asSSL/TLS and SSH.

To be useful, DNSSEC needs to be widely deployed. The talks will demonstratethat switching on DNSSEC can be straight-forward, and will mention some of thetraps and pitfalls that can catch the unwary.

1 Introduction

I gave this talk at Networkshop, which is a conference run by JANET for UK academicnetwork operators run by JANET.

I am going to assume that you are already familiar with basic DNS concepts such asresource records and zones.

Everything I will talk about is work done by other people.

1

2 Context

Pre-history

• Steven M. Bellovin, June 1995. Using the Domain Name System for system break-ins.

• Wietse Venema, September 1992. TCP Wrapper: network monitoring, access con-trol, and booby traps.

• Robert Elz, Randy Bush, RFC 2181, July 1997. Clarifications to the DNS Specifi-cation.

• Daniel J. Bernstein. djbdns. December 1999.

I think the first person to write about security problems in the DNS was Steve Bellovin[2]. He was so terrified by the poor security that he kept his paper quiet for several yearsbefore it was eventually published in 1995.

At that time resolvers and application software would basically believe everything thatturned up in a DNS packet. What makes this worse is DNS caches have an interestingmultiplying effect: if you can get poisonous data into a shared cache, your successfulattack can affect thousands of people for several days.

There were a number of quick improvements to the DNS which addressed some of theattacks in Bellovin’s paper.

Application software which was doing hostname-based access control started to cross-check forward and reverse DNS rather than believing the attacker’s reverse DNS. Anearly example is TCP Wrapper’s ”paranoid” host checking, which I think was addedafter Wietse’s paper was published in 1992 [14].

RFC 2181 [6] says that DNS servers must treat “additional” data with suspicion. Ad-ditional data is supposed to be a helpful performance improvement which avoids multipleround trip query chains, but you do not want to believe it if (for example) you are doing areverse DNS lookup on a connection from an attacker, who helpfully gives you an answerand also tells you where google.com is.

Since the DNS mostly uses UDP it is fairly vulnerable to spoofed packets. Followingdjbdns [3] most DNS software now makes spoofing harder by using random DNS queryIDs and random UDP source ports.

However none of these measures protect you against attackers that are on your net-work, or against bad intermediaries such as DNS caches.

DNSSEC is a fairly comprehensive system to detect and stop bogus DNS data.

2

DNSSEC development

This is an extract from a graph of dependencies between the DNS RFCs made by RayBellis of Nominet [1]. It is illegible but you don’t need to read it! Each blob representsan RFC, the grey ones are obsolete and the yellow ones are current specifications.

This part of the graph covers most of the DNSSEC development process. It wasamazingly long and painful. The project started in 1995 and the current base RFCs(towards the bottom of this diagram) were not published until 2005.

Almost all of the grey blobs represents a problem with the original version of theprotocol which required an incompatible change to fix. Despite this, DNSSEC does havea reasonably coherent design and rationale, which I am going to try to explain in thistalk.

3

DNSSEC deployment

• March 2005 – RFC 4033, RF 4034, RFC 4035

• July 2008 – Kaminsky cache poisoning attack

• January-July 2010 – Root zone signed

Paul Vixie said in August 2008 [15],

DNSSEC is a colossal flop, but not a mistake. It’s an embarrassment, butwe’d do it all again if we had to. [...] It’s ugly and complicated and if weknew then what we know now we’d’ve scrapped DNS itself and started fromscratch just to avoid the compromises we’ve made. But we didn’t know then,etc., and what we have to do now is avert our gaze and fully deploy this uglyembarrassing thing.

That was about the low point for DNSSEC. The specifications were done, there weremultiple implementations, but there was almost no deployment apart from a few enthu-siasts.

But that summer Dan Kaminsky discovered a new attack on the DNS which made itdramatically easier to get a resolver to accept poison data into its cache [16]. This wasenough of a push to get ICANN to start serious work on DNSSEC for the root zone.Several top level domains enabled DNSSEC around the same time as the root.

DNSSEC deployment – root zone

Here is a graph from ICANN of the number of top level domains with DNSSEC since2010 [9]. Progress has been fairly steady but not particularly thrilling. The recent uptickis due to the influx of new gTLDs, which must support DNSSEC, and the total hasonly recently passed 50%. When I checked yesterday, 298 out of 495 TLDs had securedelegations.

4

DNSSEC deployment – large ccTLDs

Here is a graph produced by Bert Hubert, the developer of PowerDNS [8]. It showsthe number of second-level domains with DNSSEC in the countries that have made themost effort to deploy it, from summer 2012 to the present.

The total number of domains in .nl is nearly 5.5 million so nearly 1/3 of them aresigned with DNSSEC. That is by far the largest proportion of any TLD.

The top-level domain registries in these countries have made a special effort to de-ploy DNSSEC by providing technical assistance and financial incentives – your domainregistration is cheaper if you deploy DNSSEC.

The other key thing that has helped this deployment is a steady improvement in thequality and usability of DNSSEC software, a lot of it sponored by the TLD registries inthese countries.

5

DNSSEC deployment – ac.uk

In UK academia just four universities have deployed DNSSEC – Cambridge, Imperial,Loughborough, and Leicester – plus a handful of other institutions. We don’t have thekinds of incentives that work in the root zone or in the Netherlands, so I am going to tryto appeal to higher motives.

If DNSSEC were just about securing the DNS then it would be an enormous crypto-graphic mallet to crack a quite small nut, and it wouldn’t be interesting enough for meto want to talk about it. After all, we are used to working around the insecurity of theDNS so it doesn’t seem like a big deal.

I do not mean to say that securing the DNS is not important. At the beginning ofFebruary, CERT Polska reported a large-scale DNS redirection attack on home routerswhich was aimed at financial theft [12]. If DNSSEC were widely deployed it would havethwarted this attack.

In the last week in Turkey, Twitter has been blocked by intercepting its DNS, aswell as open DNS resolvers such as Google Public DNS and OpenDNS. If DNSSEC werewidely deployed it would make this meddling obvious; however DNSSEC cannot stopyour ISP from blocking a site - it mainly turns malicious redirections into blocks.

Now that is useful, but not compelling. What is important is that DNSSEC is astrategic move to provide better security support for all application protocols on theInternet. But this will only work if it becomes popular. Don’t be discouraged by Vixie’sbitterness – it really isn’t that bad!

6

3 Rationale and security properties

DNSSEC security properties

The main features that DNSSEC provides are authenticity and integrity of DNS data.That is, you know where the data came from and that no-one messed around with it onthe way. DNSSEC does this using cryptographic public key signatures.

DNSSEC authenticates DNS data, not DNS servers. That is, the key that signs thedata belongs to the ultimate source of that data. It doesn’t matter what server you getthe data from, even if the server is untrustworthy, so long as you can verify the signature.

Phish

Date: Tue, 31 Dec 2013 06:17:40 -0800

From: Hermes Help Desk <[email protected]>

To: undisclosed-recipients:;

Bcc: [email protected]

Subject: Validate Mailbox

Hello Mailbox User,

kindly visit our scheduled Internet Webmail

Customer Validation Form!

Click Here <http://hermes.form2go.com/128416.html>

to validate your account.

As a contrasting analogy, I connect to my mail server over TLS, which authenticatesthe server. This guarantees that the mail I read was stored on my server, but TLS doesn’tguarantee anything about the original source of a message I am reading.

According to this analogy, DNSSEC works more like PGP or S/MIME, which authen-ticates the message contents, as opposed to TLS which authenticates the server.

7

DNS caches and clients

Recursive DNS servers are in a similar intermediate position to my mail server, butconsiderably less trustworthy – especially when I am roaming to a dodgy wireless hotspot and using its DNS server.

With DNSSEC, recursive DNS servers and caches continue to do a useful job ofreducing load on authoritative servers and reducing query latency for clients.

Recursive servers need to validate DNSSEC signatures so that bogus data does notget into their cache. DNS client machines need to validate DNSSEC signatures so thatthey do not have to trust the recursive server.

So the DNSSEC deployment model at the user / client /resolver end is the same asfor plain DNS, except that everything validates signatures to stop bad data propagating.

Masters and secondaries

Similarly, DNSSEC does not change the deployment model for authoritative servers.

It is quite common for people to use third-party secondary name servers to improvethe performance and availability of their zones – it’s true for the root, for .uk, for ac.uk,cam.ac.uk, and cl.cam.ac.uk.

DNSSEC allows you to continue these arrangements without requiring any extra keyexchange or extra trust between the master server and its secondaries. The master signsthe zone with its private key and ships just the signed data to the secondaries, who canserve the zone without doing any cryptography,

This separation of signing and serving a zone was important back in the 1990s whencrypto performance was terrible and government restrictions were a huge concern. It isstill valuable today because it keeps the trust model simpler.

8

Record not message integrity

;; ANSWER SECTION:

cam.ac.uk. 86400 IN NS authdns0.csx.cam.ac.uk.

cam.ac.uk. 86400 IN NS authdns1.csx.cam.ac.uk.

cam.ac.uk. 86400 IN NS dns0.cl.cam.ac.uk.

cam.ac.uk. 86400 IN NS dns0.eng.cam.ac.uk.

cam.ac.uk. 86400 IN NS dns1.cl.cam.ac.uk.

cam.ac.uk. 86400 IN NS ns2.ic.ac.uk.

;; ADDITIONAL SECTION:

authdns0.csx.cam.ac.uk. 86400 IN A 131.111.8.37

dns1.cl.cam.ac.uk. 21600 IN A 128.232.0.18

ns2.ic.ac.uk. 86400 IN A 155.198.142.82

Since DNSSEC-aware authoritative servers do not do crypto, there isn’t any way forthem to guarantee the integrity of a whole DNS reply, since that would depend on thecontents of the query.

The other reason for this odd lack of message integrity checks is that DNS messagesare often assembled using data from multiple sources, as in this example, which has datafrom Cambridge University Information Services, the Cambridge Computer Lab, andfrom Imperial College.

So DNSSEC signs individual resource record sets, and includes all the necessary sig-natures in the message. This example would have four signatures, for the NS records(which together comprise one RRset) plus three for the three address records.

Unfortunately DNS data is small and public key signatures are relatively large, soadding all these signatures massively increases the size of a zone – ten times larger isfairly typical.

9

What DNSSEC does not do

DNSSEC does not improve the availability of the DNS – it only adds failure modes,when signature validation fails.

DNSSEC does not provide confidentiality – it has no encryption, only public keysignatures.

There are a number of reasons for this, beyond the lack of online cryptography thatI have already mentioned.

The main reason is that encryption would not improve privacy very much.

DNS resolution involves revealing your query to a lot of third parties: your ISP’srecursive server, and often top-level domain and other secondary name servers.

When you make a DNS query, usually the next thing you do is connect to the addressin the answer. If an attacker can snoop your traffic they can see the answer even if theycouldn’t see inside the DNS exchange.

These reasons are not especially good, so people are working on adding encryption tothe DNS, but it is very early days.

What makes DNSSEC interesting

• RFC 4025 – IPSECKEY

• RFC 4255 – SSHFP

• RFC 4398 – CERT

• RFC 4871 – DKIM

• RFC 6698 – TLSA

• RFC 6844 – CAA

What makes DNSSEC interesting is that it becomes reasonable to put public keys inthe DNS and use DNSSEC to authenticate those keys. There are already a number ofspecifications for doing this with different keys, and I will shortly give a demo of makingit work with ssh.

This is one of the things that makes the lack of encryption rather short-sighted. Whatif we start using the DNS to store PGP or S/MIME public keys? Then my DNS activitywill reveal whose keys I am looking up, and therefore who I am exchanging email with,which is a lot more sensitive than just revealing that I am using my mail server.

10

DNSSEC is a PKI

• cl.cam.ac.uk.

• cam.ac.uk.

• ac.uk.

• uk.

• •

Putting public keys into the DNS makes it into a public key infrastructure: that is, away to associate cryptographic keys with some meaningful identity.

DNSSEC is a structured hierarchial PKI that follows the delegation structure of theDNS: the root (i.e. ICANN and Verisign and the US Department of Commerce) au-thenticates .uk (i.e. Nominet) who authenticate ac.uk (i.e. JANET) who authenticatecam.ac.uk etc. Organizations in other parts of the hierarchy cannot say anything aboutnames outside their subtree.

Contrast with the TLS PKI X.509 which is entirely flat. Any certification authoritycan associate any name with any key. This means that the whole X.509 system is onlyas secure as its weakest CA. You cannot get a more secure certificate by paying more orby choosing a reputable CA.

With DNSSEC you can in principle get meaningfully better security by careful choiceof name and provider and by paying for extra authentication procedures to stop roguechanges to your domain’s delegation.

DNSSEC is not ideal – it concentrates too much trust in the root – but it is betterthan X.509 from the security economics point of view.

11

4 DNSSEC validation demo

Demo – validation

start...

A recursive server

$ ssh [email protected]

# host cam.ac.uk

cam.ac.uk has address 131.111.150.25

cam.ac.uk mail is handled by 7 mx.cam.ac.uk.

# dig cam.ac.uk

; <<>> DiG 9.9.5 <<>> cam.ac.uk

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36118

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 9

;; ANSWER SECTION:

cam.ac.uk. 86400 IN A 131.111.150.25

This machine is running a recursive name server, specifically BIND 9.9.5. I can dosome queries against it.

host tells me our web server IP address and incoming mail server name. I get a lotmore details from a query with dig.

Note the flags:

qr means this is a response from the server

rd means recursion desired

ra means recursion available

Normal for a recursive name server.

Note that there are DNSSEC records associated with cam.ac.uk but I have not askeddig to show them.

12

A recursive server

; <<>> DiG 9.9.5 <<>> no-dnssec.dotat.at


;; Got answer:



;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;no-dnssec.dotat.at. IN A

;; ANSWER SECTION:

no-dnssec.dotat.at. 3600 IN A 212.13.197.229

I can also query a special test zone and I get an answer.

Turn on validation

# vi /usr/local/etc/named/named.conf

Before:

options {

# default settings are OK

};

After:

options {

dnssec-validation auto;

dnssec-lookaside auto;

};

Now I am going to turn on validation.

As you can see this server has a simple configuration.

The first line I add turns on DNSSEC validation using BIND’s built-in copy of theroot public key.

The second line adds validation using the ISC DLV, which some sites use to covergaps in the secure delegation hierarchy. (See https://dlv.isc.org.)

13

Turn on validation

# rndc reload

# rndc flush

# dig cam.ac.uk

; <<>> DiG 9.9.5 <<>> cam.ac.uk


;; Got answer:


;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1




;cam.ac.uk. IN A

;; ANSWER SECTION:

cam.ac.uk. 86400 IN A 131.111.150.25

Now I tell the server to reload its configuration

And I need to flush the un-validated gubbins from its cache

Now this time when I dig you can see there is a new flag in the response:

ad means authenticated data

And apart from that it is pretty unexciting. Not much visible has changed. This is agood thing: infrastructure technology should quietly get on with its job.

14

Validation failure

# dig no-dnssec.dotat.at

; <<>> DiG 9.9.5 <<>> no-dnssec.dotat.at


;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18858





;no-dnssec.dotat.at. IN A

;; Query time: 472 msec

;; SERVER: 131.111.8.193#53(131.111.8.193)

;; WHEN: Tue Feb 25 11:35:21 GMT 2014

;; MSG SIZE rcvd: 47

The difference is more obvious if I query a domain that is broken for DNSSEC vali-dation.

The query fails.

SSH without DNSSEC

# ssh black.csi.cam.ac.uk

The authenticity of host ’black.csi.cam.ac.uk (2001:630:212:110:221:9bff:fe16:a526)’ can’t be established.

RSA key fingerprint is 1a:b9:90:ee:b1:42:52:26:09:7e:8a:eb:70:d0:0a:c9.

Are you sure you want to continue connecting (yes/no)? ^C

It gets more interesting when applications make use of DNSSEC, because it can makekey distribution easier and more trustworthy.

Who always verifies the host fingerprint before typing their password into it? OK I’llquit before I do something mildly unsafe. Now I will get ssh to make use of DNSSEC, soI don’t need to make a leap of faith.

15

Application keys – SSH

# dig black.csi.cam.ac.uk sshfp

; <<>> DiG 9.9.5 <<>> black.csi.cam.ac.uk sshfp


;; Got answer:






;black.csi.cam.ac.uk. IN SSHFP

;; ANSWER SECTION:

black.csi.cam.ac.uk. 86400 IN SSHFP 1 1 EC365639846190A7C575CE33BA50F5F8B8E03BDA

black.csi.cam.ac.uk. 86400 IN SSHFP 2 1 63BD9811ECA943E9DE3A3A6D38BB46B018B91D55


;; SERVER: 131.111.8.193#53(131.111.8.193)

;; WHEN: Tue Feb 25 11:36:24 GMT 2014


I have a machine with SSHFP records in the DNS, which are signed with DNSSEC.I need to make a couple of configuration changes so ssh will use these records for hostauthentication.

Configure stub resolver

# vi /etc/resolv.conf

Before:

nameserver 127.0.0.1

domain csi.cam.ac.uk

After:

nameserver 127.0.0.1

domain csi.cam.ac.uk

options edns0

The stub resolver on this machine is talking to the validating resolver on the same ma-chine. I need to add options edns0 which will make ssh ask for the DNSSEC validationstatus and trust the results.

16

Configure ssh

# vi /usr/local/etc/ssh/ssh config

Before:

# default settings are OK

After:

VerifyHostKeyDNS yes

I also need to turn on SSHFP authentication in ssh’s configuration.

SSH with DNSSEC

# cat ~/.ssh/known_hosts

cat: /root/.ssh/known_hosts: No such file or directory

# ssh black.csi.cam.ac.uk

Password:

I check that ssh knows nothing about my target host.

This time when I run ssh I immediately get a password prompt.

SSH was able to authenticate the host without extra human assistance.

Demo – validation

...end

17

5 How DNSSEC works

So, what was going on after I turned on DNSSEC validation?

DNSSEC validation follows a fairly close parallel to normal DNS resolution.

Root hints (IPv6 edition)

a.root-servers.net. IN AAAA 2001:503:ba3e::2:30

c.root-servers.net. IN AAAA 2001:500:2::c

d.root-servers.net. IN AAAA 2001:500:2d::d

f.root-servers.net. IN AAAA 2001:500:2f::f

h.root-servers.net. IN AAAA 2001:500:1::803f:235

i.root-servers.net. IN AAAA 2001:7fe::53

j.root-servers.net. IN AAAA 2001:503:c27::2:30

k.root-servers.net. IN AAAA 2001:7fd::1

l.root-servers.net. IN AAAA 2001:500:3::42

m.root-servers.net. IN AAAA 2001:dc3::35

When BIND is resolving a query, it starts off by asking the root name servers. BINDhas a built-in list of the root server addresses which it uses to start this process.

A referral, without DNSSEC

;; flags: qr; QUERY: 1, ANSWER: 0 , AUTHORITY: 10 , ADDITIONAL: 13


;black.csi.cam.ac.uk. IN AAAA

;; AUTHORITY SECTION:

uk. 172800 IN NS ns1.nic.uk.

uk. 172800 IN NS ns2.nic.uk.

;; etc...


ns1.nic.uk. 172800 IN A 195.66.240.130

ns1.nic.uk. 172800 IN AAAA 2a01:40:1001:35::2

ns2.nic.uk. 172800 IN A 217.79.164.131

;; etc...

The root servers do not have the answer, so they send a referral to another set ofname servers. The referral contains the delegation records from the root zone which givethe names and addresses of the .uk zone’s name servers.

This process repeats with the .uk, and ac.uk zones, until we get an answer from thecam.ac.uk zone.

18

DNSSEC chain of trust – dnsviz.net

Similarly, BIND has a built-in copy of the root key, which is its “trust anchor”, i.e.the starting point for validation.

Actually as this diagram shows, the root zone has more than one key. The key at thetop is the “key-signing key”, which belongs to ICANN. Its private key is kept in a pair ofhardware security modules, which are kept inside safes, inside cages, inside locked rooms,in secure data centres on the west and east coast of North America. Four time a yearone of the HSMs is used to generate signatures for the root DNSKEY RRset for the nextquarter. Even dusing these key ceremonies the root KSK is kept offline.

The other two keys are “zone-signing keys”. These are used to sign the rest of the rootzone. One of them is currently in use; the other one is either being retired or introducedinto service as part of a key rollover. The ZSKs are kept online by Verisign and are infrequent use since the root zone changes several times a week.

I am explaining this in some detail since you will see as I scroll down this diagram[5] that the other zones also have separate KSKs and ZSKs. This practice is encouragedby DNSSEC signing tools and by the procedures that have been developed around them,so it is usual to follow this convention even though most zones do not have complicatedsplit organizational arrangements like the root zone.

The arrows in this diagram indicate which key is used to sign which records. So youcan see the key-signing key signs itself and the zone-signing keys.

One of the zone-signing keys is signing a DS record. DS records are published atdelegation points, next to a delegation NS RRset. A DS record contains a cryptographichash of one of the DNSKEY records in the child zone.

So this DS in the root zone authenticates the KSK in the .uk zone, which authenticatesthe .uk ZSKs, which authenticate the ac.uk DS record, etc. down to cam.ac.uk.

In the demo I showed a DNSSEC failure for the zone no-dnssec.dotat.at. Thisfailure was caused by a mismatch between the DS record in the parent zone and theDNSKEY records in the child, which is a rough simulation of what happens if an attackertries to pass off an answer signed with the wrong key.

19

DNSSEC chain of trust

cam.ac.uk. 86400 IN DS 52543 5 2 (

F3D339A8602D46463CBDCDC33769165B58489FAE38FC

5DB84AE0136A8874FCB2 )

cam.ac.uk. 86400 IN DNSKEY 257 3 5 (

AwEAAe9CQ5E0MbMr7AGMTmlzpyLrh+JJxjITH77T6cEx

vk69Fqon41u/PWRi+XOKWjHO5d/ffqSLAs+K+SswQwZR

G2FyVieRWXQDoLt1bDRrjNqjM+ursG1TNMUE0jZDiFRp

iHxDE+qhWLOJXwwMarkOw8QFa4U3VirMTROZkeTqyp5P

MLnB/cBzqLdiHN2VVElYd53tt5Z/OP8cSt7T9SFAXp8=

) ; KSK; alg = RSASHA1; key id = 52543

;; Top tip: use dig +multiline to get helpful comments

This is what DS and DNSKEY records look like, the DS from the delegation point ofthe parent zone, and the DNSKEY record from the apex of the child zone.

When your zone is signed with DNSSEC, a certain amount of key management isrequired, which will be covered in the next talk, and I will give a brief demo shortly.

You also need to manage your DS records in your parent zone. This is done using thesame interface that you use for managing your delegation’s NS records and glue.

RRSIG – resource record signature

cam.ac.uk. 86400 IN RRSIG DNSKEY 5 3 86400 (

20140429171945 20140330161945 52543 cam.ac.uk.

VKxyh21mZbqJu2JLCkGMFSfBZehHfSXu9rkta+iBwWFz

y9eC/sDwhwGeypMmo54uWNd9UXfsZm93PHo6jmZ0rJEX

xr5J88LBzc8ryEfiNJjuNvR0Yu2pB5qYi6rGLzixNbGU

CCqCGKqnGqhFVVS2dhYFnUzJchvnpohaY3iE4c4QdeiP

rWPTOIMyef5V4myhgumv3fyie6G12JRMnNohvA==

• See RFC 4034 for details of the DNSSEC record formats.

RRSIG records are big and ugly, and there are a lot of them.

An important feature of RRSIG records is the expiry and inception times, displayed inISO 8601 format [10] – year, month, day, hour, minute, second. These provide protectionagainst replay attacks, so attackers cannot bogusly re-use old data.

Zones need to be frequently re-signed in order to keep the signatures fresh. One of themost common problems with DNSSEC is when signing stops working causing signaturesto expire. Fortunately this is becoming more rare as software becomes more reliable andmakes automatic zone signing easier.

20

NSEC / NSEC3 – next secure

tahini.csx.cam.ac.uk. 14400 IN NSEC (

tanzanite.csx.cam.ac.uk.

A MX AAAA RRSIG NSEC )

D0J53D8V33MHN4M6K7QK1529R1VFF4QJ.ac.uk. 14400 IN NSEC3 (

1 0 10 - D0T3CH0AH4FNL56SUG6Q3VE9FP2DBI9J NS )

• RFC 7129: Authenticated denial of existence in the DNS

RRSIG records prove that data exists and is valid. DNSSEC also needs to be able toprove that data does not exist.

These proofs of nonexistence are usually generated in advance by the DNSSEC signingsoftware, so that secondary servers do not have to have any private keys nor do anycryptography when answering questions.

The strategy is to systematically enumerate which reource records exist, and makethe gaps in the list explicit. A validator can use the proof of a gap to verify a negativeanswer.

For example, “tamper” comes between “tahini” and “tanzanite” so this NSEC recordproves that tamper.csx.cam.ac.uk does not exist.

NSEC3 records are a suped up obfuscated version of the same basic idea. RFC 7129 isa very nice tutorial explaining how it works [7].

21

6 DNSSEC signing demo

Demo – signing

start...

An authoritative server


# cd /var/run/named

# cat dnssec.demo.dotat.at

$TTL 60

dnssec.demo.dotat.at. 60 IN SOA (

dnssec-demo-a.csi.cam.ac.uk. fanf2.cam.ac.uk.

1 ; serial

3600 ; refresh (1 hour)

3600 ; retry (1 hour)

604800 ; expire (1 week)

60 ; minimum (1 minute)

)

NS ns.demo.dotat.at.

A 127.0.0.1

This machine is running an authoritative name server hosting a small zone.

22

Key generation

# dnssec-keygen dnssec.demo.dotat.at

Generating key pair.........++++++ ....................++++++

Kdnssec.demo.dotat.at.+005+59346

# dnssec-keygen -f KSK dnssec.demo.dotat.at

Generating key pair......................................................................................................................................+++ ................................................................................................................................+++

Kdnssec.demo.dotat.at.+005+61981

# chgrp named K*

# chmod g+r K*

In order to sign this zone I need to create some keys for it. BIND prefers each zoneto have at least two keys, a zone-signing key and a key-signing key.

I have to note the KSK key tag.

For automatic signing, BIND needs to be able to read the key files.

Server config – before

# vi /usr/local/etc/named/named.conf

options {

directory "/var/run/named";

recursion no;

allow-query { any; };

rate-limit {

responses-per-second 10;

};

};

zone dnssec.demo.dotat.at {

type master;

file "dnssec.demo.dotat.at";

};

My configuration includes response rate limiting to prevent the server from being usedin DDoS attacks.

23

Server config – after

zone dnssec.demo.dotat.at {

type master;

file "dnssec.demo.dotat.at";

auto-dnssec maintain;

inline-signing yes;

};

The first line turns on automatic signing.

Inline signing mode keeps the dynamically generated signatures in a separate file,which allows me to keep using a static zone file instead of switching to a dynamic zone.

Reload server

# rndc reload

server reload successful

# tail /var/log/syslog | sed ’s/.*[]]://’

reloading zones succeeded

zone dnssec.demo.dotat.at/IN (unsigned): loaded serial 1

all zones loaded

running

zone dnssec.demo.dotat.at/IN (signed): loaded serial 1

zone dnssec.demo.dotat.at/IN (signed): receive secure serial: unchanged

zone dnssec.demo.dotat.at/IN (signed): sending notifies (serial 1)

zone dnssec.demo.dotat.at/IN (signed): reconfiguring zone keys

zone dnssec.demo.dotat.at/IN (signed): next key event: 25-Feb-2014 13:22:00.600

zone dnssec.demo.dotat.at/IN (signed): sending notifies (serial 3)

OK, reload the server configuration, and if we look at the log we will see that BINDhas done something.

24

Directory listing

# ls -l

total 44

-rw-r--r-- 1 named named 241 Feb 19 01:01 dnssec.demo.dotat.at

-rw-r--r-- 1 named named 512 Feb 25 12:22 dnssec.demo.dotat.at.jbk

-rw-r--r-- 1 named named 1680 Feb 25 12:22 dnssec.demo.dotat.at.signed

-rw-r--r-- 1 named named 4135 Feb 25 12:22 dnssec.demo.dotat.at.signed.jnl

-rw-r--r-- 1 root named 449 Feb 25 12:10 Kdnssec.demo.dotat.at.+005+59346.key

-rw-r----- 1 root named 1010 Feb 25 12:10 Kdnssec.demo.dotat.at.+005+59346.private

-rw-r--r-- 1 root named 623 Feb 25 12:11 Kdnssec.demo.dotat.at.+005+61981.key

-rw-r----- 1 root named 1774 Feb 25 12:11 Kdnssec.demo.dotat.at.+005+61981.private

-rw-r--r-- 1 named named 5 Feb 25 12:23 named.pid

-rw-r----- 1 named named 102 Feb 25 11:04 session.key

In the directory listing we can see the new .signed zone file which is several timeslarger than the original.

No secure delegation chain yet

# dig dnssec.demo.dotat.at

; <<>> DiG 9.9.5 <<>> dnssec.demo.dotat.at


;; Got answer:






;dnssec.demo.dotat.at. IN A

;; ANSWER SECTION:

dnssec.demo.dotat.at. 60 IN A 127.0.0.1

;; AUTHORITY SECTION:

dnssec.demo.dotat.at. 60 IN NS ns.demo.dotat.at.


ns.demo.dotat.at. 60 IN A 131.111.8.194


;; SERVER: 131.111.8.193#53(131.111.8.193)

;; WHEN: Tue Feb 25 12:31:14 GMT 2014


25

Just signing a zone isn’t enough to make it validate as secure. Note there is no ADflag in the dig output.

Generate DS records

# dnssec-dsfromkey Kdnssec.demo.dotat.at.+005+61981.key

dnssec.demo.dotat.at. IN DS 61981 5 1 C5A83CE7E75CBB435691A370703C959641B98A2E

dnssec.demo.dotat.at. IN DS 61981 5 2 08B0D66C27D22487B25BFF9B728CEE11D9F47E0CAEEC55AA45991550C4197BE9

I also need to add a DS record into the zone’s parent. First I generate the DS record.

Publish DS records

$ ssh black

$ nsupdate -l

> update add dnssec.demo.dotat.at. 3600 IN DS 61981 5 1 C5A83CE7E75CBB435691A370703C959641B98A2E

> send

Now I need to switch to the name server for the parent zone and add a DS record. Iam going to do a dynamic update, but normally you would use a registrar web page orAPI as when updating your delegation NS records.

I need to remember to include the update add command and a TTL.

Secure validation


# rndc flush

# dig dnssec.demo.dotat.at

; <<>> DiG 9.9.5 <<>> dnssec.demo.dotat.at


;; Got answer:



Now if I switch back to my recursive server I can flush any stale records then make itvalidate the zone, with an AD flag in the response.

Demo – signing

...end

26

7 Closing remarks

Caveat emptor

Although I have tried to give an optimistic picture of DNSSEC, there are still someobstacles to its deployment.

DNSSEC data is a lot larger than plain DNS data. A lot of the problems come fromthe fact that this means reply packets are a lot larger.

The extension mechanism for the DNS, called EDNS0 [4] allows DNS over UDP touse packets larger than 512 bytes without triggering fallback to TCP.

In fact EDNS0 allows (in fact encourages) servers to use UDP packets that are largerthan the network’s MTU. These large packets have to be fragmented.

Unfortunately misconfigured firewalls often block DNS packets larger than 512 bytes,and DNS over TCP, and IP fragments. This can cause problems with resolving signedzones.

This problem does not just occur if the broken firewall is in front of a validator. Mostrecursive DNS servers will send queries stating that they understand DNSSEC even ifthey aren’t validating. (This includes Microsoft Windows as well as BIND and Unboundon Unix.) So authoritative servers will send them large signed responses [13].

This problem is much more common – practically pervasive – at the edge of thenetwork, between client machines and recursive servers. It is still very early days foractive validation on client machines, so the solutions to this problem are still somewhatimmature.

One example is dnssec-trigger [11] which can fall back to DNS-over-TLS to a knowngood recursive server if the local network is particularly opaque.

Poised for take-off?

So my aim was to give you some idea of why DNSSEC works the way it does and whyit is important. And I hope I have demonstrated that the tools are getting fairly easy touse. So go and deploy DNSSEC!

27

References

[1] Ray Bellis. DNS RFC dependency graphs, May 2010. http://blog.nominet.org.uk/tech/2010/05/24/436/.

[2] Steven M. Bellovin. Using the domain name system for system break-ins. In5th USENIX UNIX Security Symposium, June 1995. https://www.usenix.org/

legacy/publications/library/proceedings/security95/bellovin.html.

[3] Daniel J. Bernstein. djbdns, December 1999. http://cr.yp.to/djbdns.html.

[4] Joao Damas, Michael Graff, and Paul Vixie. Extension mechanisms for DNS(EDNS0), April 2013. http://tools.ietf.org/html/rfc6891.

[5] Casey Deccio. Dnsviz.net. http://dnsviz.net/d/black.csi.cam.ac.uk/dnssec/.

[6] Robert Elz and Randy Bush. RFC 2181: Clarifications to the DNS specification,July 1997. http://tools.ietf.org/html/rfc2181.

[7] R. (Miek) Gieben and W. (Matthijs) Mekking. RFC 7129: Authenticated denial ofexistence in the DNS, February 2014. http://tools.ietf.org/html/rfc7129.

[8] Bert Hubert. DNSSEC deployment graph. https://xs.powerdns.com/

dnssec-nl-graph/.

[9] ICANN. DNSSEC deployment graph. http://www.icann.org/en/news/in-focus/dnssec/deployment-graph.

[10] International Organization for Standardization. Iso 8601: Data elements and in-terchange formats – information interchange – representation of dates and times,December 2004. http://dotat.at/tmp/ISO 8601-2004 E.pdf.

[11] NLnetLabs. dnssec-trigger. https://www.nlnetlabs.nl/projects/

dnssec-trigger/.

[12] CERT Polska. Large-scale dns redirection on home routers for financial theft, Febru-ary 2014. https://www.cert.pl/news/8019/langswitch lang/en.

[13] Roland van Rijswijk. Dnssec: what every sysadmin should be doing to keep thingsworking. In USENIX LISA ’12: 26th large installation system administrationconference, December 2012. https://www.usenix.org/conference/lisa12/

dnssec-what-every-sysadmin-should-be-doing-keep-things-working.

[14] Wietse Venema. TCP wrapper: network monitoring, access control, and booby traps.In USENIX UNIX Security Symposium III, September 1992. https://www.usenix.org/legacy/publications/library/proceedings/sec92/.

[15] Paul Vixie. Why you should deploy DNSSEC, August 2008. http://www.dnssec.

net/why-deploy-dnssec.

[16] Wikipedia. Dan Kaminsky. http://en.wikipedia.org/wiki/Dan Kaminsky.

28

introduction to dnssec: principles and practicepeople.ds.cam.ac.uk/fanf2/dns/nws42/notes.pdf ·...

Documents