Hands-on DNSSEC Deployment

Hands on DNS and DNSSEC
Md. Abdul Awal

DNS Basics
• Distributed global database
• Transport protocol: UDP and TCP port 53
• Theoretically the DNS indexes internet resources
§ IP addresses of hosts, where to send email, etc.
• Data is indexed by domain names
§ A domain name is a sequence of labels
§ Labels are separated by dots (“.”) and form a tree
§ eg: www.yahoo.com
Hands on DNS and DNSSEC 3
RFC
1034
1035

Hierarchical Database
• Root (“.”) at the top,
domain names as leaves
underneath
• Administration is shared
• Authority is delegated,
No single entity in charge
com org bd
sanog.org nsrc.orggoogle.com net.bd
bdren.net.bdwww.sanog.org
/
(root)
etc bin usr
etc/rc.d usr/local
usr/local/src
usr/sbin
.
(root)
DNS Database UNIX Filesystem
DNS represented as
a tree of labels

Root and TLDs
• “Empty Label” covers the “.” zone or the Root of the DNS
§ There are 13 Root servers (a-m.root-servers.net) and more than a thousand
instances
§ Next level of names are called Top Level Domains (TLDs)
• Types:
§ TLD: Top Level Domains (.com, .net, .edu, .org etc)
§ ccTLD: Country Code TLD (2 letter country codes: .us, .fr, .bd etc)
§ Infrastructure: .arpa (usage: reverse DNS)
§ IDN: (Internationalized Domain Name: .‫ا‬‫ﻟ‬‫ﻤ‬‫ﻐ‬‫ﺮ‬‫ب‬ , .বাংলা, .भारत etc)
§ The new gTLD: Generic TLD (.tourism, .museum, .dubai etc)
o newgtlds.icann.org

Domains
• Domains are namespaces
• Everything below .net is the
net domain
• Everything below apnic.net is
in the apnic.net domain and
in the net domain
com org net
bdnoggoogle apnic
training
“.”
com domain
apricot
wwwftp
amazon
ns1 ns2
net domain
apnic.net
domain

Delegation
• An administrator of a domain can delegate responsibility for managing
a subdomain to someone else
• The parent domain retains links to the delegated subdomain
§ The parent domain “remembers” who it delegated the subdomain to
§ Parent zone adds “Glue” records for delegated zone

Delegation: Domains vs Zones
• When we talk about the
entire subtree, we talk
about domains
• When we talk about part
of a domain that is
administered by an entity,
we talk about zones
• Delegation: boundaries
between zones (sometimes
called Zone Cuts)
com bd arpa
gov
ip-addr
45
“.”
ip6
114
130
bcc
www mail
amazon
129
Delegation
130.114.in-addr.arpa
zone
root
zone
nsrc
nsrc.org
domain
www ws
org
nocns1
nsrc.org
zone mail
ws.nsrc.org
zone

DNS Main Components
• Server Side:
§ Authoritative Servers
o Primary
o Secondary
§ Resolvers (Recursive Resolvers)
o Aka Caching Resolvers
§ Hybrid (Authoritative + Recursive)
o Security and management issues
• Client Side:
§ Stub resolvers (on client machines)
Client
Root DNS
Server
Recursive
Resolver
(Stub Resolver)
Authoritative
Server
Authoritative
Server

1. I got NS of com. — Cache
2. Do I know example.com.? — No!
3. Send query to TLD server ... wait
5
DNS Working Mechanism
“.”
Root Server
Recursive
Resolver
“example.com.”
Authoritative
Server
“.com.”
TLD Server
Client
(Stub Resolver)
App: What is the
IPv6 address of
www.example.com?
1
1. Do I have answer in cache? — No!
2. Do I have a resolver? – Yes!
3. Query: www.example.com. AAAA
4. Send to recursive resolver ... wait
2
3. Send query root server ... wait
3
1. Do I know www.example.com.? — No!
2. Do I know com.? — Yes!
3. Reply: com. nameservers’ IPs
4
2. Do I know example.com.? — Yes!
3. Reply: example.com. Nameservers’ IPs
61. I got AAAA of www.example.com.— Cache
2. Reply: AAAA of www.example.com is
2001:db8::80
9
1. Do I know www.example.com. AAAA? — Yes!
2. Reply: AAAA of www.example.com is 2001:db8::80
8
1. I got AAAA of www.example.com – Cache
2. Serve the application
10
2
9
3
5
6
7
8
Query?
Response!
7
1. I got NS of example.com.— Cache
2. Send query to nameserver ... wait
Recursive Resolver is
prepopulated with root
DNS server addresses
4

DNS Packet Format
DNS Query Packet DNS Response Packet

Resource Records (RR)
• The fundamental unit of data in the DNS database
• A grouping of a {domain name, type, class}, a TTL (time-to- live),
and the associated “resource data”
• Has a defined text “presentation format”
www.example.com. 86400 IN A 203.0.113.5
label ttl class type rdata

Common Resource Record Types
• NS: Name Server Record
• A: IPv4 Address Record
• AAAA: IPv6 Address Record
• CNAME: Canonical Name (Alias)
• MX: Mail Exchanger Record (IP to host)
• PTR: Pointer (Reverse DNS info)
• SRV: Service Location Record (host + port)
• SOA: Start of Authority

Zone File Example
$TTL 3600 ; Default TTL directive
example.com. IN SOA ns1.example.com. admin.example.com. (
2002021301 ; serial
1h ; refresh
30M ; retry
1W ; expiry
300 ) ; minimum
IN NS ns1.example.com.
IN NS ns2.example.com.
IN MX 10 mail1.example.com.
IN MX 20 mail2.example.com.
86400 IN TXT “Demo zone”
ns1.example.com. 7200 IN A 10.1.1.1
AAAA 2001:db8:1::1
ns2.example.com. IN A 10.1.2.1
AAAA 2001:db8:2::1
mail1.example.com. IN A 10.1.1.5
AAAA 2001:db8:1::5
mail2.example.com. IN A 10.1.2.10
AAAA 2001:db8:2::10
www.example.com. IN CNAME ns1.example.com.

DNS Tree for Reverse Domains
net arpa
ip-addr
114
“.”
ip6
103
apnic
48
nsrc
www
org
mail
academy
50
16 17
1.f.d.0.1.0.0.2
0.8.3.3
0.8.d.e.1.0.4.2
16.48.103.in-addr.arpa
zone
0.8.d.e.1.0.4.2.ip6.arpa
zone
1.8.3.3
0.8.3.3.1.f.d.0.1.0.0.2.ip6.arpa
zone
130
130.114.in-addr.arpa
zone

Pointer (PTR) Records
• Create PTR records for each IP address
§ Example (IPv4 domain): 2.0.192.in-addr.arpa
§ Example (IPv6 domain): 2.0.0.0.8.1.c.0.8.b.d.0.1.0.0.2.ip6.arpa
$ORIGIN 2.0.192.in-addr.arpa.
10 IN PTR vm01.example.com.
10.2.0.192.in-addr.arpa. IN PTR vm01.example.com.
Or
$ORIGIN 2.0.0.0.8.1.c.0.8.b.d.0.1.0.0.2.ip6.arpa.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR vm01.example.com.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0.8.1.c.0.8.b.d.0.1.0.0.2.ip6.arpa.
IN PTR vm01.example.com.
Or

