1

DNS Security

Network Security Workshop26-30 October 2020

2

Root.

.org .net .com .ph

.gov.ph

example.gov.ph

.gov

.as

.tv

.aux.y.z.a

www.example.gov.ph

a.b.c.d

e.f.g.h

i.j.k.l

m.n.o.pw.x.y.z.

p.q.r.s

“Ask a.b.c.d”“Ask e.f.g.h”

“Ask i.j.k.l”

“Go to m.n.o.p”

localdnswww.example. gov.ph?“go to

m.n.o.p”

www.example.gov.ph?

www.example.gov.ph?

www.example.gov.ph?

www.example. gov.ph?

Background - What is DNS?

3

The DNS Tree HierarchyRoot.

net jporg com arpa pg

whois

edubnu

iana

www www

…

www training

ws1 ws2

gov comnetabc

www

apnictest

www

FQDN = Fully Qualified Domain Name

44

Issues with DNS• DNS data can be corrupted• There is no way to check the validity of DNS data

• Transactions between DNS servers and clients can be compromised

• And what about privacy of your DNS data?

4

55

DNS: Data Flow

master Caching forwarder

Zone administrator

Zone file

Dynamicupdates

1

2

slaves

3

4

5

resolver

6

master Caching forwarder

Zone administrator

Zone file

Dynamicupdates

1

2

slaves

3

4

5

resolver

Server protection Data protection

Corrupting data Impersonating master

Unauthorized updates

Cache impersonation

Cache pollution byData spoofing

DNS Vulnerabilities

7

DNS Cache Poisoning

(pretending to be the authoritative

zone)

ns.example.com

Webserver(192.168.1.12001:DB8::1)

DNS Caching Server

Client

I want to access www.example.com

1

QID=645712

QID=64569

QID=64570

QID=64571

www.example.com 192.168.1.1www.example.com 2001:DB8::1

match!

www.example.com 192.168.1.99www.example.com 2001:DB8::9

3

3

Root/GTLD

QID=64571

88

DNS Amplification• A type of reflection attack combined with amplification

– Source of attack is reflected off another machine– Traffic received is bigger (amplified) than the traffic sent by the

attacker

• UDP packet’s source address is spoofed

9

DNS AmplificationQueries for

www.example.com

Attacker

ns.example.com

Victim Machine

DNS Recursive server

Compromised Machines

(spoofed IP)

Root/GTLD

www.example.com 192.168.1.1www.example.com 2001:DB8::1

1010

Open Resolvers• DNS servers that answer recursive queries from any host

on the Internet – pose some “significant threat” to the global network infrastructure

• Often used in DNS-based DDoS attacks

• There’s a project that maps out open resolvers on the Internet– Open Resolver Project - http://openresolverproject.org/

• Some utility available to check if running an open resolver

1111

Open Resolvers

Reference: Open Resolver Project

1212

Open Resolvers Statistics

Source: DNS Measurement Factory

1313

DNS Changer• “Criminals have learned that if they can control a user’s

DNS servers, they can control what sites the user connects to the Internet.”

• How: infect computers with a malicious software (malware)

• A malware changes the user’s DNS settings with that of the attacker’s DNS servers

• Points the DNS configuration to DNS resolvers in specific address blocks and use it for their criminal enterprise

Source: DCWG

1414

DNS Hijacking• Also called DNS redirection• Can be achieved when

– User’s DNS settings has been modified through malware – DNS server has been compromised to provide incorrect responses

1515

DNS-based DDoS DNS uses UDP

– UDP = best effort, connectionless transmission– Easy to spoof the source address– Similar case with NTP, SNMP, SSDP, Chargen protocols

Each query returns large responses– EDNS0 allows DNS messages to carry bigger data– DNSSEC returns large replies

It’s usually open to all– Open resolvers

https://www.us-cert.gov/ncas/alerts/TA14-017A

1616

Using DNS for Other Attacks• Fast flux

– Domain name resolves to many different IP addresses over a short periodhello.com IN A 203.176.188.25

hello.com IN A 203.176.188.26

• Double IP Flux– Both hostname and IP address mapping and also the authoritative nameserver rapidly change

hello.com IN A 203.176.188.25hello.com IN NS 203.176.188.111

hello.com IN NS 61.101.155.3hello.com IN A 203.176.188.26

• Domain Generation Algorithms (DGAs)– Randomise the domain name, resolves to the same IP

qwekhh4562313erreq4.hello.com IN A 203.176.188.2590j653gdfmrrn589sq.hello.com IN A 203.176.188.25

