DNSSEC Fundamentals

OPEN TUTORIAL
12 August 2025

2 v1.0
Overview
• DNSSEC Technical Overview
• DNSSEC Validation
• DNSSEC Zone Signing

3 v1.1
Pre-requisites
• This tutorial assumes that you understand
o DNS operations and delegation
o Cryptography concept and algorithms

4 v1.1
DNSSEC Technical Overview

5 v1.1
Why DNSSEC
• What aspects of DNS do we need security?
- DNS data which can be corrupted
- Transactions between DNS servers and clients
- Privacy of DNS queries/requests
- Validity of DNS data received (not tampered, confirmed source)

• How to check the validity of DNS data?

- DNSSEC is used for this

• How do we add security?

- By adding cryptography

6 v1.1
DNS Vulnerabilities

Corrupting data Impersonating master

Cache impersonation
Zone administrator
1
4
Zone file Primary DNS Recursive DNS/
Caching forwarder

2
3 5

Dynamic
updates Secondary
DNS Resolver/Host
Cache pollution by
Data spoofing
Unauthorized updates

Server protection Data protection

7 v1.1
DNS Cache Poisoning

3
1 www.example.com 192.168.1.99
I want to access www.example.com 2001:DB8::9
www.example.com QID=64569
(pretending to be
QID=64570 the authoritative
zone)
QID=64571 match!
2
QID=64571
Root/GTLD
Client DNS Caching
Server

QID=64571
3
www.example.com 192.168.1.1
www.example.com 2001:DB8::1
ns.example.com
Webserver
(192.168.1.1
2001:DB8::1)

8 v1.1
DNSSEC

Cache impersonation
Zone administrator

Zone file Primary DNS Recursive DNS /

Caching Forwarder

Dynamic
updates
Secondary DNS
Resolver/Host

Cache pollution by
Data spoofing

9 v1.1
Crypto & DNSSEC
• Crypto provides confidentiality, integrity, authenticity and non-
repudiation
o For DNSSEC, we need integrity & authenticity
o DNSSEC is not concerned with encrypting DNS data

• DNSSEC uses digital signatures

o Hash of the data is signed (using private key) at the source
o Data+Signature sent to destination
o Hash of the data is compared with decrypted Signature (using public
key)
o If match, data is verified

10 v1.1
What is DNSSEC?
• DNS Security Extensions
• Protects the integrity of data in DNS
• A form of digitally signing the data to attest its validity
• Provides a mechanism to:
o establish authenticity and integrity of data
o delegate trust to third parties or parent zones

11 v1.1
How DNS Works – Resolution

1) Sends query to local dns 2) Sends recursive query

what is the IP address apnic.net A?
of apnic.net?

Recursive DNS Authoritative DNS

Host (apnic.net)
4) Send record to host 3) Sends DNS record
apnic.net A 203.119.102.1 apnic.net A 203.119.102.1

12 v1.1
How DNSSEC Works

1) Sends query to local dns 2) Sends recursive query

what is the IP address apnic.net A?
of apnic.net?

Host Recursive DNS Authoritative DNS

(apnic.net)
Performs validation Signs zones/records
3) Sends record & signature
4) Send validated record to host
apnic.net A 203.119.102.1 ✅ apnic.net A 203.119.102.1
apnic.net signature

13 v1.1
How DNSSEC Works
Authoritative server
- Signs the zones
- Answers queries with the record requested
- Also sends the digital signature corresponding to the record DNS Auth Server

Validating Resolvers
- Authenticates the responses from the server
- Data that is not validated results to a “SERVFAIL” error

DNS Resolver

14 v1.1
How DNSSEC Works
• Records are signed with private key to prove its authenticity and
integrity
• The signatures are published in DNS
• Public key is also published so record signatures can be verified
• Child zones also sign their records with their private key
• Parent signs the hash of child zone public key to prove authenticity