A Reverse Zone Example
$ORIGIN 2.0.192.in-addr.arpa.
@ 3600 IN SOA ns1.example.com. admin.example.com. (
2002021301 ; serial
3600 ; refresh
1800 ; retry
604800 ; expiry
300 ; neg. ttl
)
NS ns1.example.com.
NS ns2.example.com.
10 PTR vm01.example.com.
11 PTR vm02.example.com.
2 PTR ns1.example.com.
7 PTR smtp.example.com.

An IPv6 Reverse Zone Example
$ORIGIN 2.0.0.0.8.1.c.0.8.b.d.0.1.0.0.2.ip6.arpa.
@ 3600 IN SOA ns1.example.com. admin.example.com. (
2002021301 ; serial
3600 ; refresh
1800 ; retry
604800 ; expiry
300 ; neg. ttl
)
NS ns1.example.com.
NS ns2.example.com.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR vm01.example.com.
1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR vm02.example.com.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR ns1.example.com.
7.0.0.0.a.0.0.0.0.0.0.0.0.0.0.0 PTR smtp.example.com.

DNS Issues and Vulnerabilities

Issues with DNS
• DNS data can be corrupted
• There is no way to check the validity of DNS data
§ Exploited by bugs in resolver implementation (predictable transaction ID)
§ Polluted caching forwarders can cause harm for quite some time (TTL)
§ Corrupted DNS data might stay in cache for a long time
• Transactions between DNS servers and clients can be compromised
• How does a secondary nameserver knows it is talking to the authentic
primary nameserver?
• And what about privacy of your DNS data?

DNS Vulnerabilities
Primary
server
Secondary
server
Dynamic Update
Query/Response
(Secondary server)
ResolverClient
(Stub Resolver) Zone data
synchronization
Update
Station
Query/Response
(Primary server)
Zone File
Zone data access
DNS Query/Response
Cache impersonation
Unauthorized updates
Corrupting Data
Impersonating master
Cache pollution by
data spoofing
Data protection Server protection

DNS Cache Poisoning
ns.example.com
Resolver
Client
QID=53125
Query: www.example.com?
Response: 192.0.2.5
QID=53126
QID=53127
Match!
Attcker
Root/GTLD
QID=53127
www.example.com = 192.0.2.5
Wrong answer is cached by
the resolver and will remain
there until TTL expires
QID=53127

DNS Cache Poisoning Protected by DNSSEC
ns.example.com
ResolverClient
QID=53125
Query: www.example.com?
Response: 203.0.113.2
QID=53126
QID=53127
DNSSEC Signature
does not match
Attcker
Root/GTLD
QID=53127
QID=53127
DNSSEC Signature
matched

Vulnerabilities Protected by DNSSEC
Primary
server
Secondary
server
Dynamic Update
Query/Response
(Secondary server)
ResolverClient
(Stub Resolver) Zone data
synchronization
Update
Station
Query/Response
(Primary server)
Zone File
Zone data access
DNS Query/Response
Cache impersonation
Cache pollution by
data spoofing
Data protection Server protection

Cryptography
• A way to encrypt or hash some content
§ Make it “secure” and/or verifiable
§ Different methods, algorithms and keys
• Intent is not always to hide the message
§ For DNSSEC, goal is to verify the content
• Three cryptography concept in DNSSEC
§ Public / Private keys
§ Message digests / checksums / hashes
§ Digital signatures
These are at the core of
DNSSEC. If these do not
make sense, then DNSSEC
will not make sense.

Ciphertext
• We start with plaintext.
Something you can read.
• We apply a mathematical
algorithm to the plaintext.
• The algorithm is the cipher.
• The plaintext is turned in to
ciphertext.
This is a tutorial.
EnCt251cf69f1b39955c1
8b9065b3251e48cb51ae
db6a51cf69f1b39955c18
b9065b32zi/xgEAswPLDNi
LFl+lQA/5iuWANQZYqddw
nHSFYv5Ghe+pE6m9eVtr
TS8kk2RInZgimYPBIwEmS
Ciphertext
CipherPlaintext

Public/Private Keys
• We generate a cipher key pair: a private key and a public key
• The private key remains secret and should be protected
• The public key is freely distributable
§ Mathematically to the private key
§ Almost impossible to derive the private key from the public key
Content encrypted with one key, can
only be decrypted with the other one
This is a DNSSEC
tutorial.
Encrypt using
private key
Decrypt using
public key
EnCt251cf69f1b39955c18b9065b3
251e48cb51aedb6a51cf69f1b3995
5c18b9065b32zi/xgEAswPLDNiLFl+l
QA/5iuWANQZYqddwnHSFYv5Ghe+p
E6m9eVtrTS8kk2RInZgimYPBIwEmS This is a DNSSEC
tutorial.
Cleartext Cleartext
Ciphertext

One-Way Hashing Function
• A mathematical function that generates a fixed-length result
regardless of the amount of data you pass through it
§ Generally very fast
§ Irreversible, thus the term “one-way”
• The fixed-length result of a hashing function is referred to as a
checksum, message digest or hash
§ Very unlikely that two sets of data produce the same fixed-length result
§ If found, this is called a collision (eg. md5)
§ Some popular hashing functions include md5 (128 bit), sha1 (160 bit),
sha2 (224-512 bit)

Hashing Function Example
This is a tutorial.
This is a DNSSEC
tutorial.
This is a DNSSEC
tutorial for network
administrators.
Hash Function
Hash Function
4af8da20baa338f9fb9e2de
afad175b15ebc555c
cd0813c2031c5ace858744
d7bc48fbfeb6b8b12e
8f1b6b4594040dfdb0ff48
45ecb0cadd27bd6be6
Hash Function
Hashes vary with inputs
but the lengths are same

Digital Signature
• Combining hashing and public key encryption creates a digital signature
§ Hashing a document produces a message digest
§ Encrypt the message digest with a key creates its digital signature
This is a DNSSEC
tutorial. cd0813c203
1c5ace8587
44d7bc48fb
feb6b8b12e
EnCt251cf69f1b39955c1
8b9065b3251e48cb51aed
b6a51cf69f1b39955c18b
9065b32zi/xgEAswPLDNiL
Fl+lQA/5iuWANQZYqddwn
HSFYv5Ghe+pE6m9eVtrT
S8kk2RInZgimYPBIwEmS
Plaintext
Message Digest
or Hash or checksum Digital Signature
Hashing
Algorithm
Encryption using
the key

Authentication with Digital Signature
• Sender sends the message along with its digital signature
• Receiver receives the message and produces its hash
• Besides, receiver decrypts the received digital signature using sender’s
public key and gets the hash of the message
• If both hashes match, nobody tampered with the message
This is a DNSSEC
tutorial.
Compare
Digital
Signature
Hashing
Algorithm
This is a DNSSEC
tutorial.
Encrypt using
private key
Decrypt using
public key
Hashing
Algorithm
Hash Hash
Hash

DNSSEC At a Glance
• DNS Security Extensions
• Protects the integrity of data in DNS by establishing a chain of trust
• A form of digitally signing the data to attest its validity
§ Changes DNS trust model from “open and trusting” to “verifiable”
• Use of public key cryptography to provide:
§ Authentication of origin
§ Data integrity
§ Authenticated denial of existence
RFC
4033
4034
4035

DNSSEC Concepts
• No modifications to the core protocol
§ Can coexist with today's infrastructure (EDNS0)
• No attempt to provide confidentiality (NO encryption)
• Don't sign the entire zone, sign a RRset
• The parent DOES NOT sign the child zone
§ The parent signs a pointer (hash) to the key used to sign the data of
child zone (DS record)

