DNS Security Tutorial

Champika Wijayatunga (ICANN) and Phil Regnauld (NSRC)

|1
DNS Concepts

|2
DNS in a nutshell

● DNS is a distributed database

⁃ Data is maintained locally but available globally
● Resolvers send queries
● Name servers answer queries
● Optimizations:
⁃ Caching to improve performance
⁃ Replication to provide redundancy and load distribution

|3
DNS Hierarchy

The root

Top-level
fj nodes

Second-level
nodes

Third-level Root
nodes
Top-level
Second level

FQDN = Fully Qualified Domain Name www.example.com.

|4
DNS Components at a Glance

Root Server

TLD Server

SLD Server

|5
DNS Servers

¤ Authoritative Servers
¡ Root Servers
¡ Primary
¡ Secondary

¤ Recursive Servers
¡ Or Recursive Resolvers
¡ Or Caching Servers

|6
Zone Files
$TTL 86400 ; 24 hours could have been written as 24h or 1d
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2017092701 ; serial number
3H ; refresh
15 ; retry
1w ; expire
3h ; nxdomain TTL )

IN NS ns1.example.com. ; in the domain

IN NS ns2.anotherexample.net. ; external to domain
IN MX 10 mail.someotherexample.com. ; external mail provider
ns1 IN A 192.168.0.1 ; name server definition
www IN A 192.168.0.2 ; web server definition
ftp IN CNAME www.example.com. ; ftp server definition
host IN A 192.168.0.3 ; host definition

|7
Root Zone Data

The root zone contains delegated top

level domain information
• Name server records (NS)
• Name server addresses (A, AAAA)
• Cryptographic records (DS, RRSIG,
DNSKEY, NSEC)

Only US ASCII-7 letters, digits, and hyphens

can be used as zone data.
In a zone, IDNs strings begin with XN--

|8
Top Level Domain (TLD) Zone Data

The TLD zones contain delegated

sub-domain information
• Name server records (NS)
• Cryptographic records

|9
Reverse Mapping

¤ Name-to-IP is “forward” mapping

¤ IP-to-name is “reverse” mapping
¤ Reverse mapping accomplished by mapping IP address space to the DNS name space
¤ IPv4 addresses under in-addr.arpa
¤ IPv6 addresses under ip6.arpa
¤ Uses PTR (pointer) records
7.2.0.192.in-addr.arpa. PTR host.example.com.

¤ Corresponds to this A record:

host.example.com. A 192.0.2.7

| 10
Reverse Mapping

A: 192.0.2.7

PTR:host.example.com.

| 11
 DNS Security

12 | 12
Common Uses for Maliciously Registered Domains

Domains registered by criminals for

• Counterfeit goods
• Data exfiltration
• Exploit attacks
• Illegal pharma
• Infrastructure (ecrime name resolution)
• Malware C&C
• Malware distribution, ransomware
• Phishing, Business Email Compromise
• Scams (419, reshipping, stranded traveler…)

| 13
13
Misused Domain Registrations

Domains compromised or hijacked by criminals or

state-sponsored actors
• Host criminal DNS infrastructure
• Domain, NS, or MX Hijacking
• Hacktivism (e.g., defacement)
• Malware (infected devices)
• Changing default resolvers (DNSChanger)
• Poisoning (resolver/ISP)
• Man in the Middle attacks

| 14
14
Domain name registrations are attractive targets for attacks

● Process is automated and

rapidly provisioned
● Registrar correspondence with
registrants is largely email
● Registrant is responsible for
registration data accuracy
● Inexpensive registrations are
plentiful…
Good for consumers, good for
attackers, too

| 15
Potential Target Points of the DNS Infrastructure/Ecosystem

TLD registries and domain name

registrars provide critical services
downstream:
• Registration platform
• Management platform
• Billing platform

| 16
Cache Poisoning Attacks

● Attacks that maliciously alter DNS data that a resolver has stored locally
(cached)

● Attacker’s name server will respond to a DNS query with additional

malicious data about another domain.

● Vulnerable resolvers add malicious data to local caches

● The malicious data will send victims to a phishing site for the lifetime of the
cached entry

| 17
IDN Based Attacks