15 v1.1
How DNSSEC Works
• RRsets are signed with private key to prove its authenticity and
integrity
• The signatures are published in DNS as RRSIG
• Public DNSKEY is also published so RRSIG can be verified
• Child zones also sign their records with their private key
• Parent signs the child zone’s DS record to prove authenticity

16 v1.1
New Resource Records

Resource Record Function

RRSIG Resource Record Signature Signature over RRset made using

private key
DNSKEY DNS Key Public key needed for verifying a
RRSIG
DS Delegation Signer Pointer for building chains of
authentication
NSEC / NSEC3 Next Secure indicates which name is the next one
in the zone and which type codes are
available for the current name

17 v1.1
RRs and RRsets
• Resource Record – each entry in the zonefile

www.example.net. 7200 IN A 192.168.1.1

• RRset - RRs with same name, class and type

www.example.net. 7200 IN A 192.168.1.1

web1.example.net. 7200IN A 10.0.0.1
web2.example.net. 7200IN A 172.16.0.20

In DNSSEC, RRsets are signed and not the individual RRs

18 v1.1
New Resource Record – RRSIG
• Resource Record Signature
• The private part of the key-pair is used to sign the resource record set
(RRset)
• The digital signature per RRset is saved in an RRSIG record
RR type signed Digital signature algorithm
Number of labels in the
signed name

apnic.net. 3595 IN A 203.119.101.61

apnic.net. 3595 IN RRSIG A 13 2 3600 (
20220520101020 20220421084020 50453 apnic.net.
tO046TNbVsZW3FaqsH2C2iYrlFm3Jp9T65wrOXFLhnAg
TO72QpkYMTMN770UJ9hiq/EHtfuMnqFY/gtxKUT6Xw== )

Signature expiry
Date signed

19 v1.1
New Resource Record – DNSKEY
• Contains the zone’s public key
• Uses public key cryptography to sign and authenticate DNS resource
record sets (RRsets)

16-bit field flag; 256 if ZSK, 257 if KSK

Protocol octet
DNSKEY algorithm number
apnic.net. 3600 IN DNSKEY 257 3 13
3NbLPP4IDRHT01x4y3NtKQrJ0L6yb5Gz9q7ftsX9em4vPnqcvCHLqMLM
Zdd441f3ZwsF3C0JHT0+sVj+a34KfA== Public key (base64)

apnic.net. 3600 IN DNSKEY 256 3 13

YZAtlOXa22wFILAd99YPseUJKuH2zAch+jH6aLk4xBik29Ki3ImyJcSz
fr0TGhoxQ+0W8haZNvcIs+z7EEkOvw==

20 v1.1
New Resource Record – DS
• Delegation Signer
• Establishes authentication chains between DNS zones
• Must be added in the parent’s zonefile
• In this example, irrashai.net has been delegated from .net. This record
is added in the.net zone file

Key ID
DNSKEY algorithm
Digest type: 1 = SHA1 or 2 = SHA256

apnic.net. 14232 IN DS 18078 13 2

1D50476FDE7E2578A3674EAFB15AE7D490D9DD9C6A1AF79C41107A09 3D224C34

21 v1.1
New Resource Record – NSEC
• Next Secure
• Forms a chain of authoritative owner names in the zone
• Also proves the non-existence of a domain
• Each NSEC record also has a corresponding RRSIG

myzone.net. NSEC blog.myzone.net. A NS SOA MX RRSIG NSEC DNSKEY

23 v1.1
New Resource Record - NSEC3
• NSEC allows an attacker to walk through the linked list to find all the
records in the zone file. This is called zone walking
• NSEC3 uses a hashing algorithm to list the next available domain in
“hashed” format
• It is still possible for an attacker to do zone walking, although at a
higher computation cost

0907n2ptm63c74h9fq9t07r98ias4spc.apnic.net. 3600 IN NSEC3 1 1 5 F25EFEEAB38712CB