1717

Basic DNS Security Practices• Run the most recent version of the DNS software or apply

the latest patch• Restrict queries• Prevent unauthorized zone transfers• Run BIND with the least privilege (use chroot)• Randomize source ports• Secure the box• Implement TSIG and DNSSEC

1818

DNS DDoS Mitigation• Set up monitoring to know when you are being attacked

– Use previous statistics to know your baseline load

• Avoid single point of failure– DNS server, router, firewall, uplinks, etc– Authoritative nameservers must be geographically distributed

• Provision for your DNS infrastructure– Find your DNS capacity (using tools like dnsperf)– Be ready to deploy more as needed

• Deploy anycast– Attack is isolated in one group at a time– Alternatively use cloud-based DNS providers

• Don’t run an open resolver!

1919

Response Rate Limiting (RRL)• Protects against DNS amplification attack• Implemented in CZ-NIC Knot (v1.2-RC3), NLNetLabs NSD

(v3.2.15), and ISC BIND 9 (v9.9.4) release

rate-limit {responses-per-second 5;log-only yes;

};

• If using older versions, a patch is available from – http://ss.vix.su/~vjs/rrlrpz.html– patch –p0 -l

2020

Sender Policy Framework (SPF) • Using DNS for email validation• Checks the sender IP address

• Defined in RFC 4408 with updates in RFC 6652

apnic.net. 3600 IN TXT"v=spf1 mx a:clove.apnic.net a:asmtp.apnic.net

ip4:203.119.93.0/24 ip4:203.119.101.0/24 ip4:203.89.255.141/32 ip4:203.190.232.30/32 ip4:122.248.232.184/32 include:_spf.google.com -all"

2121

DANE• DNS-Based Authentication of Named Entities• RFC 6698 (proposed standard)

• “secure method to associate the certificate that is obtained from the TLS server with a domain name using DNS”

• Adds a TLSA resource record

2222

DNS RPZ• Resource Policy Zone• Developed for ISC Bind. Built in from version 9.8

• Turns a recursive DNS server into a “DNS firewall”

• “reputation-based” zones

• Like creating a reputation server for recursive DNS servers– Function is similar to DNSBL for email SMTP servers

• Blocks DNS resolution to malicious hosts

2323

Transactions - Protected Vulnerabilities

Unauthorized updates

master Caching forwarder

Zone administrator

Zone file

Dynamicupdates

slavesresolver

Impersonating master

DNS query/response, zone transfers,Dynamic updates

2424

DNS Transactions• Remote Name Daemon Controller (RNDC)

– Protects the remote CLI administration using shared key– Prevents unauthorized access to named

• Transaction Signature (TSIG)– Protects transactions using shared keys between both parties

• SIG(0)– Protects transactions using asymmetric key (public and private

keypair)

2525

What is Transaction Signature?• A mechanism for protecting a message from primary to

secondary (and vice versa)

• Provides secure communication of queries and responses– Also protects zone transfers and dynamic updates

• How?– A keyed-hash is applied so recipient can verify the message source

• Based on a shared secret - both sender and receiver are configured with it

26

27

DNSSEC TECHNICAL OVERVIEW

2828

Vulnerabilities protected by DNSKEY / RRSIG / NSEC

Cache impersonation

Cache pollution byData spoofing

master Caching forwarder

Zone administrator

Zone file

Dynamicupdates

slavesresolver

2929

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:– establish authenticity and integrity of data– delegate trust to third parties or parent zones

30

How DNSSEC WorksAuthoritative server

• Signs the zones• Answers queries with the record

requested • Also sends 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

DNS Resolver

DNS Auth Server

3131

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

31

3232

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

32

3333

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

3434

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.1web1.example.net. 7200 IN A 10.0.0.1web2.example.net. 7200 IN A 172.16.0.20

In DNSSEC, RRsets are signed and not the individual RRs

3535

RRSIG• 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

irrashai.net. 86400 NS NS.JAZZI.COM.86400 NS NS.IRRASHAI.NET.86400 RRSIG NS 5 2 86400 (

20190314010528 20190214010528 3510 irrashai.net.

Y2J2NQ+CVqQRjQvcWY256ffiw5mp0OQTQUF8vUHSHyUbbhmE56eJimqDhXb8qwl/Fjl40/kmlzmQC5CmgugB/qjgLHZbuvSfd9W+UCwkxbwx3HonAPr3C+0HVqP8rSqGRqSq0VbR7LzNeaylBkumLDoriQxceV4z3d2jFv4ArnM= )

35

