DNSSEC - The Domain Name System
Security Extensions
Applications & Protocols
Daniel Haslinger
DNS
▪ DNS itself has security built-in
▪ Unfortunately we have not enough security for todays requirements
▪ No cryptography
▪ 16 Bit transaction numbers
▪ MITM or Cache Poisoning Attacks are possible
DNS
▪ ATTACK #1: DNS Cache Poisoning:
▪ Attacker queries a recursive name server for an IP address in a zone
under the control of the attacker
▪ Recursive server does not have any information on the
zone and starts the recursion  he queries the malicious
DNS resolver
▪ The malicious resolver provides the requested rogue IP address
and also includes rogue IP addresses to additional sites (example:
www.fhstp.ac.at)
▪ The recursive server caches the rogue information from the
additional section.
▪ A user queries the recursive server for www.fhstp.ac.at
▪ The name server delivers the cached rogue IP address.
DNS
▪ ATTACK #2: MITM Attack
▪ Attacker intercepts the connection between Client and Resolver
using ARP Spoofing (or any other form of MITM)
▪ The client requests a valid A record (e.g. www.fhstp.ac.at)
▪ The attacker intercepts the answer from the server and changes
the IP address to a rogue IP.
DNS
▪ ATTACK #3: Blind response using Birthday Paradox
▪ The first answer to a request containing the correct transaction ID, wins.
▪ The entropy for transaction IDs is 16
▪ According to the birthday paradox, an attacker only needs 2 ˆ N / 2 tries
on average to generate a valid forged response that matches the request.
▪ As long as the forged reply arrives first at the requesting host – it will poison
the cache.
▪ Birthday paradox? Let’s test it:
▪ >= 23 People: > 50%
▪ >= 50 People: > 97%
DNS
▪ ATTACK #4: Kaminsky Attack
▪ In short:
A DNS Cache poisoning attack that poisons NS records of the parent
zone in order to redirect the whole zone to a rogue DNS server.
DNS
▪ ATTACK #4: Traffic Amplification
▪ Attacker requests a TXT from a zone that is hosted by a DNS server with
high bandwidth.
▪ The request has a forged sender IP, which is the IP of the desired victim that
has a lower bandwidth than the DNS server.
▪ The DNS server answers to the forged sender IP – containing the TXT
record which is longer (in bytes) than the query.
▪ The attacker amplified his bandwidth since actually started a transmission of
more data to the victim than he had to send using his own connection.
DNSSEC
▪ DNSSEC to the rescue
▪ Digitally signed resource records
▪ Digital signatures based on asymmetric cryptography
▪ Public Key goes into a special RR inside the zone
▪ Private Key is used for actually signing the records
▪ An attacker can still modify replies or send spoofed answers,
but he is not able to sign this answer in a valid way without
possessing the private key!
DNSSEC
▪ DNSSEC embedded into the "Security BIG-3":
▪ CONFIDENTIALITY
(nope)
▪ INTEGRITY
(yes)
▪ AVAILABILITY
(nope)
▪ An attacker can still modify replies or send spoofed answers,
but he is not able to sign this answer in a valid way without
possessing the private key!
DNSSEC
▪ What do we need?
▪ New resource records  RFC 4034, RFC 5155
▪ RRSIG
Signature of the resource record
▪ DNSKEY
Public key
▪ NSEC
Next owner (name) and RR type of the NSEC owner
▪ NSEC3
Hash of the next owner
▪ DS
Delegation Signer – DNSKEY Digest of a child zone
DNSSEC
▪ The problem with hierarchies
▪ DNS is managed in a hierarchical manner
▪ The parent zone always points to a child zone
▪ At minimum, a parent needs an NS resource record
▪ Sometimes, also an A resource records is needed (GLUE)
▪ So if an attacker is able to modify one of these
resource records stored in the parent zone,
signatures are worthless…....
DNSSEC
▪ The problem with hierarchies & key renewal
▪ To protect the system from such modifications,
a DS (Delegation Signer) record was introduced
▪ When a query is performed, both – the NS and the DS
records are retrieved for verification.
▪ With enough computational power, cracking the key is
just a matter of time
▪ Therefore, you should renew your keys on a regular basis
▪ Everytime you renew your key, you have to request a change
of your DS RR in the parent zone
▪
... Thats pretty annoying ...
DNSSEC
▪ Key renewal
▪ The solution: TWO Key pairs!
▪ ZSK
Zone Signing Key
( short key size )
▪ KSK
Key Signing Key
( strong key size )
▪ The zone RRs are signed using the ZSK
▪ The keys are signed with the KSK
▪ The DS of KSK is stored within the parent zone
DNSSEC
▪ How to configure DNSSEC in BIND (9)
▪ First you activate DNSSEC in options:
dnssec-enable yes;
▪ Then you create a KSK keypair (in this example for the tld zone „foo“)
dnssec-keygen –r /dev/urandom –a RSASHA1 –b 4096 –n ZONE –f KSK foo
▪ As a next step, you create a ZSK keypair
dnssec-keygen –r /dev/urandom –a RSASHA1 –b 1024 –n ZONE foo
▪ For each keypair, you will get 2 files:
▪ .key
Public Key, already formatted as RR
▪ .private Private Key. KEEP IT SECRET!
DNSSEC
▪ How to configure DNSSEC in BIND (9)
▪ Next, you copy the public keys into your zone file ...
cat *.key >> foo
▪ ... and then sign the zone using your private keys
dnssec-signzone –o <origin> -k <KSK-file> -N unixtime <zone file> <ZSK-file>
▪ This will create a new zone file: foo.signed
▪ ... and another file containing the DS record: dsset-foo
DNSSEC
▪ How to configure DNSSEC in BIND (9)
▪ A DNS Server needs a trust anchor in order to check
zones for validity.
▪ This trust anchor is usually the public key of the
root zone.
▪ Configure the trust anchor into options:
trusted-keys { . 257 3 5 „AwEAAZkX...[SNIP]...7OTYVByqh8=„; };
DNSSEC
▪ How to configure DNSSEC in BIND (9)
▪ To test your configuration, start a DNS query:
▪ dig +dnssec @<server-ip> foo any
▪ Did it work? Great! Now change your zonefile without refreshing
your signatures and try again. The answer you should get is SERVFAIL.
DNSSEC
▪ So what does actually happen?
▪ Each RR (except for RRSIG) entry gets a corresponding RRSIG entry
that contains the following information:
▪ Name, TTL, Class, Type
( all these are DNS Standard )
▪ Algorithm
▪ Number of name components
▪ RR-TTL at time of signing
▪ Expiry Date
▪ Start Date
▪ Unique Number / Key ID
▪ Name of the zone
▪ Actual signature
DNSSEC
▪ So what does actually happen?
▪ Each RR (except for RRSIG) entry gets a corresponding RRSIG entry
that contains the following information:
▪ Example:
3600
IN RRSIG
SOA 8 2 3600 20160431150000 (
20160415133515 31560 foo.bar. AAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= )
DNSSEC
▪ So what does actually happen?
▪ Two DNSKEY entries are added, that contain:
▪ Name, TTL, Class, Type
(all these are DNS Standard)
▪ Flags
(256: ZSK, 257: KSK)
▪ Protocol
(1=TLS, 2=Mail, 3=DNSSEC, 4=IPSEC, 255=any)
▪ Algorithm
▪ Actual Key
▪ Key ID
DNSSEC
▪ So what does actually happen?
▪ Two DNSKEY entries are added
▪ Example:
▪
3600
IN DNSKEY 256 3 8 (
Asfdj4Q5kj54349ipfja45jiorJerljf4kf
lkf59jgeP3itjigjl2r4p2pofifw45924jf
) ; key id = 31560
▪
3600
IN DNSKEY 257 3 8 (
jj4308orjseiojrtp394hwuireww34q0fas
vz4q49z5ga9w4632UGREjlgdrlejtj44ioj
038457fnDH594jtwrgpgjJPGOErj3ip5j4i
5i94Pg590g5gpegjsERGKh2t49jiorsgwjr
) ; key id = 29950
DNSSEC
▪ So what does actually happen?
▪ The ZSK DNSKEY RRs (256) also get their respective RRSIG entries –
they are signed using the KSK
▪ A DS record is placed into the parent zone. It contains a hash of the
KSK that resides in the child zone.
DNSSEC
▪ So what does actually happen?
▪ When a query for e.g. an A record is performed against the DNS Server
it delivers the A record and the corresponding RRSIG.
▪ The client can retrieve the ZSK in order to validate that the A record
matches the RRSIG.
▪ To validate that the ZSK was not manipulated, it retrieves the RRSIG of
the ZSK and checks if they correspond to the KSK.
▪ But who guarantees that the KSK was not manipulated?
DNSSEC
▪ So what does actually happen?
▪ The designated signer within the parent zone.
▪ To prove that the KSK is correct, a hash is created and checked against
the hash found in the DS record of the parent zone.
▪ But how is the parent DS record secured?
DNSSEC
▪ So what does actually happen?
▪ The DS record in the parent zone has its own RRSIG, created using the
ZSK of the parent zone, which itself is protected by an RRSIG created
using the KSK of the parent zone, of which we find the corresponding
hash within the DS record of the parents parent zone ...
▪ After we wrapped our head around that, we end up at the root zone.
▪ The root zone is also secured the same way – but where goes
the DS record?
DNSSEC
▪ So what does actually happen?
▪ A trust anchor is what we need.
▪ trust anchors are pre-installed into your operating system and
may also be downloaded / refreshed directly from IANAs website or
using software update facilities that come with your OS.
DNSSEC
▪ And what about „holes“ ?
▪ What happens if you ask for a record that does not actually exist?
DNSSEC
▪ And what about „holes“ ?
▪ What happens if you ask for a record that does not actually exist?
▪ You get an NXDOMAIN reply. But where comes the signature from?
DNSSEC
▪ And what about „holes“ ?
▪ What happens if you ask for a record that does not actually exist?
▪ You get an NXDOMAIN reply. But where comes the signature from?
▪ Yup. Trick question. There IS no signature since we have no data to
sign.
▪ Therefore – we have to introduce another resource record:
▪ NSEC
DNSSEC
▪ NSEC
▪ NSEC records are chaining resource records together in alphabetical
order.
▪ Example:
▪ mail.foo.bar.
IN NSEC
printing.foo.bar.
▪ printing.foo.bar
IN NSEC
shop.foo.bar.
▪ shop.foo.bar
IN NSEC
www.foo.bar.
▪ www.foo.bar.
IN NSEC
mail.foo.bar.
DNSSEC
▪ NSEC
▪ If an non-existent record is requested, the server answers with
the NSEC record that „covers the hole“ you tapped into:
▪ Example:
▪ mail.foo.bar.
IN NSEC
printing.foo.bar.
▪ printing.foo.bar
IN NSEC
shop.foo.bar.
▪ shop.foo.bar
IN NSEC
www.foo.bar.
▪ www.foo.bar.
IN NSEC
mail.foo.bar.
▪ Query:
missing.foo.bar
▪ Answer:
mail.foo.bar.
IN NSEC
printing.foo.bar.
DNSSEC
▪ NSEC
▪ Since NSEC records are resource records like all the other records we
discussed – they also get their corresponding RRSIG entries – so they
are digitally signed.
▪ Congratulations – you signed a „nothing“ ☺
▪ But ... do you smell the trouble in there?
DNSSEC
▪ NSEC
▪ Zone walking by design 
▪ Since all NSEC records are connected to each other, an attacker has a
great time when it comes to reconnaissance!
▪ Just request a non-existing record to get an NSEC entry and request
the NSEC entry it points to – and follow this procedure.
▪ You‘ll end up with all records and basically accomplished an
unauthorized zone transfer.
▪ That‘s bad ... really bad.
DNSSEC
▪ NSEC3
▪ To mitigate this, NSEC3 has been specified.
▪ Instead of replying with the next element in clear text, it responds with a
hashed version.
▪ The client can validate this answer, together with the RRSIG of the
NSEC3 record, while at the same time he does not know where the
record points to, since it is hashed.
DNSSEC
▪ Is all this possible with Standard DNS?
▪ No. 512 bytes (udp) are not enough for keys and signatures.
▪ DNSSEC uses „EDNS“ (Extension Mechanisms for DNS) in
order to do its job.
DNSSEC
▪ EDNS
▪ EDNS Introduces a new resource record named „OPT“, but
you won‘t find it within a zone file.
▪ An EDNS compatible client will ask for a standard record and
additionally ask for an OPT record named <integer>.
▪ The integer is the number of bytes the client accepts via UDP, for
example asking for the record „OPT 8000“ tells the server that the client
will happily accept UDP packets up to a size of 8 KB.
▪ The server will reply with an integer, stating what he is able to send by
design. Both then agree on the lower integer.
DNSSEC
▪ SO....
▪ We sign successful answers ... and we sign empty answers
▪ Everything can be checked for validity
▪ ... it there still an attack to consider?
DNSSEC
▪ Traffic Amplification gone mad
▪ The traffic amplification attack now works better than ever.
▪ Attackers get an extreme bandwidth boost through the keys and
signatures we now deliver inside our answers!
DNSSEC
▪ Zone file format (unsigned)
▪ foo.bar.
3600
IN SOA
ns1.upstream.com. (
2016041306
7200
540
604800
86400
)
▪
3600
IN NS
ns1.upstream.com.
▪
3600
IN NS
ns1.upstream.com.
▪
3600
IN A
123.10.10.1
▪ www
3600
IN A
123.10.10.1
▪
3600
IN MX
10
123.10.20.50
▪
3600
IN MX
20
123.10.20.51
; serial
; refresh
; retry
; expire
; min
DNSSEC
▪ Zone file format (signed)
▪ foo.bar.
▪
3600
3600
IN SOA
IN RRSIG
ns1.upstream.com. (
2016041306
7200
540
604800
86400
)
; serial
; refresh
; retry
; expire
; min
SOA 8 2 3600 20160431150000 (
20160415133515 31560 foo.bar. AAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= )
▪
3600
IN NS
ns1.upstream.com.
▪
3600
IN RRSIG
NS 8 2 3600 20160431150000 (
20160415133515 31560 foo.bar. BBBBB
DNSSEC
▪ Zone file format (signed)
▪ [...]
▪
3600
IN DNSKEY 256 3 8 (
Asfdj4Q5kj54349ipfja45jiorJerljf4kf
lkf59jgeP3itjigjl2r4p2pofifw45924jf
) ; key id = 31560
▪
3600
IN DNSKEY 257 3 8 (
jj4308orjseiojrtp394hwuireww34q0fas
vz4q49z5ga9w4632UGREjlgdrlejtj44ioj
038457fnDH594jtwrgpgjJPGOErj3ip5j4i
5i94Pg590g5gpegjsERGKh2t49jiorsgwjr
) ; key id = 29950
▪
3600
IN RRSIG
DNSKEY 8 2 3600 20160431150000 (
20160415133515 31560 foo.bar.
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC= )