What’s new in DNSSEC
• New Resource Records (DNSKEY, RRSIG, NSEC/NSEC3, DS etc.)
• New packet options (CD, AD, DO)
• Chain of trust
• Key generation and signing
• Validation
• Key Rollovers

DNSSEC Records
Resource
Records
Description Function
DNSKEY DNS Key
Contains public key used for zone
signing
RRSIG
Resource Record
Signature
Contains signature made by signing
RRset using private key
NSEC Next Secure
Points to next name in zone (used for
authenticated denial of existence)
DS
Delegation
Signer
Contains the hash of the public key for
subordinate zone
NSEC3 Next Secure v3
Enhanced version of NSEC (provides zone
enumeration protection and opt-out)
NSEC3PARAM NSEC3 Parameter Parameters to create NSEC3 RRs

How DNSSEC Works
• Authoritative servers
§ Sign their zones
§ Answer queries with the record requested
§ Also send the digital signature corresponding to the record
• Validating Resolvers
§ Authenticates the responses from the server
§ Data that is not validated results to a “SERVFAIL” error

EDNS0
• DNS messages larger than 512 bytes requires:
§ Use of TCP (typically truncated UDP response followed by TCP retry)
§ EDNS0 - a DNS extension mechanism allowing negotiation of larger UDP
message buffers
§ RFC 6891 “Extension Mechanisms for DNS (EDNS0)
• For DNSSEC, EDNS0 does:
§ Negotiation of larger UDP payload sizes
§ Flag to indicate querier is able to process DNSSEC records:
o the “DNSSEC OK” or “DO” bit

Opt “pseudo” RR
• OPT resource record (RR type code 41)
• Pseudo RR (doesn’t exist as data in a zone)
• Appears in the “Additional Section” of a DNS message
• Contains maximum UDP Payload Size, extended RCODEs and flags
• Only flag defined to date: DNSSEC OK (DO)

New Header Flags: AD and CD
42
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| OpCode |AA|TC|RD|RA|Z |AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5
1 1 1 1 1 1
12bytes
6 7 8 9 0 1 2 3 4 5
Common Response codes (RCODE):
0 NOERROR No Error
1 FORMERR Format Error
2 SERVFAIL Server Failure
3 NXDOMAIN Not existent domain
4 NOTIMPL Not implemented
5 REFUSED Query Refused
DNSSEC responses that fail to authenticate
(validate) properly, eg. bad signature,
expired signature etc is SERVFAIL
Querier sets CD flag to indicate that
“pending” (non- authenticated
data) is acceptable to it
Resolver sets AD flag in responses when the
queried record is signed with a valid, unexpired
signature and an authenticated chain of trust.
Can also be set in a DNS query to indicate querier
understands responses with AD bit.
AD = Authenticated Data
CD = Checking Disabled

RR and RRset
www.example.com. 86400 IN AAAA 2001:db8:1::80
44
3 RRs but 2 RRSets
In DNSSEC, RRsets are signed,
not the individual RRs
Each RRsets will be
signed as a separate set
MX
MX
MX
AAAA
AAAA
AAAA
AAAAAAAA
AAAAMX
RRset
Resource Records
AAAAAAAA
RRSIG
AAAAMX
RRSIG
RRsets signed with private key

DNSKEY Record
• Contains zone’s public key(s) and associated flags
example.com. 3600 IN DNSKEY 256 3 5 (
AwEAAdevJXb4NxFnDFT0Jg9d/jRhJwzM/YTuPJqpvjRl14Wab
habS6vioBX8Vz6XvnCzhlAxz7zc7lirVewUphYijpDTeeX2nE
fq3leFKmHqQw4Oc7Jxp7/Bdfr2uZfeCws0zwal2kZDJX/O+wB
NqtIltc6tdwzXtGU21VEvDsFdl3xiQpRHkXt9PclVIqnGv39h
) ; key id = 3510
Owner
Key ID
Public Key
(Base64 encoded)
Type
Algorithm
Protocol
(3=DNSSEC)
Flags (16-bit)
256 = ZSK
257 = KSK
Common DNSSEC Algorithm
5 = RSA/SHA1
6 = DSA-NSEC3-SHA1
7 = RSA-NSEC3-SHA1
8 = RSA/SHA256
10 = RSA/SHA512
13 = ECDSA-SHA256
14 = ECDSA-SHA384
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

RRSIG Record
• The private part of the key-pair is used to sign the RRset
• The digital signature per RRset is saved in an RRSIG record
example.com. 3600 IN NS ns1.example.com.
example.com. 3600 IN NS ns2.example.com.
example.com. 3600 IN RRSIG NS 13 2 3600 (
20200919034524 20200820024524 10500 example.com.
VBekRkq60wdXayRHSM5qRtVtPBJ4GpWwG0DBzbS28mJQ
kZksOsymj/sB+2OHjZlSgbO5B0WcT8IyJy40ScHwjA== )
Original TTL
Type covered
No. of Labels
12
‘NS’ RRset
Algorithm
Type
Key ID
Signer Name
Cryptographic Signature
Signature Inception
(YYYYMMDDhhmmss)
Signature Expiration
(YYYYMMDDhhmmss)

NSEC Record
• Next SECure
• Forms a chain of authoritative owner names in the zone
§ Last NSEC record points back to the first
§ Each NSEC record also has a corresponding RRSIG
• Lists two separate things:
§ Next owner name (canonical ordering)
§ Type-bitmap defines RRtypes available at owner name
• Used for authenticated denial-of-existence of data
§ Authenticated non-existence of TYPEs and Labels
• Side Effect: allows enumeration of zone contents (Zone Walking)

NSEC Record
a.example.com. 600 IN NSEC d.example.com. A AAAA TXT MX RRSIG NSEC
a.example.com. 600 IN RRSIG NSEC 13 2 600 (
20200918035156 20200819031904 54481 example.com.
kw2k+hl38n92gMCOWyocpd12rxP8Bz1ChE9gwtnusDMZ
DDV7d4PGcoykHmt/+MQEcPSWLw+ec6WLjniD0Nud0A== )
Owner
Signature of the
corresponding NSEC
Type
Next Owner Name
in the zone
Type Bitmap
(List of Types defined at Owner Name)

NSEC: Negative Answers
• “Authenticated Denial of Existence”
• With NSEC or NSEC3 records (and their signatures)
§ Chain together DNS records in a zone
example.com
a.example.com
blah.example.com
z.example.com
buzz.example.com
Zulu.example.com
A MX AAAA NS TXT DS RRSIG DNSKEY NSEC
NS DS RRSIG NSEC
A RRSIG NSEC
NS RRSIG NSEC
AAAA RRSIG NSEC
A AAAA RRSIG NSEC
I have nothing between blah.example.com and
buzz.example.com. Therefore, I deny the
existence of box.example.com
What’s the A record of box.example.com?
signed
Zulu.example.com exists for A AAAA RRSIG and
NSEC RRTypes but not for MX record
What’s the MX record of Zulu.example.com?
signed

NSEC3 Record
• New version of NSEC that provides defence against zone enumeration
• Uses a hashing algorithm to list the owner name and next available
domain in “hashed” format (Base32 with extended hex alphabet)
• Optional “Opt-Out” flag
RFC
5155
N84P2BUKTKBUJMVEGQD0BHVO0I2V8MAQ.example.com. 1799 IN NSEC3 1 0 10 4F83F5 (
NLT8KJ9MTE8O99FFMRJ1RAT6D4H56Q4V
A RRSIG )
N84P2BUKTKBUJMVEGQD0BHVO0I2V8MAQ.example.com. 1799 IN RRSIG NSEC3 7 3 3600 (
20200903205003 20200820205003 9629 example.com.
FWnq6xxoPiIEBdlLdaRi0obd9jz7siEQWnT...... )
Hashed owner name
Signature of the
corresponding NSEC3
Type Algorithm Iteration Salt
Opt-Out flagHashed next owner
NSEC3PARAM
Owner’s RRtypes

