DNSSEC

Kyle Rankin

http://greenfly.org/talks/security/dnssec.html

A heavily RFC-based talk.

It's not that hard, just a lot of documents.

How DNS Works

1' job: hostname -> IP address

Client sends request to lcoal DNS server
What is the IP for www.greenfly.org?
DNS server starts recursive query
To play at home: gid +trace www.greenfly.org
// a recursive trace
// run it against your own domain (more familiar), helpful when you see it
yourself

Tracing a recursive query

1. ns1.someisp.com to root:www.greenfly.org?
request goes to ns1.someisp.com which goes to root DNS server.
2. root to someisp.com to root:www.greenfly.org?
the root levels, odn't know your website, only top levels (org, net etc). Go
talk to ...
3 someisp.com to org: www.greenfly.org
4. org to ns1.someisp.com: no clue, bu ns1.greenfly.org and ns2.greenfly.org know
about it. Here are their addresses...

5. ns1.someisp.com to ns2.greenfly.org: www.greenfly.org?

ns2.greenfly.org to ns1.someisp.com: <ip address>

6.
7.

(see slides)

DNS Security Issues

DNS designed to be an open, friendly service // expectation then was no one would
do anything wrong
DNS queries and responses are not encrypted
Domainnames sometimes look alike (google.com vs googIe.com)
depending on the font you use, you might be victim of a fishing email
Companies can't always register their name on all TLDs (artemis.com vs artemis.net)
user will type artemis.com and could be a security issue (unintended site)
Many DNS serveres (open resolvers) will perform recursive queries for anyone who
asks
recently, DNS amplification attacks, send a tiny query for isc.org records,
huge response (sample)
DNS goes over UDP, so possible to spoof
send DNS attack to open DNS resolver
sends gigantic reply to target
use 1000 open resolvers, ouch! (tiny bw to exec)
Open resolvers heavily used in modoern DNS amplication DDOS attacks.
DNS subject to MitM attacks (coffee shops, send UDP request out, inject
bankofthewest.com to a shady ip)
DNS spoofing/cache poisoning attacks.
poison an ISPs name web server & change the cache for a banks ip to be
something else

DNSSEC addresses the last two. The others are...

How DNSSEC works

Some similarities with a CA system
Uses public-key cryptography to sign every DNS record for a zone
Root DNS servers have key pair, DNSSEC-enabled
DNSSEC-enabled TLDs get key singatures signed, published by root DNS
onboard a TLD into DNS sec, gets a public key, do back channel validation of
each other, then root takes it and signs it

DNSSEC-enabled zones get key sinngatures signed, bpulicsed by TLD (need to get them
signed and published by their org servers)

DNSSEC_caapable resolveres anchor trust in root DNS keys (they implicitly trust
each other... they org trusts root, DNS servers trust org, etc to validate the
entire chain)

WHen DNSSEC record resolve, chain of trust is followed.

If record tampered with, signature won't match (impossible to spoof because they
dont' have your private key)

If record doesn't exist, absence is also signed (you cannot just inject a record if
name server doesn't have it, it will sign the record is absent also)

Trust Graphigh for www.google.com

root (.) has a DNSKEY (KSK), com has a key, trian of trust goes from . to com to
google

Terms

RR - Resource Record: smalles unit of data in a zone (A, NS...)

RRSET - COmplete set of resource records (all NS records or A recrods for a name)
KSK - Key-signing Key. Signs DNSKEY records in a zone. (all it does, to sign those
keys)
ZSK - zone signing key. SIgns all of th other records in a zone
SEP - secure entry point. Flag set in key to denote it as a KSK
Separate KSK, ZSK not required, but best practice
Allows larger KSK, easier rotation of ZSKs (when u gen a KSK, u also gen a public
record you share up, any time you change your KSK, you'd have to share that up, but
ZSKs you can change anytime you want, rotate it every month, that way you don't
havae to talk to your ZSK every mo to get them to sync up).

// share public key w your parent and in your own zone (ZSKs have them in
your own zone so you share them there too, that's the only one you make public)

// ensure you keep the public key private or you can be exploited!!!

DNSKEY - A public key for the zone, either KSK or ZSK

 why trust the public key? b/c I trust org, which trusts root.

RRSIG - Recource REcord Signature, contains a signature for an RRSET

published the sig as a record combined. Why put a www a records together?
So you can't slip another A record in there

NSEC - Next SEcure, used in "negative answers" to prove whether a name exists or
not

NSEC3 - Next Secure (v3). Like NSEC, protects against "zone walking". NSEC flaw
let you walk the entire zone to know the records existed, even if you don't know
their contents, DNS is open, shouldn't nec treat them as secret, but some ppl do

DS - Delegation Signer. Contains KSK signature & submitted 2 zone parent as part
of chain of trust (this si the rec you send up that they sign & publish etc)

