APNIC Online Tutorial –DNS/DNSSEC

1

APNIC Online Tutorial – DNS/DNSSEC

22

OutlineDay 2• DNSSEC Concept

• DNSSEC Deployment

• Hands-on Lab– Part 1: DNSSEC Validation– Part 2: Manual DNSSEC Signing– Part 3: Automatic DNSSEC Signing– Part 4: Chain of Trust

33

Housekeeping• Please note that this session will be recorded

• Please mute your microphone when the Instructor is presenting to avoid disruptions to the class;

• For Q&As please use the google document;

• After every 30 minutes we will discuss the Q&A;

• The chat section will be used to share information, URLs, etc;

• If you raise your hand be sure to lower it again;

• If something goes wrong, re-join the meeting;

• If you have any trouble please email training@apnic.net

44

Resources • Course Materials

– https://wiki.apnictraining.net/dns20200722-online

• Lab– https://academy.apnic.net/en/virtual-labs?labId=75818

55

Ask Questions• Google Doc

– https://docs.google.com/document/d/1VZ6DqBqPwNiHMTyp0XE4mL9OHEcqd8BTMyqYOaYGuPs/edit?usp=sharing

• Email the mailing list– CommunityTrainers@apnic.net

6

DNS SECURITY OVERVIEW Module 1:

77

DNS: Data Flow

master Caching forwarder

Zone administrator

Zone file

Dynamicupdates

1

2

slaves

3

4

5

resolver

8

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

99

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?

9

10

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

1111

Attacks on DNS

11

https://www.icann.org/news/announcement-2019-02-15-en

1212

Basic DNS Security Practices• Update and patch DNS software• Restrict queries• Prevent unauthorized zone transfers• Run BIND with the least privilege (use chroot)• Randomize source ports• Secure the box• Implement TSIG and DNSSEC• DoH and DoT

13

14

DNSSEC TECHNICAL OVERVIEWModule 2:

1515

Vulnerabilities protected by DNSKEY / RRSIG / NSEC

Cache impersonation

Cache pollution byData spoofing

master Caching forwarder

Zone administrator

Zone file

Dynamicupdates

slavesresolver

1616

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

17

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

1818

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

18

1919

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

19

2020

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

2121

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

2222

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

22

RR type signed

Digital signature algorithmNumber of labels in the signed name

Signature expiry

Date signed

2323

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)

2424

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

2525

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.

2626

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

2727

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

2828

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

2929

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

30

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

3131

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

3232

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

33

34

DNSSEC VALIDATIONModule 3:

3535

DNSSEC Validation Rate

35

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

3636

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

36

3737

DNSSEC Validation

37

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

3838

DNSSEC Validation

38

;; ->>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

3939

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

39

40

DNSSEC ValidationWithout validation With validation

41

DNSSEC Validation

Without validation With validation

4242

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

42

4343

DNSSEC for End-users• Use a dnssec-validating resolver

• If not available, use other tools (such as browser plugin)

43

44

DNSSEC SIGNINGModule 3:

44

4545

DNSSEC Deployment Maps

45

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

4646

DNSSEC Deployment Maps (AP)

46

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

4747

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)

47

4848

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 zonefile

6. Test the server

7. Push the DS record (to parent zone)

48

4949

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} ;

49

5050

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

50

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

5151

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

51

5252

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

52

5353

Using NSEC3• Generate keys

dnssec-keygen -r /dev/urandom -a RSASHA256 -3 -b 1024 -n ZONE irrashai.netdnssec-keygen -r /dev/urandom -f KSK -a RSASHA256 -b 2048 -3 -n ZONE irrashai.net

5454

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”; };

54

5555

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

55

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

5656

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

56

5757

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;

57

5858

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

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

58

5959

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

6060

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”;

};

60

6161

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”;

};

61

6262

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

is signed

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

62

6363

Testing with Dig

63

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

6464

Testing with Dig – Reverse

64

dig @localhost -x 192.168.100.100 +dnssec

6565

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

65

6666

Pushing DS Records for Forward Zone

66

Example form for Godaddy

6767

Pushing DS Record for Reverse Zone

67

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

Using MyAPNIC

6868

Tools: DNSViz

68

http://dnsviz.net/

DNSViz can be used to see the chain of authentication

6969

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

69

DNSSEC tools for BIND, NSD, PowerDNS, etc

HSM, OpenDNSSEC

DNS Appliance

70

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

70

71