| 18
DNS Hijacks

● The attacker distributes DNS configuration altering malware via

⁃ Spam, drive-by download…
⁃ Example: DNSChanger malware

● Attacker alters DNS configuration of infected device to cause all requests to

go to a malicious nameserver run by attackers

● Local DNS cache redirects web traffic to a destination of attackers choosing

| 19
DNS: Data Flow

Zone administrator
1
4
Zone file Primary Caching
Servers
2
3 5

Dynamic
updates
Secondaries Resolvers

20
| 20
DNS Vulnerabilities

Corrupting data Cache

Impersonating master
impersonation
Zone administrator
1
4
Zone file Primary Caching
Servers
2
3 5

Dynamic
updates
Secondaries Resolver
Cache pollution by
Data spoofing
Unauthorized updates
Altered zone data

Server protection Data protection

21
| 21
Security BCPs

• Networks and Servers (redundant)

• Back office systems.
• Physical and Electronic Security
• Quality of Service (24/ 7 availability!)
• Name Servers
• DNS software (BIND, NSD, etc.)
• Registry software
• Diagnostic tools (ping, traceroute, zonecheck, dig)
• Registry Registrar Protocol

| 22
Name Server Considerations

• Support technical standards

• Diverse bandwidth to support above

• Authoritative vs Recursive

• Authoritative Servers must answer authoritatively

• Turn off recursion!

• Recursive Servers should be providing recursion only to designated clients

| 23
Know Your SLAs

• Functioning name servers are the most critical/visible service

• All other services also need to be considered

‣ Billing
‣ Whois server, webservers
‣ Registrar APIs

• Consider your service level targets and how you will meet them

• DNS servers always on, other systems mostly on?

| 24
When It All Goes Wrong

• DNS is a known target for hackers.

• You will be targeted at some point!

• Have plans in place to deal with attacks, failures and disasters.

• Test those plans regularly!

| 25
 DNSSEC

26 | 26
Digital Signatures in Theory

A pair of keys have

Private Key a unique bond. If you
can "verify" something
with one, they other
Key Pair "signed" it.

If the public key of

Public Key someone verifies it,
that person's private
key must have signed it.

| 27
DNS's Data Organization

The Root • The DNS is a federation of

owners (registrants) of
information
– Each owner signs their own
TLD data with their own key
– That's a lot of keys

SLD • Hierarchy to the rescue!

data
| 28
DNSSEC Chain of Keys In Theory

root KEYs
The Root

tld KEYs
TLD

sld KEYs
SLD
data data records
| 29
Making A Chain

• The root zone signs TLD keys

• A TLD (administrator) signs registrant keys

• A DNS zone administrator (registrant) signs their own data

This creates a "chain" used in validation

| 30
Resource Records

• Adds following DNS Resource Records:

1. DNSKEY: Public key used in zone signing operations.
2. RRSIG: RRset signature
3. NSEC &
4. NSEC3: Returned as verifiable evidence that the name and/or RR type
does not exist
5. DS: Delegation Signer. Contains the hash of the public key used to sign
the key which itself will be used to sign the zone data. Follow DS RR's
until a ”trusted” zone is reached (ideally the root).

| 31
RR: DNSKEY

PROTOCOL
OWNER TYPE FLAGS ALGORITHM
example.com. 43200 DNSKEY 256 3 8 (

AwEAAbinasY+k/9xD4MBBa3QvhjuOHIpe319SFbWYIRj PUBLIC KEY

/nbmVZfJnSw7By1cV3Tm7ZlLqNbcB86nVFMSQ3JjOFMr (BASE64)

....) ; ZSK; key id = 23807 KEY ID

• FLAGS determines the usage of the key

• PROTOCOL is always 3 (DNSSEC)
• ALGORITHM can be (3: DSA/SHA-1, 5: RSA/SHA1, 8: RSA/SHA-256, 12: ECC-
GOST)
– http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml

| 32
DNSKEY: Two Keys, not one…

• Key Signing Key (KSK)