RR type signed

Digital signature algorithmNumber of labels in the signed name

Signature expiry

Date signed

3636

DNSKEY• Contains the zone’s public key• Uses public key cryptography to sign and authenticate DNS

resource record sets (RRsets).

• Example:

irrashai.net. IN DNSKEY 256 3 5 ( AwEAAagrVFd9xyFMQRjO4DlkL0dgUCtogviS+FG9Z6Au3h1ERe4EIi3L X49Ce1OFahdR2wPZyVeDvH6X4qlLnMQJsd7oFi4S9Ng+hLkgpm/n+otEkKiXGZzZn4vW0okuC0hHG2XU5zJhkct73FZzbmBvGxpF4svo5PPWZqVb H48T5Y/9 ) ; key id = 3510

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

Protocol octet

DNSKEY algorithm number

Public key (base64)

3737

NSEC Record• 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

3838

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.

3939

DS Record• 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

irrashai.net. IN NS ns1.irrashai.net.NS ns2.irrashai.net.

IN DS 19996 5 1 ( CF96B018A496CD1A68EE7C80A37EDFC6ABBF8175 )

IN DS 19996 5 2 (6927A531B0D89A7A4F13E110314C722EC156FF926D2052C7D8D70C50 14598CE9 )

Key IDDNSKEY algorithm (RSASHA1)

Digest type: 1 = SHA12 = SHA256

4040

DS Record• indicates that delegated zone is digitally signed

• Verifies that indicated key is used for the delegated zone

• Parent is authoritative for the DS of the child zone– Not for the NS record delegating the child zone– DS should not be added in the child zone

4141

Chain of Trust• Establishes a chain of trust from parent to child zone

– Parent does not sign child zone– Parent only signs a pointer to the child zone (key) – DS RECORD

• The root is on top of the chainRoot.

.net

.apnic.net

4242

Creation of keys• 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 (RFC allows both methods)

• 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

43

Types of KeysZone Signing Key (ZSK)

Sign the RRsets within the zoneSigned by the KSKUses flag 256

Key Signing Key (KSK) Signs the ZSKPointed to by the parent zoneActs as the security entry point

4444

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

• Expired signatures will not validate– Must re-sign the zones

4545

DNSSEC Algorithms

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

New algorithms such as ECDSA and GOST are faster and can generate smaller keys and signatures

46

47

DNSSEC VALIDATION

4848

DNSSEC Validation Rate

48

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

4949

DNSSEC in the Resolver• Recursive servers that are DNSSEC-enabled can validate

signed zones

• To enable DNSSEC validation: dnssec-validation yes;

• The AD bit in the message flag shows if validated

49

5050

DNSSEC Validation

50

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= )

5151

DNSSEC Validation

51

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47652 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; >>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21978 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

'ad’ bit – authenticated data

If dnssec validation is yes, and validation fails

5252

DNSSEC Validation• Other options if you don’t have a validating resolver

– Online web tools– Browser plugins

• Use public DNS serverdig @1.1.1.1 www.apnic.net +dnssec +multilinedig @8.8.8.8 www.apnic.net +dnssec +multiline

52

53

DNSSEC ValidationWithout validation With validation

54

DNSSEC Validation

Without validation With validation

5555

DNSSEC for Network Service Providers• Enable DNSSEC on your recursive servers and validate

responses– Deploy DNSSEC-validating resolvers

• Before you fully implement:– Domains that can’t be validated will be inaccessible– Be prepared to answer helpdesk queries related to this

55

5656

DNSSEC for End-users• Use a dnssec-validating resolver• If not available, use other tools (such as browser plugin)

56

57

Lab: DNSSEC Validation

58

58

59

DNSSEC SIGNING

59

6060

DNSSEC Deployment Maps

60

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

6161

DNSSEC Deployment Maps (AP)

61

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

6262

DNSSEC for Registries and Hosting Providers• Sign your zones• Before fully implementing:

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

• Support more and newer algorithms (such as ECDSA)

62

6363

DNSSEC - Deploy a Secure Zone1. 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 zonefile6. Test the server7. Push the DS record (to parent zone)

63

6464

1. Enable dnssec• Enable DNSSEC in the configuration file (named.conf)

options {

directory “….”

dnssec-enable yes;

dnssec-validation yes;

};

• Other options to automate signing and key rolloverauto-dnssec { off | allow | maintain} ;

64

6565

2. Generate key pairs• Generate ZSK and KSK

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

Or simply:dnssec-keygen –f KSK <myzone>

• This generates four files.– Note: There has to be at least one public/private key pair for each