0988Q0KHJI2649DSNEBJASV7R295RE0S A NS SOA MX TXT AAAA RRSIG DNSKEY NSEC3PARAM
CDS CDNSKEY

24 v1.1
DNSSEC Delegation

DNS Delegation With DNSSEC

PARENT ZONE
Parent adds NS record Also adds DS record
of child zone of child zone

Child zone adds NS record Generate a hash of its

CHILD ZONE
for authoritative servers public key

25 v1.1
New Resource Records – CDS and CDNSKEY
• Child Delegation Signer
• Child DNS Key

• conveys to the Parent the desired content of the DS resource record

set (which resides in the parent)

7344
26 v1.1
Chain of Trust
• DNSSEC follows this chain of trust .

DS
• Establishes a chain of trust from parent to child zone
net
o Parent does not sign child zone
o Parent only signs a pointer to the child zone (key) DS

apnic.net
• The root is on top of the chain (also called trust anchor)
DS

abc.apnic.net

27 v1.1
Trust Anchor
• Trust anchor is an authoritative entity for which trust is assumed, not
derived.

• DNSSEC signatures are validated by following a chain of signatures to

a trust anchor.
- This can be any trust anchor
- Root DNS maintained by IANA preferred

7958
28 v1.1
Trust Anchor – Root Zone
<TrustAnchor id="380DC50D-484E-40D0-A3AE-68F2B18F61C7" source="http://data.iana.org/root-
anchors/root-anchors.xml">
<Zone>.</Zone>
<KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00" validUntil="2019-01-
11T00:00:00+00:00">
<KeyTag>19036</KeyTag>
<Algorithm>8</Algorithm>
<DigestType>2</DigestType>
<Digest>49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</Digest>
</KeyDigest>
<KeyDigest id="Klajeyz" validFrom="2017-02-02T00:00:00+00:00">
<KeyTag>20326</KeyTag>
<Algorithm>8</Algorithm>
<DigestType>2</DigestType>
<Digest>E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D</Digest>
</KeyDigest>
</TrustAnchor>

https://data.iana.org/root-anchors/root-anchors.xml

29 v1.1
DNSSEC Keys
• In practice, we use two keypairs
o one to sign the zones, another to sign the other key
o Unless using Combined Signing Key (CSK)

• Using a single key or both keys is an operational choice (RFC allows both
methods)

• If using a single key-pair:

o Zones are digitally signed using the private key
o Public key is published using DNSKEY RR
o When key is updated, DS record must again be sent to parent zone

• To address this administrative load, two keypairs will be used

30 v1.1
Types of Keys
Zone Signing Key (ZSK)
Sign the RRsets within the zone
Signed by the KSK
Uses flag 256

Key Signing Key (KSK)

Signs the ZSK
Pointed to by the parent zone
Acts as the security entry point

Common Signing Key (KSK)

Used for both

31 v1.1
Signature Expiration
• Keys do not expire
o Still a good practice to generate new ones regularly for added security

• Signatures have validity period

o By default, set to 30 days
o This info is added in the key metadata

• Expired signatures will not validate

o Must re-sign the zones

32 v1.1
DNSSEC Algorithms

Number Description Mnemonic

5 RSA/SHA-1 RSASHA1 SHA-1 has long been deprecated 8624
Does not support NSEC3
8 RSA/SHA-256 RSASHA256 Widely used, considered strong
10 RSA/SHA-512 RSASHA512 No significant difference than RSASHA256
12 GOST R 34.10-2001 ECC-GOST Superseded by GOST R 34.10-2012, but not standardized for DNSSEC
13 ECDSA Curve P-256 ECDSAP256SHA256 Shorter key and signature, thus smaller DNS packet
with SHA-256 Industry-wide trend to move to EC driven by large DNS operators

14 ECDSA Curve P-384 ECDSAP384SHA384 Similar to #13, modest security advantage