– Pointed to by parent zone in the form of DS (Delegation Signer). Also called Secure
Entry Point.
– Used to sign the Zone Signing Key
– Flags: 257
• Zone Signing Key (ZSK)
– Signed by the KSK
– Used to sign the zone data RRsets
– Flags: 256
• This decoupling allows for independent updating of the ZSK without having
to update the KSK, and involve the parents (i.e. less administrative
interaction)

| 33
RR: RRSIG (Resource Record Signature)

example.com. 600 A 192.168.10.10

example.com. 600 A 192.168.23.45
TYPE COVERED #LABELS
OWNER TYPE ALG TTL
example.com. 600 RRSIG A 7 2 600 (

SIG. EXPIRATION SIG. INCEPTION KEY IDSIGNER NAME

20200115154303 20191017154303 23807 example.com.

SIGNATURE
CoYkYPqE8Jv6UaVJgRrh7u16m/cEFGtFM8TArbJdaiPu
W77wZhrvonoBEyqYbhQ1yDaS74u9whECEe08gfoe1FGg
. . .
)

| 34
RR: RRSIG

• Typical default values

– Signature inception time is 1 hour before.
– Signature expiration is 30 from now
– Proper timekeeping (NTP) is required

• What happens when signatures run out?

– SERVFAIL
– Domain effectively disappears from the Internet for validating resolvers

• Note that keys do not expire

• No all RRSets need to be resigned at the same time

| 35
RR: DS (Delegation Signer)

• Hash of the KSK of the child zone

• Stored in the parent zone, together with the NS RRs indicating a

delegation of 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)

Digest type 1 = SHA-1, 2 = SHA-256

myzone. DS 61138 5 1
F6CD025B3F5D0304089505354A0115584B56D683

myzone. DS 61138 5 2
CCBC0B557510E4256E88C01B0B1336AC4ED6FE08C8268CC1AA5FBF00 5DCE3210

| 36
Key Rollovers

• Try to minimise impact

– Short validity of signatures
– Regular key rollover

• Remember: DNSKEYs do not have timestamps

– the RRSIG over the DNSKEY has the timestamp

• Key rollover involves second party or parties:

– State to be maintained during rollover
– Operationally expensive

| 37
 DNSSEC Validation

38 | 38
Verification In Theory

Address SLD SLD

Data Public Digital
Key Sig
• Verification works backwards, or "up" the hierarchy
• Start with the data sought – in this case the
address...

| 39
Verification In Theory

Address SLD Public SLD Digital

Data Key Sig

SLD Public TLD Public TLD Digital

Key as Data Key Sig

• Now we need to inspect the key used...

| 40
Verification In Theory

Address SLD Public SLD Digital

Data Key Sig

SLD Public TLD Public TLD Digital

Key Key Sig

TLD Public Root Public Root Digital

Key as Data Key Sig

| 41
Verification In Theory

Address Data SLD Public SLD Digital

Key Sig

SLD Public TLD Public TLD Digital

Key Key Sig

TLD Public Root Public Root Digital

Key Key Sig

| 42
Signing Chain in Practice
root KEY KSK
The Root root KEY ZSK
com. DS

com. KEY KSK

TLD com. KEY ZSK
example.com. DS

SLD example.com. KEY KSK

data example.com. KEY ZSK
www.example.com. DATA
| 43
Verification Chain In Practice
root KEY KSK
The Root root KEY ZSK
com. DS

com. KEY KSK

TLD com. KEY ZSK
example.com. DS

SLD example.com. KEY KSK

data example.com. KEY ZSK
www.example.com. DATA
| 44
Root Zone KSK

• The public Internet DNS has a root zone

• The root zone used on the Internet is signed with
DNSSEC, has a KSK and a ZSK

• The root zone adheres to Automated Updates (RFC 5011)

| 45
 Validation

• Having collected all of the needed records, all the

signatures can be validated

• If all the checks succeed, then the answer is valid and

returned to the application that asked

| 46
Start with the "final" response

$ dig +dnssec www.example.com. a

www.example.com. A 192.0.2.2
www.example.com. RRSIG A 8 3 3600 20190228002508
20190201120009 42694 example.com. aSignature

• The answer plus a digital signature

– aSignature is a random-looking sequence

| 47
Engage with ICANN – Thank You and Questions

Visit us at icann.org Email: champika.wijayatunga@icann.org

| 48