DNSSEC signing Tutorial

© Men & Mice http://menandmice.com
DNSSEC signing tutorial
1

© Men & Mice http://menandmice.com  
© ISC http://www.isc.org
Agenda
Why DNSSEC
Decisions:
Algorithm
key-size
NSEC(3)
DNSSEC with BIND 9
DNSSEC with Knot
2

DNSSEC
"One Key to rule them all,
one Key to find them,
one Key to bring them all
and in the Resolver bind them."
—Modified from Lord of the Rings
Miek Gieben.
3

DNSSEC Does and Does Not...
DNSSEC signs data to guarantee authenticity and
integrity.
It assures a client that a RRSet is from the proper
authoritative server and has not changed.
DNSSEC does not encrypt data to provide privacy.
Anyone can find out the RRSets you request.
4

Why DNSSEC
Protects DNS data
against cache spoofing
against "Man in the Middle" (MITM) attacks
against take-over of authoritative server
against rogue secondaries
Protects DNS server
against denial of service attacks (in the near future)
5

Why DNSSEC
Enables new functions
Mail transport security (SMTP/TLSA)
Mail end-to-end encryption (OPENPGPKEY/SMIMEA)
opportunistic IPSec encryption (IPSECKEY)
SSH server authentication (SSHFP)
x509 Certification Authority Authorisation (CAA)
6

DNS Security Extensions
DNSSEC deployment
7
http://www.internetsociety.org/deploy360/dnssec/maps 
http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains

DNSSEC Fundamentals
8

9
RRSet
(plain
DNS data)
hash
finger-
print
RRSIG
encrypt with
private key k
Zonefile
authoritative
server
resolving/validating
server
parent
zone
DNSSEC in a Nutshell

10
RRSet
(plain
DNS data)
hash
finger-
print
RRSIG
encrypt with
private key k
Zonefile
RRSet
RRSIG
authoritative
server
server
DNSKEY 
(public key)
parent
zone
DNSSEC in a Nutshell (DS RR Added)

11
RRSet
(plain
DNS data)
hash
finger-
print
RRSIG
encrypt with
private key k
Zonefile
RRSet
RRSIG
authoritative
server
server
DNSKEY 
(public key)
parent
zone
DS record
hash

12
RRSet
(plain
DNS data)
hash
finger-
print
RRSIG
encrypt with
private key k
Zonefile
RRSet
RRSIG
authoritative
server
server
DNSKEY 
(public key)
RRSet
RRSIG
decrypt with
public key k
finger-
print
parent
zone
DS record
hash

13
RRSet
(plain
DNS data)
hash
finger-
print
RRSIG
encrypt with
private key k
Zonefile
RRSet
RRSIG
authoritative
server
server
DNSKEY 
(public key)
RRSet
RRSIG
decrypt with
public key k
finger-
print
parent
zone
DS record
hash verify

14
RRSet
(plain
DNS data)
hash
finger-
print
RRSIG
encrypt with
private key k
Zonefile
RRSet
RRSIG
authoritative
server
server
DNSKEY 
(public key)
RRSet
RRSIG
decrypt with
public key k
finger-
print
hash
finger-
printcompare
parent
zone
DS record
hash

DNS Servers for DNSSEC
•BIND 9.6 and up: Authoritative server and validating resolver
•NSD from NlNetLabs: Fast authoritative server
•Windows 2012/2016 DNS Server: Authoritative server and validating
resolver with a GUI
•PowerDNS: Authoritative DNS Server with many backends, including
SQL Databases
•Knot-DNS: fast authoritative DNS Server with DNSSEC key-rollover
automation
15

DNSSEC Keys Fundamentals
16