DNSSEC zone

65

Notes: Algorithm and keysize is an operational choice, but generally:- ECDSA is recommended- Keysize must be at least 2048

6666

2. Generate key pairs• 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

66

6767

2. Generate key pairs (reverse DNS)• 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

67

6868

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

6969

3. Publish the public key• A few options to do this:

– 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

– You can also manually enter the DNSKEY RR in the zone file– Or add the files into a key directory

zone { key-directory “/etc/bind/keys”; };

69

7070

4. Sign the zone• Sign the zone using the secret keys:

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

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

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

70

Notes: Most of the following steps have been automatically done by the software. The manual steps are shown to understand the signing process.

7171

4. 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 are signed– Glue records are not signed

• Notice the difference in file size– db.myzone.net vs. db.myzone.net.signed

71

7272

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;

72

7373

Inline Signing• The use RNDC to load the new keys and do inline signing.

rndc reconfigrndc loadkeys myzone.netrndc signing –list myzone.net

73

7474

Using NSEC3• Load the keys and sign the zone

rndc loadkeys irrashai.netrndc signing –NSEC3PARAM 1 0 10 <some-salt> irrashai.net.

– To randomly generate a salt used aboveopenssl rand -hex 4

• Get the DS record and upload to the parent zone dig @localhost dnskey irrashai.net | dnssec-dsfromkey -f –irrashai.net

7575

5. Publish the new zonefile• 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”;

};

75

7676

5. Publish the new zonefile (reverse)• 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”;

};

76

7777

6. Test the server• Ask a dnssec-enabled server and see whether the answer

is signed

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

77

7878

Testing with Dig

78

dig @localhost www.irrashai.net +dnssec (+multiline)

7979

Testing with Dig – Reverse

79

dig @localhost -x 192.168.100.100 +dnssec

8080

7. Push the DS record• 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:– RFC 7344 : Automating DNSSEC Delegation Trust Maintenance– RFC 7477 : Child to Parent Synchronization in DNS– RFC 8078 : Managing DS Records from the Parent via

CDS/CDNSKEY

80

8181

Pushing DS Records for Forward Zone

81

Example form for Godaddy

8282

Pushing DS Record for Reverse Zone

82

DS record added in the domain object in a ds-rdata field

Using MyAPNIC

8383

Tools: DNSViz

83

http://dnsviz.net/

DNSViz can be used to see the chain of authentication

8484

Ways to Deploy DNSSEC• As part of the DNS software used

– Manual key management– Can be quite complex– For static environment– Some means of automation

• Use with a hardware security module (HSM)– Semi-automatic – Good for dynamic environment

• Using an external appliance – ‘dnssec-in-a-box’– Fully automates key generation, signing and rollover

84

DNSSEC tools for BIND, NSD, PowerDNS, etc

HSM, OpenDNSSEC

DNS Appliance

85

DNSSEC Signer Appliance

DNS Master• Creates the zones

as per usual

DNSSEC Signer• Signs the zones• Propagates the

signed zones

DNS Server• Answer queries

• 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

• Examples: Secure64, Xelerance, SolidDNS, etc

85

86

87

Lab: Manual & Automatic DNSSEC Signing

88

DNSSEC KEY MANAGEMENT & ROLLOVER

8989

Key Considerations• Option to use two keys (ZSK or KSK) or a single key

– Having 2 keys will ease the burden of management

• Regenerate keys occasionally as a good security practice– ZSK changes more frequently (6 months or yearly)– KSK can be done periodically (every couple of years?)

• ZSK and KSK will have different timing for key generation and rollover

9090

Key Storage• Public key does not need secure storage, but centralised

storage is useful– Easy access to DNS (ex. /etc/bind/keys)– Easy to send DS to parent zone

• Private key must be stored securely. – Options to store offline, use HSM, or restricted folder access– Storing ZSK offline may cause more complexity– KSK can be stored offline since it’s less frequently used

9191

DNSSEC Operational Practices - RFC 6781 • Lists down choices and decisions available when deploying DNSSEC• Keep the chain of trust

– Broken chains result in data being marked as Bogus– Shared responsibility by admins

• Key generation and storage– The motivations to differentiate KSK and ZSK are purely operational– Timing parameters– Key compromise and risk of cryptanalysis– Keys should be large enough to avoid all known crypto attacks during the

effectivity period of the key– zone private keys and the zone file master copy to be signed be kept and used in

off-line

91

https://tools.ietf.org/html/rfc6781

9292