NSEC3PARAM Record
• “NSEC3 Parameter” record
§ Configured at zone apex of authoritative
§ Used by authoritative nameservers for the zone, to choose an appropriate
set of NSEC3 RRs for responses
§ Hashed names are ordered
• RDATA: Hash algorithm, Flags, Iteration number and Salt
example.com 600 IN NSEC3PARAM 1 0 10 2D81AA46
Zone name Type
Algorithm
1 = SHA-1
Flag
0 = Opt-Out disabled
1 = Opt-Out enabled
Number of
Iteration Salt

DS Record
• Delegation Signer
§ Establishes authentication chains between DNS zones
§ Indicates that delegated zone is digitally signed
• Hash of the public DNSKEY (KSK) of the child zone
§ Stored in the parent zone, together with child’s NS RRs
§ Not to be added in the child zone
• The DS record for the child zone is signed together with the rest of
the parent zone data
§ NS records are NOT signed (they are a hint/pointer)

DS Record
• Validating resolvers use the DS record and its corresponding signature (RRSIG) to
securely authenticate the delegation
example.com. 43200 IN DS 3330 7 2 (
7AD5E47FFFFA05AE70D5166E01B7836E34AD3032541D
95DB9D1E9D7D3AFB33D4 )
example.com. 43200 IN DS 3330 7 1 (
268B71BF480AE2C1484BB1DBA7E0A42089D90298 )
example.com. 43200 IN RRSIG DS 7 2 86400 (
20200907152802 20200817142802 21869 com.
bse4x+/QMeQaWObJyaUEwB3YeQe2JRnxDBOYF22Jrzye
TtKQhiRKqNYoR3rTsrxe6eiP5MoceI7yTVYAd7m13bOi
8TmrZ6EZ2uhXrUlmPx9D/DPIVPrbKJGBQmgrKLQn+dP2
qHEH923Gkt0sD8dmaIikjqb4TtLUAeOBGjZdzJM= )
Owner Type
Key ID
Hash of child’s public key
Digest Type
1=SHA1, 2=SHA256Algorithm
Signature of
DS RRset

Secure and Insecure Delegations
• Secure Delegations
§ Parent zone has child’s NS RRs and its DS RRSet with corresponding
RRSIG
• Insecure Delegations
§ Parent zone has child’s NS RRSet, but lacking a DS RRSet
o i.e. A delegation to an unsigned child zone
• Validating resolvers use the presence of the DS record, its RRSIG and
corresponding DNSKEY to securely authenticate the delegation

Multiple DNSKEYs: ZSK and KSK
• In practice, we use two keypairs
§ One to sign the zones, another to sign the other key
• Using a single key or both keys is an operational choice
• If using a single key-pair:
§ Zones are digitally signed using the private key
§ Public key is published using DNSKEY RR
§ When key is updated, DS record must again be sent to parent zone
• To address this administrative load, two keypairs will be used

Multiple DNSKEYs: ZSK and KSK
• Zone Signing Key (ZSK) : Flag 256
§ Sign the RRsets within the zone
§ Signed by the KSK
§ Can be lower strength
§ Can be changed without
coordination with parent zone
• Key Signing Key (KSK) : Flag 257
§ Signs the ZSK
§ Pointed to by the parent zone
using DS records
§ Can be larger (ie. stronger)
§ Used as trust anchor or security
entry point
57
Private Key Public Key
Private Key Public Key
Key Signing Key
Zone Signing Key
Signs only the DNSKEY
RRset in the Zone
Hashed and put in
parent zone as DS
Included in zone file
as DNSKEY record
Included in zone file
as DNSKEY record
Signs all RRset in the
zone to create RRSIGs

Verifying Chain of Trust
• Data in zone can be trusted if signed by a ZSK
• ZSK can be trusted if signed by a KSK
• KSK can be trusted if pointed to by trusted DS record
• DS record can be trusted
§ if signed by the parents ZSK, or
§ DS or DNSKEY records can be trusted if exchanged out-of-band and
locally stored (Secure Entry Point)

5
Recall: DNS Working Mechanism
“.”
Root Server
Recursive
Resolver
“example.com.”
Authoritative
Server
“.com.”
TLD Server
Client
(Stub Resolver)
App: What is the
IPv6 address of
www.example.com?
1
2
3
4
6
2001:db8::80
9
8
10
2
9
3
5
6
7
8
Query?
Response!
7
4

5
DNSSEC Working Mechanism
“.”
Root Server
Recursive
Resolver
“example.com.”
Authoritative
Server
“.com.”
TLD Server
Client
(Stub Resolver)
App: What is the
IPv6 address of
www.example.com?
1
2
3
4
6
2001:db8::80
9
8
10
2
9
3
5
6
7
8
Query?
Response!
7
4
and the root’s public key root keySet DO bit
+DS,RRSIG,DNSKEY
+DS,RRSIG,DNSKEY
+RRSIG,DNSKEY
Set AD bit
com key
example key
root pubkey
Set DO bit
Set DO bitSet DO bit

DNSSEC: Roles to be Played
• Registries and hosting providers
§ Sign your zones, use newer algorithms (such as ECDSA)
§ Before fully implementing:
o Plan about key rollover
o Think about securing your keys (what happens if your key gets compromised)
• Network Service Providers
§ Enable DNSSEC validation on recursive servers
o BTW, domains that can’t be validated will be inaccessible
• End users
§ Use a DNSSEC-validating resolver

Signature Expiration
• Keys do not expire
§ Still a good practice to generate new ones regularly for added security
• Signatures have validity period
§ By default set to 30 days
§ This info is added in the key metadata
• What happens when signatures expire
§ SERVFAIL – the domain disappears from the Internet for validating resolvers
§ Must re-sign the zones

Walking the Chain of Trust
AAAA
AAAA
:
‘AAAA’ RRset
MX
MX
:
‘MX’ RRset
RRSIG AAAA
RRSIG MX
DNSKEY (ZSK)
DNSKEY (KSK)
RRSIG DNSKEY
RRSIG DNSKEY
‘DNSKEY’
RRset
:
: RRsets and RRSIGs
DS
RRSIG DS
DNSKEY (ZSK)
DNSKEY (KSK)
‘DNSKEY’
RRset
Private ZSK
Private KSK
Private ZSK
Private KSK
Parent Zone
Child Zone
Sign
Sign
Sign
Sign
Sign
Hash
. DNSKEY (...) 5TQ3s... (8907) ; KSK
DNSKEY (...) lasE5... (2983) ; ZSK
RRSIG DNSKEY (...) 8907 . 69Hw9...
net. DS 7834 3 1ab15...
RRSIG DS (...) . 2983
net. DNSKEY (...) q3dEw... (7834) ; KSK
DNSKEY (...) 5TQ3s... (5612) ; ZSK
RRSIG DNSKEY (...) 7834 net. cMas...
ripe.net. DS 4252 3 1ab15...
RRSIG DS (...) net. 5612
ripe.net. DNSKEY (...) rwx002... (4252) ; KSK
DNSKEY (...) sovP42... (1111) ; ZSK
RRSIG DNSKEY (...) 4252 ripe.net. 5t...
www.ripe.net. A 193.0.0.202
RRSIG A (...) 1111 ripe.net. a3...
Trusted Key . 8907
root (.)
net.
ripe.net.
Locally configured
Resolvers’ get
root’s public KSK