DNSSEC Key Algorithms
RSAMD5 (deprecated, not implemented)
RSASHA1 (not recommended anymore)
RSASHA256 (recommended)
RSASHA512 (large keys)
DSA (slow validation, no extra security)
ECC-GOST (used in Russia)
ECDSA (small signatures and keys, fast crypto, recommended)
ED25519 (Curve developed by Dan "djb" Bernstein,  
https://ed25519.cr.yp.to/)
ED448 (448-bit Edwards curve with a 223-bit conjectured security level)
17

DNSSEC Signing Algorithms
18
Number Algorithm Mnemonic
1 RSA/MD5 (deprecated) RSAMD5
5 RSA/SHA-1 RSASHA1
6 DSA-NSEC3-SHA1 DSA-NSEC3-SHA1
7 RSASHA1-NSEC3-SHA1 RSASHA1-NSEC3-SHA1
8 RSA/SHA-256 RSASHA256
10 RSA/SHA-512 RSASHA512
12 GOST R 34.10-2001 ECC-GOST
13 ECDSA Curve P-256 with SHA-256 ECDSAP256SHA256
14 ECDSA Curve P-384 with SHA-384 ECDSAP384SHA384
15 Ed25519 ED25519
16 Ed448 ED448
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

ECDSA vs. RSA in .COM
19
https://schd.ws/hosted_files/icann58copenhagen2017/b9/Roland%20Van%20Rijswijk-Surfnet-ECDSA%20Adoption%20in%20DNSSEC.pdf

Key Size for RSA algorithms
20

Key Sizes (for RSASHA256)
be aware of DNS packet size limits  
(IPv6 fragmentation issues discussed below)
Recommendations:
RFC 6781: 1024 bits
BIND 9 default: KSK - 2048 bits, ZSK - 1024 bits
mildly paranoid: KSK - 2560 bits, ZSK - 1536 bits
truly paranoid: KSK - 4096 bits, ZSK - 2048 bits
21

RSA-Key Size
Modern cryptanalysis finds RSA keys less than 700
bits breakable.
2012 calculations indicate that 1024bit RSASHA1
keys may be broken within 5 years.
It is recommended to move away from SHA1.
SHA256 or SHA512 with 2048bit keys will be safe
for decades based on current cryptanalysis.
22

RSA-Key Length Impact
A larger key significantly increases the computing
resources to sign a zone and to validate the RRSets.
Remember that the validation will be done in real time.
Doubling the key size in bits increases the time:
To create signatures (signing) by a factor of 8.
To validate a signature by a factor of 4.
Every extra bit in a key doubles the amount of work for
an attacker to brute-force crack the key!
23

Key Size in BIND
Only sign the DNSKEY resource record set (RRSet)
with the Key-Signing-Key to reduce the size of the
DNSKEY answer:
options { 
[…] 
dnssec-dnskey-kskonly yes; 
};
24

IPv6 and Fragmentation
As designed in 1983, DNS had a 512-Byte payload
limit over UDP.
The limitation was raised to 4096B with EDNS0,
RFC 2671(1999-08) and RFC 6891(2013-04).
UDP/DNS answers>1280B may fragment
IPv6 fragmentation is broken in the Internet:  
RFC 7872 - "Observations on the Dropping of Packets with
IPv6 Extension Headers in the Real World" 
https://www.rfc-editor.org/rfc/rfc7872.txt
25

NSEC vs. NSEC3 (vs. NSEC5)
26

authenticated denial of existence
DNSSEC provides multiple implementations of
"authenticated denial of existence"
a way to proof negative answers from DNS
each implementation has its pros and cons
if in doubt, choose NSEC
27

authenticated denial of existence
28
Implementation Pros Cons
NSEC
fast
human debug-able
allows zone walking
NSEC3
makes zone walking
harder
requires hash operations
for every negative answer
slow(er)
NSEC5 prevents zone walking
Internet draft, not
available at this time

Tutorial
29

DNSSEC signing
in this tutorial we will use
ECDSA256P256 and NSEC3 with BIND 9.10
RSASHA256 and NSEC with Knot 2.4.1
template files for this tutorial can be found in 
 
https://github.com/menandmice-services/dnssec-signing-tutorial
30

BIND 9
31

BIND configuration
32
options {
directory "/var/named";
key-directory "keys";
recursion no;
dnssec-enable yes;
};
logging {
channel named { file "named.log" versions 10 size 20M; print-time yes; print-category yes; };
channel security { file "security.log" versions 10 size 20M; print-time yes; };
channel query_log { file "query.log" versions 10 size 20M; severity debug; print-time yes; };
channel query_error { file "query-errors.log" versions 10 size 20M; severity info; print-time yes; };
channel transfer { file "transfer.log" versions 10 size 10M; print-time yes; };
category default { default_syslog; named; };
category general { default_syslog; named; };
category security { security; };
category queries { query_log; };
category config { named; };
category xfer-in { transfer; };
category xfer-out { transfer; };
category notify { transfer; };
};
zone "dnssec.example.com" {
type master;
file "dnssec.example.com";
inline-signing yes;
auto-dnssec maintain;
};
global
configuration
logging
zone
definition

Zonefile "dnssec.example.com"
33
$TTL 3600
@ IN SOA ns1 hostmaster 1001 2h 30m 41d 30m
IN NS ns1
IN NS ns2
IN TXT "Zone for DNSSEC signing tutorial"
ns1 IN A 192.0.2.53
ns2 IN A 192.0.2.153
www IN A 192.0.2.80
IN AAAA 2001:db8:100::80

Test the unsigned zone
34
# dig @localhost dnssec.example.com soa +dnssec
; <<>> DiG 9.10.4-P6-RedHat-9.10.4-4.P6.fc25 <<>> @localhost dnssec.example.com soa +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dnssec.example.com. IN SOA
;; ANSWER SECTION:
dnssec.example.com. 3600 IN SOA ns1.dnssec.example.com. hostmaster.dnssec.example.com. 1001 7200 1800 3542400 1800
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Mar 23 09:07:21 CET 2017
;; MSG SIZE rcvd: 98

Generating the DNSSEC keys
35
# mkdir /var/named/keys
# chown named /var/named/keys
# dnssec-keygen -a ECDSAP256SHA256 -K /var/named/keys/ -n ZONE dnssec.example.com
Generating key pair.
Kdnssec.example.com.+013+22834
# dnssec-keygen -f KSK -a ECDSAP256SHA256 -K /var/named/keys/ -n ZONE dnssec.example.com
Generating key pair.
Kdnssec.example.com.+013+38320
# chown named /var/named/keys/*
ZSK
directory for
keys
KSK
adjust permissions, the BIND process
must be able to read the key files

signing the zone
36
# rndc sign dnssec.example.com
# rndc signing -nsec3param 1 0 100 A5F7B1CD dnssec.example.com
request queued
# journalctl -eu named | tail
Mar 23 09:09:58 named[2175]: received control channel command 'sign'
Mar 23 09:09:58 named[2175]: zone dnssec.example.com/IN (signed): reconfiguring zone keys
Mar 23 09:09:58 named[2175]: zone dnssec.example.com/IN (signed): next key event: 23-Mar-2017 10:09:58.
sign the zone
add NSEC3

testing the signed zone
37
# dig @localhost dnssec.example.com soa +dnssec +multi
; <<>> DiG 9.10.4-P6-RedHat-9.10.4-4.P6.fc25 <<>> @localhost dnssec.example.com soa +dnssec +multi
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12949
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dnssec.example.com. IN SOA
;; ANSWER SECTION:
dnssec.example.com. 3600 IN SOA ns1.dnssec.example.com. hostmaster.dnssec.example.com. (
1004 ; serial
7200 ; refresh (2 hours)
1800 ; retry (30 minutes)
3542400 ; expire (5 weeks 6 days)
1800 ; minimum (30 minutes)
)
dnssec.example.com. 3600 IN RRSIG SOA 13 3 3600 (
20170422080958 20170323070958 22834 dnssec.example.com.
d1Uqw9l2zNAPV9YHEVdOL07+0KKFW7eTPRK6b1kZVkPK
d7Tp80OJ5phHaDoTc8KUWSQFeRJqcAcYBLVs8mvRXw== )
;; SERVER: ::1#53(::1)
;; WHEN: Thu Mar 23 09:23:20 CET 2017

generating the DS-Record
38
# dnssec-dsfromkey -2 /var/named/keys/Kdnssec.example.com.+013+38320.key
dnssec.example.com. IN DS 38320 13 2 3E762F32EDC681F851518874763486BE8C8136DD9B258B1C558B20DC837A7143

Knot-DNS
39

Knot DNS-Server configuration
40
server:
# Listen on all configured IPv4 interfaces.
listen: 0.0.0.0@53
# Listen on all configured IPv6 interfaces.
listen: ::@53
# User for running the server.
user: knot:knot
log:
# Log info and more serious events to syslog.
- target: syslog
any: info
policy:
- id: rsasha256
algorithm: RSASHA256
ksk-size: 2560
zsk-size: 2048
zone:
# Master zone.
- domain: dnssec.example.com
storage: /var/lib/knot/zones/
file: "dnssec.example.com.zone"
dnssec-signing: on
dnssec-policy: rsasha256
global
configuration
logging
DNSSEC
signing policy
zone
definition

Zonefile
41
$TTL 3600
@ IN SOA ns1 hostmaster 1001 2h 30m 41d 30m
IN NS ns1
IN NS ns2
IN TXT "Zone for DNSSEC signing tutorial"
ns1 IN A 192.0.2.53
ns2 IN A 192.0.2.153
www IN A 192.0.2.80
IN AAAA 2001:db8:100::80

reloading and signing
42
# knotc reload
# journalctl -e | tail
Mar 23 09:56:32 knot[3546]: info: control, received command 'reload'
Mar 23 09:56:32 knot[3546]: info: reloading configuration file '/usr/local/etc/knot/
knot.conf'
Mar 23 09:56:32 knot[3546]: info: configuration reloaded
Mar 23 09:56:32 knot[3546]: info: [dnssec.example.com.] DNSSEC, executing event 'generate
initial keys'
Mar 23 09:56:33 knot[3546]: info: [dnssec.example.com.] DNSSEC, loaded key, tag 3110,
algorithm 8, KSK yes, ZSK no, public yes, active yes
Mar 23 09:56:33 knot[3546]: info: [dnssec.example.com.] DNSSEC, loaded key, tag 53466,
algorithm 8, KSK no, ZSK yes, public yes, active yes
Mar 23 09:56:33 knot[3546]: info: [dnssec.example.com.] DNSSEC, signing started
Mar 23 09:56:33 knot[3546]: info: [dnssec.example.com.] DNSSEC, successfully signed
Mar 23 09:56:34 knot[3546]: info: [dnssec.example.com.] loaded, serial 1002
Mar 23 09:56:34 knot[3546]: info: [dnssec.example.com.] DNSSEC, next signing at
2017-03-30T10:56:32
reload configuration
and sign
Key information

test the signed zone
43
# dig @localhost soa dnssec.example.com +dnssec +multi
[…]
;; ANSWER SECTION:
dnssec.example.com. 3600 IN SOA ns1.dnssec.example.com. hostmaster.dnssec.example.com. (
1003 ; serial
7200 ; refresh (2 hours)
1800 ; retry (30 minutes)
3542400 ; expire (5 weeks 6 days)
1800 ; minimum (30 minutes)
)
dnssec.example.com. 3600 IN RRSIG SOA 8 3 3600 (
20170406090136 20170323090136 53466 dnssec.example.com.
NUK5mspkQY6dTRPAuXn0gwhghHiZQIGqvbUxfNoM1ykd
kRVY/vRwqYhAZHC8Jogrj9Whr+kCV9Iv/0pNuAItp1ld
W1Ar2F9sfRpmDXyFt6qVcXKdzH88SnftAlIkdHulL4UG
xzyBxp6aHLgTkDij/5c8pyjHIgBgr5e/RHIxKtQ32gbl
XGQaVIG62oith1fQz6nnAZKcgnvvwe4qgQatVEXyKfM4
tU8kK9qxiUkL+S4lohGxJ+pGN81BbBaNSErmnCWBqEoj
ckkdQkp5oOM/a1Y/ncyK1JU22P/L6I25Jw0l1uPh9/lx
aelUZq4A5SFe7ASpoIvKJlL2VHtkgx7HMg== )
;; SERVER: ::1#53(::1)
;; WHEN: Thu Mar 23 10:10:27 CET 2017

generate the DS-record
44
# dig @localhost dnskey dnssec.example.com +dnssec | grep 257 > dnssec.example.com.ksk
# ldns-key2ds -2 -n dnssec.example.com.ksk
dnssec.example.com. 3600 IN DS 3110 8 2 ( 
8d2f37875063fd1a16ffbbd07bff8788f58411c77d3d5e3fa2fe8030cdbd7029 )

And now?
45

next steps
publish the DS-record via your registrar
test DNSSEC validation of your zone (for example
via https://dnsviz.net/)
decide if you want/need key rollover
a DNSSEC signed zone without key-rollover is still
more secure than a plain, non-DNSSEC zone!
Men & Mice will cover key-rollover (automation) in an
upcoming webinar
46

Next
47

Men & Mice DNS Training
•Introduction to DNS & BIND Hands-On Class
•April 3 – 5, 2017, Redwood City (CA), USA
•May 1 – 3, 2017, Boston (MA), USA
48
https://www.menandmice.com/training/

•Introduction & Advanced DNS and BIND Topics
Hands-On Class
•April 3 – 7, 2017, Redwood City (CA), USA
•May 1 – 5, 2017, Boston (MA), USA
49
https://www.menandmice.com/training/

•DNS & BIND (German Language)
•May 22 – 24, 2017, Essen, DE
•DNSSEC and DANE (German Language)
•December 4-12, 2017, Essen, DE
50
http://linuxhotel.de/

our next webinar  
SMTP STS (Strict Transport Security) vs. SMTP with DANE
The Internet Public Key Infrastructure (PKIX) is broken, but several
solutions exist to fix some of the issues around transport encryption
with TLS and x509 certificates.
This webinar will take a deeper look at two solutions: RFC 7672
“SMTP with DANE” and draft-ietf-uta-mta-sts “SMTP MTA Strict
Transport Security (MTA-STS)”. What problems are solved with these
solutions? What is needed to implement MTA-STS and SMTP-DANE?
Is one solution preferable over the other, or should you deploy both?
Join us for a 45 minutes webinar with a Q&A session at the end, on
Thursday, April 13th, 2017 at 5:00 PM CEST/ 3:00 PM GMT/ 11:00
AM EDT / 8:00 AM PDT.
51
https://www.menandmice.com/resources/webinar-smtp-sts-strict-transport-security-vs-smtp-with-dane/

Thank you!
Questions? Comments?
52

DNSSEC signing Tutorial

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to DNSSEC signing Tutorial

Similar to DNSSEC signing Tutorial (20)

More from Men and Mice

More from Men and Mice (20)

Recently uploaded

Recently uploaded (20)

DNSSEC signing Tutorial