with SHA-384
15 Ed25519 ED25519 Will become the recommended default algorithm once there is more
adaption
16 Ed448 ED448 Not widely used yet

http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

33 v1.1
DNSSEC Algorithms – RFC 8624

http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

34 v1.1
DNSSEC Algorithms – Statistics (as of 25/04/2022)

https://stats.dnssec-tools.org/
35 v1.1
DNSSEC Validation

36 v1.1
How DNSSEC Validation Works (Diagram)

1) Sends query to local dns 2) Sends recursive query

what is the IP address apnic.net A? DO bit
of apnic.net?

Host Recursive DNS Authoritative DNS

(apnic.net)
Performs validation Signs zones/records
4) Send validated record to host 3) Sends record & signature
apnic.net A 203.119.102.1 ✅ apnic.net A 203.119.102.1
apnic.net signature
AD bit

apnic.net A 192.168.1.100 A bad actor can fake/tamper

SERVFAIL ❌ apnic.net signature both the record and key

37 v1.1
How DNSSEC Validation Works (Diagram)

Records in Recursive DNS:

apnic.net A Y
S K EY NS K E
apnic.net RRSIG (A) N
. D SIG D
R Root DNS
.R
apnic.net DNSKEY D S G DS
) t
ne R R S I
apnic.net RRSIG (DNSKEY) (DO
K EY ? ne t
NS
apnic.net DS .D
DO)
apnic.net RRSIG (DS) ? (
t DS
n e
(DO) D N S K EY S K EY
net DNSKEY E Y ? ne t
IG D
N
NS K R R S
net RRSIG (DNSKEY) ne t D ne t Auth DNS
S (net)
n i c. net D SIG DS
ap R
net DS S ? (DO) n i c. ne t R
. ne t D ap
net RRSIG (DS) apnic
apnic.net DNSKEY?
. DNSKEY
. RRSIG (DNSKEY) apnic.net DNSKEY
Recursive DNS Apnic.net RRSIG DNSKEY Auth DNS
(apnic.net)

38 v1.1
DNSSEC in the Resolver
• Recursive servers that are DNSSEC-enabled (or security-aware) can
validate signed zones

• To enable DNSSEC validation: dnssec-validation yes|auto;

• The AD bit in the message flag shows if validated

39 v1.1
DNSSEC Validation

dig @localhost www.apnic.net +dnssec +multiline

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

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

;; ANSWER SECTION:
www.apnic.net. 300 IN CNAME www.apnic.net.cdn.cloudflare.net.
www.apnic.net. 300 IN RRSIG CNAME 8 3 300 ( 20190608045355
20190509035355 43023 apnic.net.
oX8qHhFXJLyu3TKru/1sGrDZnnyq3+aI2zhIFk6IF6PK
nTXrzFE/USOjDffJI5+x3QAzPzBKDKXB1+XaXHq1lgw9
Mw6i3mx+NTkjfq7m1bN/wbZD8ddzjY1GK4lrZ/zM39WL
5GQ+2ryIMY0aQFdQzufnHkGHMlqJM6fbHdREwPY= )

40 v1.1
DNSSEC Validation

;; ->>HEADER<<- opcode: QUERY, status:

NOERROR, id: 47652 'ad’ bit – authenticated data
;; flags: qr rd ra ad; QUERY: 1,
ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; >>HEADER<<- opcode: QUERY, status:

SERVFAIL, id: 21978 If dnssec validation is yes, and
;; flags: qr rd ra; QUERY: 1, ANSWER: validation fails
0, AUTHORITY: 0, ADDITIONAL: 1

41 v1.1
DNSSEC Validation
• Other options if you don’t have a validating resolver
o Online web tools
o Browser plugins

• Use public DNS server

dig @1.1.1.1 www.apnic.net +dnssec +multiline
dig @8.8.8.8 www.apnic.net +dnssec +multiline

42 v1.1
DNSSEC Validation
Without validation With validation

43 v1.1
DNSSEC Validation

Without validation With validation

44 v1.1
DNSSEC For Network Service Providers
• Enable DNSSEC on your recursive servers and validate responses
o Deploy DNSSEC-validating resolvers

• Before you fully implement:

o Domains that can’t be validated will be inaccessible
o Be prepared to answer helpdesk queries related to this

45 v1.1
DNSSEC for End Users
• Use a dnssec-validating resolver
• If not available, use other tools (such as browser plugin)

46 v1.1
DNSSEC Validation

https://stats.labs.apnic.net/dnssec

47 v1.1
DNSSEC Zone Signing

48 v1.1
DNSSEC Deployment Map

https://www.internetsociety.org/deploy360/dnssec/maps/

49 v1.1
DNSSEC Deployment Maps (AP)

https://www.internetsociety.org/deploy360/dnssec/maps/

50 v1.1
DNSSEC for Registries and Hosting Providers
• Sign your zones

• Before fully implementing:

o Plan about key rollover
o Think about securing your keys
o What happens if your key gets compromised

• Support more and newer algorithms (such as ECDSA)

51 v1.1
DNSSEC – Deploy a Secure Zone (Manual)
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 zonefile
6. Test the server
7. Push the DS record (to parent zone)

52 v1.1
Enable DNSSEC
• Enable DNSSEC in the configuration file (named.conf)
options {
Notes: For BIND9:
directory “….” • Auto – uses trust-anchor for DNS root
dnssec-enable yes; automatically
dnssec-validation yes|no|auto; • Yes – trust anchor explicitly configured
• No – no DNSSEC validation
};

• Other options to automate signing and key rollover

auto-dnssec { off | allow | maintain} ;

53 v1.1
Generating Keypairs
• Generate ZSK and KSK

dnssec-keygen -a rsasha256 -b 1024 -n zone <myzone>

Or simply:
Notes: Algorithm and keysize is an
dnssec-keygen –f KSK <myzone> operational choice, but generally:
- ECDSA is recommended
- Keysize must be at least 2048 for KSK

• This generates four files.

o Note: There has to be at least one public/private key pair for each
DNSSEC zone

54 v1.1
Generating Keypairs
• To create ZSK

dnssec-keygen -a rsasha256 -b 1024 -n zone myzone.net

• To create KSK

dnssec-keygen -a rsasha256 -b 2048 -f KSK -n zone myzone.net

55 v1.1
Generating Keypairs
• To create ZSK

dnssec-keygen -a rsasha256 -b 1024 -n zone

100.168.192.in-addr.arpa

• To create KSK

dnssec-keygen -a rsasha256 -b 2048 -f KSK -n zone

100.168.192.in-addr.arpa

56 v1.1
Generating Keypairs - Using NSEC3
• Generate keys
dnssec-keygen -r /dev/urandom -a RSASHA256 -3 -b 1024 -n
ZONE irrashai.net

dnssec-keygen -r /dev/urandom -f KSK -a RSASHA256 -b 2048 -

3 -n ZONE irrashai.net

57 v1.1
Publishing the public key
• A few options to do this:
o Using $INCLUDE you can call the public key (DNSKEY RR) inside the
zone file
$INCLUDE /path/Kmyzone.net.+005+33633.key ; ZSK
$INCLUDE /path/Kmyzone.net.+005+00478.key ; KSK

o You can also manually enter the DNSKEY RR in the zone file
o Or add the files into a key directory
zone { key-directory “/etc/bind/keys”; };

58 v1.1
Signing the zone
Notes: Most of the following steps have
• Sign the zone using the secret keys: been automatically done by the software.
The manual steps are shown to understand
the signing process.

dnssec-signzone –o <zonename> -N INCREMENT -f <output-file> -k <KSKfile>

<zonefile> <ZSKfile>

dnssec-signzone –o myzone.net db.myzone.net Kmyzone.net.+005+33633

• Once you sign the zone a file with a .signed extension will be created
db.myzone.net.signed

59 v1.1
Signing the zone
• Note that only authoritative records are signed
o NS records for the zone itself are signed
o NS records used for delegations are not signed
o DS records are signed
o Glue records are not signed

• Notice the difference in file size

o db.myzone.net vs. db.myzone.net.signed

60 v1.1
Inline Signing
• Searches the key repository for any keys that will match the zone
being signed

options {
keys-directory { “path/to/keys”;
};

• Then the zone statement must have these lines:

auto-dnssec maintain;
inline-signing;

61 v1.1
Inline Signing
• Then use RNDC to load the new keys and do inline signing.

rndc reconfig
rndc loadkeys myzone.net
rndc signing –list myzone.net

From BIND 9.16, dnssec-policy configuration option can be used to specify Key and
Signing Policy. This may soon replace auto-dnssec and inline-signing.

62 v1.1
Using NSEC3
• Load the keys and sign the zone
rndc loadkeys irrashai.net
rndc signing –NSEC3PARAM 1 0 10 <some-salt> irrashai.net.

o To randomly generate a salt used above

openssl rand -hex 4

• Get the DS record and upload to the parent zone

dig @localhost dnskey irrashai.net | dnssec-dsfromkey -f –
irrashai.net

63 v1.1
Publishing the new Zone File
• Reconfigure to load the signed zone. Edit named.conf and point to the
signed zone.

zone “<myzone>” {
type master;
# file “db.myzone.net”;
file “db.myzone.net.signed”;
};

64 v1.1
Publishing the new Zone File
• Reconfigure to load the signed zone. Edit named.conf and point to the
signed zone.

zone “<myzone>” {
type master;
# file “db.192.168.100”;
file “db.192.168.100.signed”;
};

65 v1.1
Test the server
• Ask a dnssec-enabled server and see whether the answer is signed

dig @localhost www.apnic.net +dnssec +multiline

66 v1.1
Testing with Dig
dig @localhost www.irrashai.net +dnssec (+multiline)

67 v1.1
Testing with Dig
dig @localhost -x 192.168.100.100 +dnssec

68 v1.1
Pushing the DS Record to the Parent Zone
• The DS record must be published by the parent zone
• Contact the parent zone to communicate the KSK to them

• The following RFCs address this:

o RFC 7344 : Automating DNSSEC Delegation Trust Maintenance
o RFC 7477 : Child to Parent Synchronization in DNS
o RFC 8078 : Managing DS Records from the Parent via CDS/CDNSKEY

69 v1.1
Pushing the DS Records for Forward Zone

Example form for Godaddy

70 v1.1
Pushing the DS Record for Reverse Zone

Using MyAPNIC

DS record added in the

domain object in a ds-rdata field

71 v1.1
Tools: DNSViz

DNSViz can be used to see the chain of authentication

72 v1.1
Ways to Deploy DNSSEC
• As part of the DNS software used
DNSSEC tools for BIND,
o Manual key management NSD, PowerDNS, etc

o Can be quite complex

o For static environment
o Some means of automation
HSM,
• Use with a hardware security module (HSM) OpenDNSSEC

o Semi-automatic
DNS Appliance
o Good for dynamic environment
• Using an external appliance 73

o ‘dnssec-in-a-box’
o Fully automates key generation, signing and rollover

73 v1.1
DNSSEC Signer Appliance

DNS Master DNSSEC Signer DNS Server

• Creates the zones as • Signs the zones • Answer queries
per usual • Propagates the signed
zones

• Can be a pure signer or packaged with an IPAM or a DNS server

• In pure signer, the hardware appliance interfaces between the
master/slave servers

74 v1.1
75 v1.1
Thank You!
Thank You!
END OF SESSION
END OF SESSION

76 v1.1