DNSSEC Validation Process
Recursive
ResolverAAAA
RRSET
AAAA
RRSIG
DNSKEY
Verified
public ZSK
AAAA
Verified
RRset
DNSKEY
Verified
public KSK
DNSKEY
RRSET
DNSKEY
RRSIGDS
RRSET
DS
RRSIG
DNSKEY
Verified
public ZSK
DNSKEY
Verified
public KSK
DNSKEY
RRSET
DNSKEY
RRSIG
Parent Zone
Child Zone

DNS Flags
• Classical DNS Flags
§ qr = query response
§ rd = recursion desired
§ ra = recursion available
§ aa = authoritative answer
• DNSSEC Flags
§ ad = authenticated data
§ cd = checking disabled
§ do = DNSSEC Ok
A
A
A
A
A
A
A
Q
Q
Q

‘dig’ Command Options for DNSSEC
+dnssec request DNSSEC RRs via DO=1
+multi Print output across multiple lines
with annotation
+adflag set AD flag
+cdflag set CD flag
dig +dnssec A IN www.apnic.net
flags type class name

$ dig academy.apnic.net AAAA +dnssec +multiline
;; ANSWER SECTION:
academy.apnic.net. 688 IN AAAA 2001:dd8:9:2::101:88
academy.apnic.net. 688 IN RRSIG AAAA 13 3 86400 (
20200921141502 20200822131502 18494 apnic.net.
oQtfJiVwnH2LrJ2ABr3rj+8mnGP6DyRxMugAfU3Rmvha
YrRhCkFhfw56OJWjKFFQU/Tnbg/W0Fg8eghTvng9fA== )
dig Demo: DNSSEC Validation
$ dig apnic.net DNSKEY +dnssec +multiline
;; ANSWER SECTION:
apnic.net. 721 IN DNSKEY 256 3 13 (
bY/nKt78m6DL+Yi5FMvKd19Fx0uFIuQ3zituPS8q8Ayg
uQlVAcvM6JtHfEE42g9QrgCF4mwqHQfqcqQThneqzg==
) ; ZSK; alg = ECDSAP256SHA256 ; key id = 18494
apnic.net. 721 IN DNSKEY 257 3 13 (
jSTTxYYYq0VSUo/VkSPCajZH17dlJzdGfGOB45eBlvaZ
jJxGjI5X/Vwjvjt6+YTIdgqMRwtGRacSLg7FrZDY0w==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 53839
apnic.net. 721 IN RRSIG DNSKEY 13 2 3600 (
20200921141502 20200822131502 53839 apnic.net.
80QnAY55+CgCdSW0BaE4Z2VbvrOOuTdClXBMQFhTBBdB
hoQPTvUrIKFZWX1j6JdYeEbhlkxUBdcx4M63D1TGuw== )
AAAA
AAAA RRSIG
ZSK 18494
KSK 53839
RRSIG
ZSK 56519
KSK 35886
RRSIG
ZSK 46594
KSK 20326
root zone
net zone
apnic.net
zone
DS 35886
DS 53839

$ dig @a.gtld-servers.net. apnic.net. DS +dnssec +multiline
;; ANSWER SECTION:
apnic.net. 86400 IN DS 53839 13 2 (
CA144D6C226FED85E326B8E214F6B20C7F265EAFE198
CC501B6756C3C8578108 )
apnic.net. 86400 IN RRSIG DS 8 2 86400 (
20200827064410 20200820053410 56519 net.
p0eQsT5wcu9oHQR5vwuaKwnSKk+MLW+YQobkcMwRFdSu
B5vPfEhcFEGg+due7mrfZZc8xKa/fz6WdLmJhF+pvZWG
SP+G0mVXf6XFC2Wlng6r1LQcTCFVzi5i6kmdkmrnAxO8
DD+Ayne+QyPPRu0ZkCJWghuMfX43fITI5t95dBj9g2RD
/4X11whKG/D+VaIcoMWi+xvCNcSTkdG72gkWRg== )
RRSIG
ZSK 56519
KSK 35886
RRSIG
ZSK 46594
KSK 20326
AAAA
AAAA RRSIG
ZSK 18494
KSK 53839
$ dig @a.gtld-servers.net. net. DNSKEY +dnssec +multiline
;; ANSWER SECTION:
net. 86400 IN DNSKEY 256 3 8 (
AQPeYYme8NvhAl+0XjyGqHVep4Y1T2OrRmO+L3QGULBl
Oe571PnxI+gRyXCQmtN7WpoJxzALFSVBPsggqwOP+wnm
...... ) ; ZSK; alg = RSASHA256 ; key id = 56519
net. 86400 IN DNSKEY 257 3 8 (
AQOYBnzqWXIEj6mlgXg4LWC0HP2n8eK8XqgHlmJ/69iu
IHsa1TrHDG6TcOra/pyeGKwH0nKZhTmXSuUFGh9BCNiw
...... ) ; KSK; alg = RSASHA256 ; key id = 35886
net. 86400 IN RRSIG DNSKEY 8 1 86400 (
20200906162830 20200822162330 35886 net.
gB7A7yhMJHjo5d8lk3+TXX28MO0Cn7G9fDyWKVGDdatH
szDvzQ8b+scBlCnBO7qJXe85WRscyBIQf+Ca...... )
root zone
net zone
apnic.net
zone
DS 35886
DS 53839

$ dig @a.root-servers.net. . DNSKEY +dnssec +multiline
;; ANSWER SECTION:
. 172800 IN DNSKEY 256 3 8 (
AwEAAdauOGxLhfAKFTTZwGhBXbk793QKdWIQRjiSftWd
usCwkPhNyJrIjwtNffCWXGLlZAbpcs414RE3oS1qVwV+
...... ) ; ZSK; alg = RSASHA256 ; key id = 46594
. 172800 IN DNSKEY 257 3 8 (
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
...... ) ; KSK; alg = RSASHA256 ; key id = 20326
. 172800 IN RRSIG DNSKEY 8 0 172800 (
20200910000000 20200820000000 20326 .
NXsK5fyg201KDPr9xGJ5e82V7V67hf4sjW/eNHMuroLL
oil3Gc+j7HGD9kngw6ybeTRfL+qYzg2ccLuO...... )
AAAA
AAAA RRSIG
ZSK 18494
KSK 53839
RRSIG
ZSK 56519
KSK 35886
RRSIG
ZSK 46594
KSK 20326
$ dig @a.root-servers.net. net. DS +dnssec +multiline
;; ANSWER SECTION:
net. 86400 IN DS 35886 8 2 (
7862B27F5F516EBE19680444D4CE5E762981931842C4
65F00236401D8BD973EE )
net. 86400 IN RRSIG DS 8 1 86400 (
20200905050000 20200823040000 46594 .
wB0DBRBgHWbqPW2Udn3FMZy/972Tebmg6CsyCy0dp4vb
lKhW7eW94QKpnPkWH4VVGKzOxsPJ8kgcoXR2...... )
root zone
net zone
apnic.net
zone
DS 35886
DS 53839

dig Example 1: Simple DNS Query
73
$ dig @192.168.1.1 apnic.net. A
; <<>> DiG 9.10.6 <<>> @192.168.1.1 apnic.net. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25343
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;apnic.net. IN A
;; ANSWER SECTION:
apnic.net. 3599 IN A 203.119.101.61
;; Query time: 136 msec
;; SERVER: 192.168.1.1 #53(192.168.1.1)
;; WHEN: Sat Aug 22 15:10:57 +06 2020
;; MSG SIZE rcvd: 54
Validation disabled
on resolver
Query
Response
DNSSEC records
not asked

dig Example 2: DNSSEC Query
$ dig @192.168.1.1 apnic.net. A +dnssec +multiline
; <<>> DiG 9.10.6 <<>> @192.168.1.1 apnic.net. A +dnssec +multiline
; (1 server found)
;; Got answer:
; EDNS: version: 0, flags: do; udp: 4096
;apnic.net. IN A
;; ANSWER SECTION:
apnic.net. 3093 IN A 203.119.101.61
apnic.net. 3093 IN RRSIG A 13 2 3600 (
20200920005613 20200820235613 18494 apnic.net.
xqvWe8RSMV1o7dFkfSO95D5NPT71musyX0kCEyuORIsI
IMMyp9K6aaFPrNyjHkNExtYJHDF8do3+Ik4mk4TOWA== )
Validation disabled
on resolver
Show DNSSEC data ie. RRSIG
(set DO flag)DNSSEC enabled
on server
DNSSEC records
asked and shown
‘ad’ flag missing
Unvalidated response

$ dig @192.168.1.1 apnic.net. A +dnssec +multiline
; <<>> DiG 9.10.6 <<>> @192.168.1.1 apnic.net. A +dnssec +multiline
; (1 server found)
;; Got answer:
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;apnic.net. IN A
;; ANSWER SECTION:
apnic.net. 3599 IN A 203.119.101.61
apnic.net. 3599 IN RRSIG A 13 2 3600 (
20200920005613 20200820235613 18494 apnic.net.
xqvWe8RSMV1o7dFkfSO95D5NPT71musyX0kCEyuORIsI
IMMyp9K6aaFPrNyjHkNExtYJHDF8do3+Ik4mk4TOWA== )
Validation enabled
on resolver
(set DO flag)DNSSEC enabled
on server
DNSSEC records
asked and shown
‘ad’ flag present
Validated response

$ dig @192.168.1.1 www.dnssec-failed.org. A
; <<>> DiG 9.10.6 <<>> @192.168.1.1 www.dnssec-failed.org. A
; (1 server found)
;; Got answer:
; EDNS: version: 0, flags:; udp: 4096
;www.dnssec-failed.org. IN A
;; ANSWER SECTION:
www.dnssec-failed.org. 7134 IN A 69.252.193.191
Validation disabled
on resolver DNSSEC broken
on server
DNSSEC records
not asked

$ dig @192.168.1.1 www.dnssec-failed.org. A +dnssec +multiline
; <<>> DiG 9.10.6 <<>> @192.168.1.1 www.dnssec-failed.org. A +dnssec +multiline
; (1 server found)
;; Got answer:
;; ANSWER SECTION:
www.dnssec-failed.org. 6841 IN RRSIG A 5 3 7200 (
20200825175115 20200818144615 44973 dnssec-failed.org.
AWIeQ3Ab7aEKCCsdu7URLRyFUX6FJx2uHcHM1peJNNxY
0UEr1BTpCtbGoMqT5ImjHAff4/SNkhx2xkZLVt/qzp9L
kXW5XAUb2nLjy8XJt2uhpAeG9PW5lVzVulT4k4bDnM8d
JMnsuMhND/2fNDzQna0Pwe4yj/lbt58vaUdYoew= )
Validation disabled
on resolver
(set DO flag)DNSSEC broken
on server
DNSSEC records
asked and shown

$ dig @192.168.1.1 www.dnssec-failed.org. A +dnssec +multiline
; <<>> DiG 9.10.6 <<>> @192.168.1.1 www.dnssec-failed.org. A +dnssec +multiline
; (1 server found)
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64787
Validation enabled
on resolver
(set DO flag)DNSSEC broken
on server
DNSSEC broken

How to Understand a Validation Failure?
$ dig @192.168.1.1 www.dnssec-failed.org. +cd
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
All DNSSEC validation failures = “SERVFAIL”
So, how do I know failure because of validation?
$ dig @192.168.1.1 www.dnssec-failed.org.
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64787
Turning on cd (checking disabled) flag
Means, I’d like to disable DNSSEC validation for this query
Query without cd flag
Query with cd flag
Response: SERVFAIL
Unvalidated Response
Validation enabled
on resolver
Validation enabled
on resolver
DNSSEC broken
on server
DNSSEC broken
on server Checking disabled

Similar to a normal DNS
response. No DNSSEC
Validation, no ‘ad’ flag in
response packet.
Response contains RRSIG.
SERVFAIL
aka DNSSEC
validation fails
DNSSEC Validation
successful, Response
contains ‘ad’ flag and
RRSIG record.
dig with dnssec Flag
dig +dnssec
+cd set? +cd set?
DNSSEC fails?
(ad flag missing)
Yes
Yes Yes
No
No No

Summary of Steps
• DNS Resolver Operator
§ Configure resolver to perform DNSSEC validation
• DNS Zone operator
§ Sign zone(s) with DNSSEC
§ Secure zone transfers (typically with TSIG)
§ Obtain secure delegation (DS record) at parent zone

BIND DNSSEC Tools
• rndc
§ Does various command line tasks for named
• dnssec-keygen
§ Generate keys of various types
• dnssec-signzone
§ Sign a zone
• dig
§ Troubleshoot: dig +dnssec ...
• named-checkzone & named-checkconf
§ syntax check for zonefiles and named.conf

Setting up a Recursive Resolver
• In named.conf options:
options {
[...]
dnssec-validation auto;
[...]
};
$ dig @localhost apnic.net. A +dnssec +multiline
• Check:
yes
no
auto
Trust anchor is manually configured.
Keys are stored in trusted-keys config.
Validation is disabled. Resolver does
simple DNS resolution without validation.
Default trust anchor is the root.
BIND keeps it updated automatically.

Setting up an Authoritative Server
1. Enable DNSSEC in the config file
2. Generate key pairs (KSK and ZSK)
3. Publish your public key
4. Signing the zone
5. Publish the new zone file
6. Test the server
7. Push the DS record (in parent zone)
8. Test the server

Enable DNSSEC
• Enable DNSSEC in the configuration file (named.conf)
options {
[...]
dnssec-validation auto;
};

Generate Keys
• For KSK, add: -f KSK
• For NSEC3 capable keys, add: -3
• To add source of randomness, add: -r /dev/urandom
dnssec-keygen -a <ALG> -b <BIT> -n ZONE <ZONE_NAME>

Generate Keys
• Better to keep keys in a separate directory, e.g. /etc/bind/keys
dnssec-keygen -a RSASHA256 -b 1024 -n ZONE example.com
dnssec-keygen -a RSASHA256 -b 1024 –f KSK -n ZONE example.com
• NSEC3 capable keys with ECDSA algorithm (‘-b’ part is not necessary):
dnssec-keygen –a ECDSAP256SHA256 -3 example.com
dnssec-keygen -a ECDSAP256SHA256 -3 –f KSK example.com
• Source of randomness might be required, add: -r /dev/urandom
• Required the permission for ‘bind’ to access the keys

Generate Keys: Example
# mkdir /etc/bind/keys
# cd /etc/bind/keys
# dnssec-keygen -r /dev/urandom -a RSASHA256 -b 1024 -n ZONE example.com
Generating key pair............++++++
Kexample.com.+008+61938
# dnssec-keygen -r /dev/urandom -a RSASHA256 -b 2048 -f KSK -n ZONE example.com
Generating key pair.......... +++ ................+++
Kexample.com.+008+29869
Kexample.com.+008+29869.key
Kexample.com.+008+29869.private
Kexample.com.+008+61938.key
Kexample.com.+008+61938.private
• 4 files for 2 key pairs should be created:
.key = public key
.private = private key

Generate Keys: Example
# cat Kexample.com.+008+29869.key
; This is a key-signing key, keyid 29869, for example.com.
; Created: 20200902075041 (Wed Sep 2 08:50:41 2020)
; Publish: 20200902075041 (Wed Sep 2 08:50:41 2020)
; Activate: 20200902075041 (Wed Sep 2 08:50:41 2020)
example.com. IN DNSKEY 257 3 8 AwEAAdOs12wtLc9lg7......
# cat Kgov.bd.+008+61938.key
; This is a zone-signing key, keyid 61938, for example.com.
; Created: 20200902075024 (Wed Sep 2 08:50:24 2020)
; Publish: 20200902075024 (Wed Sep 2 08:50:24 2020)
; Activate: 20200902075024 (Wed Sep 2 08:50:24 2020)
example.com. IN DNSKEY 256 3 8 AwEAAbh/q5unt90......
• More info about the keys:

1. Publish the Public Keys
• Publish the public keys (DNSKEY RR) inside the zone file
• You can also manually enter the DNSKEY RR in the zone file
• Or, add the key directory in the zone configuration
$INCLUDE “/path/Kexample.com.+008+29869.key”; KSK
$INCLUDE “/path/Kexample.com.+008+61938.key”; ZSK
zone "example.com" in {
[...]
key-directory "/etc/bind/keys";
};

2. Sign Zone with Keys
• Once you sign the zone a file with a .signed extension will be created
§ e.g. db.example.com.signed
dnssec-signzone –o <zonename> -N INCREMENT -k <KSK> <zonefile> <ZSK>

2. Sign Zone with Keys: Example
# cd /etc/bind/keys
# dnssec-signzone –o example.com -N INCREMENT -k Kexample.com.+008+29869
db.example.com Kexample.com.+008+61938
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
[...]
[...]

2. Sign Zone with NSEC3
• Using dnssec-signzone command:
• Generate 16-character string for salt
• Using rndc utility:
rndc loadkeys <zonename>
rndc signing -NSEC3PARAM 1 0 10 <salt> <zonename>
dnssec-signzone -3 <salt> -A -N INCREMENT -o <zonename> -t <zonefile>
-A: set opt-out flag, do not sign insecure delegations
-H <iterations>: num of hash iterations (def 10)
head -c 1000 /dev/random | sha1sum | cut -b 1-16

2. Sign the Zone
• Note that only authoritative records are signed
§ NS records for the zone itself are signed
§ NS records used for delegations are not signed
§ DS records for delegated zones are signed
§ Glue records are not signed
• Notice the difference in file size
§ db.example.com vs. db.example.com.signed

3. Publish the Signed Zone File
• Reconfigure to load the signed zone
• Edit named.conf and point to the signed zone
zone “example.com.” {
type master;
#file “db.example.com”;
file “db.example.com.signed”;
};
zone “192.168.100.in-addr.arpa.” {
type master;
#file “db.192.168.100”;
file “db.192.168.100.signed”;
};

DNSSEC Inline Signing
• Avoid administrative overhead of resigning zones
§ BIND does that automatically
zone "example.com" in {
type master;
file ”db.example.com";
key-directory "/etc/bind/keys";
inline-signing yes;
auto-dnssec maintain;
};
Where named should look
for the DNSSec key files
BIND keeps unsigned zone
and creates a signed zone
off
allow
maintain
Default. Keys are managed manually
Allows uploading keys and resigning the zone
when user runs “rndc-sign [zone-name]”
Same as “allow” +automatically
adjusts the keys on schedule

DNSSEC Inline Signing
• Update configuration and reload
• New files created after auto-signing:
example.com example.com.jbk example.com.signed example.com.signed.jnl
# rndc reconfig
# rndc loadkeys example.com
# rndc signing –list example.com

Publish the DS Record in Parent Zone
• The DS record must be published by the parent zone
• Once signed, BIND creates the DS file automatically:
• Can also be generated manually:
# cat dsset-example.com.
example.net. IN DS 29869 8 1 42727823EB40A1D93......
example.net. IN DS 29869 8 2 BC34B1EA3196C01EEFCC4C571B6175......
# cd /etc/namedb/keys
# dnssec-dsfromkey -a SHA-1 Kexample.net.+008+29869.key
example.net. IN DS 29869 8 1 42727823EB40A1D93......
# dnssec-dsfromkey -a SHA-256 Kexample.net.+008+29869.key
example.net. IN DS 29869 8 2 BC34B1EA3196C01EEFCC4C571B6175......

Test the Server
• Ask a dnssec-enabled server and see whether the answer is signed
$ dig @192.168.1.1 example.com. A +dnssec +multiline
; <<>> DiG 9.10.6 <<>> @192.168.1.1 example.com. A +dnssec +multiline
; (1 server found)
;; Got answer:
;example.com. IN A
;; ANSWER SECTION:
example.com. 3599 IN A 203.119.101.61
example.com. 3599 IN RRSIG A 13 2 3600 (
20200920005613 20200820235613 18494 example.com.
xqvWe8RSMV1o7dFkfSO95D5...... )

Key Management and Zone Re-signing
• Key management
§ Using Hardware Security Module (HSM)
§ Some people use hidden primary NS
• Zone re-signing
§ BIND can be configured to manage it automatically
§ Task scheduling e.g. crontab

Resolver
10.10.1.10
2001:db8:d::10
User PC
10.10.1.2
2001:db8:d::2
root (.)
bd &
gov.bd
ns1.bcc.gov.bd
203.0.113.10
2001:db8:c::10
Zone data
synchronization
ns2.bcc.gov.bd
203.0.113.20
2001:db8:c::10
bcc.gov.bd
dns.bd
198.51.100.10
2001:db8:b::10
a.root-servers.net
192.0.2.10
2001:db8:a::10
Internet
Lab Topology

NSEC: Canonical Order
• Needed because of the pre-computed signature model of DNSSEC
• Names are sorted in order of most significant (rightmost) labels first
§ If it is identical, next most significant label is sorted, and so forth
§ Within each label, sorting is done by octet strings
§ Uppercase ASCII letters are treated as lowercase
example.com
a.example.com
blah.a.example.com
Z.a.example.com
zABC.a.EXAMPLE.com
test.example.com
z.example.com
example.com
zABC.a.EXAMPLE.com
a.example.com
blah.a.example.com
z.example.com
Z.a.example.com
test.example.com

NSEC: An authenticated negative answer (nxdomain)
• If the server responds NXDOMAIN
§ One or more NSEC RRs indicate that the name (or a wildcard) does not exist
113
dig +dnssec +multiline bozo.upenn.edu. A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32006
;; AUTHORITY SECTION:
box.upenn.edu. 600 IN NSEC Budget.upenn.edu. A RRSIG NSEC
box.upenn.edu. 600 IN RRSIG NSEC 13 3 600 (
20200905172738 20200806171300 54481 upenn.edu.
9cbshFKMkQ0yn+tGVGvspp2mFrHH...... )
upenn.edu. 600 IN NSEC _dmarc.upenn.edu. A NS SOA MX AAAA RRSIG NSEC DNSKEY
upenn.edu. 600 IN RRSIG NSEC 13 2 600 (
20200918035156 20200819031904 54481 upenn.edu.
kw2k+hl38n92gMCOWyocpd12rxP8...... )
<some parts omitted for brevity>

NSEC: An authenticated negative answer (nodata)
• If the server responds NOERROR with empty ANSWER section
§ The NSEC proves that the TYPE does not exist
dig +dnssec +multiline www.upenn.edu. MX
www.upenn.edu. 600 IN NSEC dev.www.upenn.edu. A AAAA RRSIG NSEC
www.upenn.edu. 600 IN RRSIG NSEC 13 3 600 (
20200830132120 20200731123000 54481 upenn.edu.
Y9uIjU8kXk5hmKomemDLCcIi1egvd...... )

NSEC3: An authenticated negative answer (nxdomain)
115
dig +dnssec +multiline blah.apnic.net. A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31286
q4j3fefpb3975rnh4jndh8g99dquc51s.apnic.net. 1799 IN NSEC3 1 1 10 5D3EF9B0 (
Q668SAL2DPIVRRM7OUNNBPA1KF5MAG60
A RRSIG )
q4j3fefpb3975rnh4jndh8g99dquc51s.apnic.net. 1799 IN RRSIG NSEC3 13 3 3600 (
20200920005613 20200820235613 18494 apnic.net.
EHL4x77Rh+kR1LcMc7Fzv3vyy+rPM9I...... )
rb722p5l5thsub27ha4keh6skch8v130.apnic.net. 1799 IN NSEC3 1 1 10 5D3EF9B0 (
RCBKT0NIO12KSD2BSTI5I6EI17TEK986
A NS SOA MX TXT AAAA RRSIG DNSKEY NSEC3PARAM )
rb722p5l5thsub27ha4keh6skch8v130.apnic.net. 1799 IN RRSIG NSEC3 13 3 3600 (
20200920141500 20200821131500 18494 apnic.net.
/ZFJEzX5VWkhrI2AdlOeJGuEF16bbgr...... )
v5rbau2r3rsf8d20tgqo7v6bq6lbgdu6.apnic.net. 1799 IN NSEC3 1 1 10 5D3EF9B0 (
V9JG4FABPIIQ24M9ML37K08ULPAEC83F
A RRSIG )
v5rbau2r3rsf8d20tgqo7v6bq6lbgdu6.apnic.net. 1799 IN RRSIG NSEC3 13 3 3600 (
20200920005613 20200820235613 18494 apnic.net.
CC+3MdpT87QBJTu6f2ehY5MFXXOyxcj...... )<some parts omitted for brevity>
Matches “closest encloser”
(e.g. apnic.net)
Covers “next closer name”
(e.g. abc.apnic.net)
Covers wildcard at
closest encloser
(e.g. *.apnic.net)

NSEC3: An authenticated negative answer (nodata)
dig +dnssec +multiline www.isoc.org. NS
ELTTS8QOIMIFN0UR34MHT59AB1CJS4S0.isoc.org. 1799 IN NSEC3 1 0 10 4F83F5 (
ENT5GFN05TATEU4P979DCUQ532AVO85E
A MX AAAA RRSIG )
ELTTS8QOIMIFN0UR34MHT59AB1CJS4S0.isoc.org. 1799 IN RRSIG NSEC3 7 3 3600 (
20200903205003 20200820205003 9629 isoc.org.
n3uWQp5noMqI/hc4q4EZ6CSxy+YpznVSa0sU7QIdqjVu
pyCLra5KwxVTrihvp9zMN2nYjM8uNRM+tGGb10t6sDtH
MYALxYi89e1u4jy5UJQS4VdmTIhkx8WNJZPXEJFwKGpf
VjhFNZNS3cPDTacUXGI+sqGjeHevoKYP2y1jU48= )

NSEC or NSEC3?
• No single right answer that fits everyone
§ Depends on needs or requirements
• If zone-walk defence is required, NSEC3 paired with a periodically changed
salt would work better
§ However, someone could still randomly guess names like "ftp" or "www”
• If you have many many delegations, and have a need for opt-out to save
resources, NSEC3 is for you
• NSEC is typically a good choice for most zone administrators
§ it relieves the authoritative servers from the additional cryptographic operations
§ NSEC is comparatively easier to troubleshoot than NSEC3

DNSSEC Key Rollover
• Key rollover limits effects of key compromise
• Typically, ZSKs are rolled over more frequently
§ This can be done transparently, and with no co-ordination with the
parent zone
• KSKs are rolled less frequently
§ This does require co-ordinating with the parent zone to sign and install
new DS records for the KSKs
• Must keep the chain of trust intact while rolling over the keys

DNSSEC Key Metadata
Metadata Included in
Zone File?
Used to Sign
Data?
Purpose
Publish Yes No Introducing a key soon to be active
Activate Yes Yes Activation date for new key
Revoke Yes Yes Notifying a key soon to be retired
Inactive Yes No Inactivate or retire a key
Delete No No Deletion or removal of key from zone

ZSK Rollover
• Double signature
§ Publish the new ZSK and sign the zone with the new key alongside the old one
o Essentially double the size of the zone due to the additional RRSIG for each RRset
§ Wait at least one TTL before removing the old ZSK and old RRSIG.
• Pre-publish
§ Publish the new ZSK into zone data (but do not yet sign zone data with it)
§ Wait at least one TTL so the world's recursive servers know about both keys
§ Stop using the old key and generate new RRSIG using the new key
§ Wait at least one TTL, before removing the old key and re-sign DNSKEY RRset
• The pre-publish tends to be preferred as it doesn’t increase the zone size

ZSK Rollover
122
Current ZSK
New ZSK
Double signature
Method
Pre-publish
Method
Publish New
ZSK
Stop using
current ZSK
and Sign zones
with new ZSK
Remove
old ZSK
> TTL
Preferred
> TTL
Current ZSK
New ZSK
> TTL
Sign zones with
new ZSK alongside
the old ZSK
Remove
old ZSK

KSK Rollover
• Double signature method:
§ Introduce a new KSK in to the DNSKEY RRset
§ Sign the ZSK with both the current ("old") KSK, and the new KSK
§ After sufficient amount of time, substitute the DS record with the new one in
the parent zone
§ Sign the zone with only the new KSK
• Pre-publish method:
§ Publish the DS for the new KSK to the parent zone alongside the existing one
§ After a sufficient amount of time has elapsed, replace the current ("old") KSK
with the new one and sign the ZSK with the new KSK
• The double signature tends to be preferred as it doesn't require that the
parent be able to handle multiple DS records for each child zone

KSK Rollover
DS of current KSK DS of new KSK
Current KSK
New KSK
Current KSK New KSK
DS of current KSK
DS of new KSK
Parent
Child
Parent
Child
Double signature
Method
Pre-publish
Method
Sign ZSK with New
KSK alongside the
current KSK
DS Change
(Parent)
Remove
old KSK
Publish New DS
(Parent)
Sign ZSK with
new KSK
Remove old DS
(Parent)
> KSK_TTL > DS_TTL
> DS_TTL > KSK_TTL
Preferred

Hands-on DNSSEC Deployment

More Related Content

What's hot

Similar to Hands-on DNSSEC Deployment

More from Bangladesh Network Operators Group

Hands-on DNSSEC Deployment