DLV - DNSSEC Look-aside Validation. Much like DS records, used when DS records not
supported. Your avg com net or org today, u want to enable DNSSEC, there may be 3-
4 registrars in the US that could shared DNSSEC if you want (GoDaddy charges $30/mo
extra) and a few others. Need some kind of cert that you are the administrator,
lets you have a diff root of trust (other name server that will sign my zone, ISC
is the primary, DLV.ISC.ORG is the site. BIND lets you implicitly trust DLV.ISC.ORG

Work-around solution until DNSSEC is fully adopted by TLDs

Or if a resitrrat dn sppt DNSSEC
Changes trust anchor from root to a 3rd party liek dlv.isc.org
Reqs DNS resolvers to add/trust thrid party keys

// use dlv.isc.org if you cannot use the resource records directly for
some reason

Trust Graph for www.greenfly.org

root (.) trusted by org ((dark keys are KSK, light keys are ZSK, sometimes you have
multiples)
dlv.isc.org (KDK, ZSK, and your record you pub & send to them)

(web site that gens these has a legend)

Implementing DNSSEC

Not that bad. Even easier ways to maintain now.

Create KSK and ZSK

$ dnssec-keygen -a RSASHA1 -b 2048 -n ZONE -f KSK greenfly.org
$ dnssec-keygen -a RSASHA1 -b 1024 -n ZONE greenfly.org

// 2nd one generates the key

INclude refs to keys in zone file (db.greenfly.org):

$INCLUDE Kgreenfly.org.+005+10849.key ; KSK
$INCLUDE Kgreenfly.org.+005+58317.key ; ZSK

Sign the zone using KSK and ZSK

dnssec-signzone -o greenfly.org -k Kgreenfly.org.+005+10849 \ db.greenfly.org
Kgreenfly.org.+005+58317

Or if using DLV:
...

dnssec-signzone -l dlv.isc.org ...

Config bind to use signed zone:

zone "greenfly.org" {
type master;
file "/etc/binddb.greenfly.org.signed";
allow-transfer {slaves; } ;
};

Enable DNSSEC in BIND masters and slaves

options {
dnssec-enabled yes;
dnssec-validation yes;
};

To validate DLV zones, add addiitional BIND option and trusted key
options { dnssec-lookaside . trust-anchor dlv.isc.org.; };
trusted-keys {
dlv.isc.org. 257 3 5 "BEAAAAPHMu//5onzrEE7z1egmhz/WPO0+juoZrW
};

// useful if you want to run this thing internally only and don't want to send it
to the outside world to get it signed

// sounds like a CA system, can you use it to replace a CA system? (some CAs are
really upset about this)

// OPENSSL vs BIND broken? uses OPenSSL on the back end

dig +dnssec www.greenfly.org

// tells resolver to enable dnssec and try to validate the chain of trust

// flags: qr aa rd ra;
// aa = it is itself saying "I'm fine"
// there is a diff flag, ad, that signifies that DNS was validate (query someone
except that name server and tell them to do a recursive query).

only 1 a record for www.greenfly.org

you can see the key further down on the RRSIG

NS reecords (1 RRSIGN for both NS records, 1 set, 1 sig that applies to both)

DNSSEC Deployed at root zone on July 15, 2010

463 TOtal TLDs in root zone

271 TLDs are signed
265 TLDs have trust anchors published as DS records in the root zone
4 TLDs (.ee, .kg, .th, .ua) also have trust anchors published in the ISC DLV
Repository)
// presuming 4 early adopters who wanted it b4 top level servers were ready)

DANE (DNS-based Authentication of Named Entities) proposed on top of DNSSEC

Defined in RFC 6698
DANE authenticates TLS w.o CAs using DNSSEC-signed keys
Shifts the trust from the CAs to root DNS, TLDs, and DNS admin

Prolbem with CA system, u have to implicitly trust them all. In this case, instead
of trusting all these guys, you can kick out some (13 root name servers no matter
what happens). Now, what are you going to do? DANE causes you to trust fewer
entities in a way you can't revoke them every. An alternative is proposed to let
you invoke and revoke trust by entity. (more decentralized).

?: We sitll have to trust the core root implicitly (up, but not secure). Not to
lie to me. That's what the CA system is for, puts trust in 1 entity, the DNS
system itself.

A lot of trust in 1 entity. People put effort in how to break that.

If you want to test it: Chrome since 2011, add on for firefox.

see slides for RFCs

Why is sep KSK & ZSK a goog practice? (4641)

dnsviz.net is how he generated the trust graphs.

Implicitly trust: how do we ensure the top end is secure to begin with. HOw do we
trust the root zones before we trust them (w/o having Dan Kaminsky showing his
key). Download from bind from