Embed Size (px)
Citation preview
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
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