DNSSEC Operational Practices - RFC 6781 • Signature generation, key rollover and policies

– Data published in previous versions still live in caches– ZSK can be rolled without taking into account the DS record from

parent– KSK rollover requires interaction with the parent– Emergency key rollover

• Motivation to deploy NSEC3 over NSEC– Prevention of zone enumeration

92

https://tools.ietf.org/html/rfc6781

9393

Two Options for Key RolloverPre-publication

Publish a new key prior to date of activationthe new key will not be used for signing yetBest for ZSK rollover

Double SigningBoth keys are used to signBest for KSK rollover

9494

ZSK Key Rollover• Using Pre-publication

1. Publish both keys, but use only the old one for signing2. Wait for the propagation time and TTL of the DNSKEY RR to expire.

dnssec-keygen –K keydir –f ksk –A none <myzone.net> rndc loadkeys <myzone.net>

94

This scheme exposes the key slightly longer for cryptanalysis and involves more parental work.

9595

ZSK Key Rollover• Then use dnssec-settime once you are ready to sign the zone. Use the new key for zone

signing, leaving the old one published.

dnssec-settime –K keydir –A <time> Kmyzone.net.+005+12345 rndc loadkeys myzone.net

• Wait for the propagation and TTL in the old zone. Set the old key to no longer sign with the key but leave it in the zone.

dnssec-settime –K keydir -I <time> Kmyzone.net.+005+12345 rndc loadkeys myzone.net

• Now remove the old keys. This completely removes the keys.

dnssec-settime –K keydir -D <time> Kmyzone.net.+005+12345 rndc loadkeys myzone.net

95

9696

ZSK Key Rollover• Using Double signing

1. Publish the new key and new RRSIG, thus double signing the zone. 2. Remove the old key and old RRSIG after some time (generally,

after one TTL)

96

This is an easier approach, but with the downside of increased zone size during rollover.

9797

KSK Key Rollover• More complexity involved. With any changes, the parent

zone must be informed.

• Similar considerations as ZSK rollover

• Use double-signing to guarantee that old data in cache can still be verified.

• Only the key set is signed, so zone size is not an issue

9898

KSK Key Rollover – RFC7583• Methods:

– Double-DS – publish new DS record and wait until it propagates before changing the KSK

– Double-KSK – new KSK is added to the DNSKEY RRset, then wait to expire

– Double-RRset – new KSK is added to the DNSKEY RRset and DS key is added to parent zone.

98

https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html#key-rollovers

9999

Emergency Key RolloverWhat happens if the private key gets compromised?

Option 1:Reduce TTL of the current DNSKEYGenerate new KEY and follow the same rollover steps

Option 2:Pre-publish a second key that you can use anytime

100100

Algorithm Rollover• It may be required to rollover to support a more secure

DNSSEC algorithm

– Ex: RSASHA1 to RSASHA2 or ECDSA

• Switching from NSEC to NSEC3 also requires algorithm change

• Similar to normal rollovers, but it’s best to roll KSK and ZSK at the same time

101101

DNSSEC Practice Statement – RFC 6841• a means for stakeholders to evaluate the strength and

security of the DNSSEC chain of trust

• DNSSEC Policies (DPs) – security requirements and standards to be implemented for a DNSSEC-signed zone

• DNSSEC Practice Statement (DPS) – practice disclosure document; states how the management of a given zone implements procedures and controls at a high level

101

https://tools.ietf.org/html/rfc6841

102102

DNSSEC Practice Statement• The DPS for Root Zone Signing Key (ZSK) is published

– https://www.iana.org/dnssec/icann-dps.txt

• Published DPS of TLD operators• .SE's DNSSEC Practice Statement

– www.iis.se/docs/se-dnssec-dps-eng.pdf• .CL's DNSSEC Practice Statement

– http://www.nic.cl/dnssec/en/dps.html• .NET DNSSEC Practice Statement

– http://www.verisigninc.com/assets/20100925-NET+DPS-FINAL.pdf

102

103

DNSSEC Practice Statement (APNIC)

https://www.apnic.net/wp-content/uploads/2016/11/DNSSEC_DPS_210616v1.pdf

• This DPS applies to reverse zones for IP blocks that APNIC is responsible for

• Some useful info related to rollover– Signature format: ECDSA SHA256– Key Rollover

• KSK: Double Signing• ZSK: Pre-publish

– Signature lifetime and re-signing frequency: 30 days

– Resource Records TTL: • DNSKEY KSK: 1 hour• DNSKEY ZSK: 1 hour

104

105105

Thank You!END OF SESSION