Summit 2010 Dnssec

8/6/2019 Summit 2010 Dnssec

1/44


2/44

Securing DNS by Deploying

DNSSEC

Steven BonnevilleManager Linux Curriculum, Red HatJune 2010


3/44

Agenda

Why should I care about DNSSEC? High-level overview of DNSSEC

Using RHEL 6 / BIND 9.7 to validate secured zones

Using RHEL 6 / BIND 9.7 to publish secure zones Troubleshooting DNS in a DNSSEC world

Learning more....


4/44

Expected Background

This session is targeted at an audience already familiarwith standard DNS operation

To get the most out of this session, participants should

already be familiar with The basic operation and terminology of DNS

The configuration of nameservers using BIND 9

System administration with Red Hat Enterprise Linux


5/44

Why should I care about DNSSEC?


6/44


DNS operation is fundamental to the Internet How we map human-friendly names to IP addresses,

mail exchangers, and other critical information

DNS is known to be subject to forgery attacks Bad guys forge DNS to map names to their IP

addresses, mail exchangers, and forged information

Cache poisoning attacks and pharming


7/44


Digitally signs DNS resource records Authentic responses can be validated

Forged responses will fail to validate, can be ignored

This blocks cache poisoning attacks and DNS forgery


8/44

How does DNSSEC work?


9/44


Public key encryption is used to sign zones We have four (well, five) new resource records

RRSIG

DNSKEY

DS

NSEC3 (or NSEC)

We have scripts to generate the records for us


10/44


Zone Signing Key Signs all resource records with the same name and type

For example, all A records forwww.redhat.com

The resulting signature is stored in a RRSIG record

The public part of the ZSK is in a DNSKEY record

Key Signing Key

Signs all Zone Signing Keys in the zone

Public KSK is also stored in a DNSKEY record in the zone Hash of the KSK is stored in a DS record in theparent zone


11/44


Signed zone has: DNSKEY records for ZSK and KSK

RRSIG records for resource record signatures

NSEC or NSEC3 records to validate NXDOMAIN

responses

Its parent zone has:

DS record for the KSK for the signed child zone

Its own normal records and DNSSEC records


12/44

ValidatingA for www.org from a signed root zone

Have local copy of KSK for root zone (trust anchor) In root zone

Verify KSK is still present as a DNSKEY in . and is still valid

Get other DNSKEYs (ZSKs) for . and validate with root KSK

Get DS for .org and validate with a DNSKEY (ZSK) from . In .org zone

Get DNSKEY (KSK) matching the DS for .org

Get DNSKEYs (ZSKs) for .org and validate with .org KSK

Get RRSIG for www.org A records and validate with the rightDNSKEY (ZSK)


13/44

The Root Zone

In order for this to work well, need signed root zone Planned to happen July 15, 2010!

RHEL 6 will ship the correct key when it is published

Also need signed TLDs which will accept DS records

Many TLDs are now signed

.org registrars expected to accept DS records very soon

If your TLD isn't signed or accepting DS records yet, there is a temporaryworkaround (DLV) which we'll talk about in a bit....


14/44

Deploying DNSSEC


15/44

Red Hat Enterprise Linux 6 and DNSSEC

RHEL 6 will ship BIND 9.7 Provides the latest support for DNSSEC

Two use cases:

Recursive nameserver that validates DNSSEC zones

Authoritative nameserver that serves DNSSEC zones


16/44

Validating Recursive Nameserver


17/44


Uses DNSSEC to verify DNS results Insecure: from a normal unsigned zone

Secure: from a signed zone, validates correctly

Bogus: signature fails to validate, or zone is unsigned

but parent says it should be signed Insecure and Secure results are returned normally

Bogus results are suppressed: SERVFAIL


18/44


This is the default BIND configuration in RHEL 6!

options {

dnssec-enable yes;dnssec-validate yes;

};


19/44

Trust Anchor for the Root Zone

In /etc/named.conf will set a trust anchor so wetrust the root DNSKEY

managed-keys {/* not the real root key */. initial-key 257 3 5 BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEf

K3clRbGaTwSJxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRhaBKnvcC2U9mZhkdUpd1Vso/HAdjNe8L;

};

Will auto-update to current key on startup if this is valid

RHEL 6 expected to set this when the root key isavailable (after July 15)


20/44

Installing a validating recursive nameserver

yum install bind

Edit /etc/named.conf

listen-on port 53 { any; };listen-on-v6 port 53 { any; };allow-query { any; };

(or restrict to allow only appropriate clients....)

Open inbound port 53/udp and 53/tcp on your firewall

service named start; chkconfig named on


21/44

Testing the validating recursive nameserver

[bash]# dig www.example.com +dnssec

;; ->>HEADER


22/44

DNSSEC-enabled Authoritative Nameserver


23/44

Authoritative Server: Configuration Overview

1

Create a normal DNS zone file2 Generate the zone-signing key and key-signing key

3 Add DNSKEY records for both keys to the zone file

4 Sign the zone (creates RRSIG and NSEC/NSEC3)

5 Point /etc/named.conf at the signedzone file

6 Reload the zone

7 Provide DS record for zone's KSK to your parent zone (We'll talk about what to do if your parent zone is not yet signed in a moment....)


24/44

BIND 9.7 Directory Structure in RHEL 6

/etc/named.conf is the main configuration file /var/named contains zone content and supporting files

Easiest to set up DNSSEC if each signed zone has its

own directory, and zone file has same name as zone /var/named/example.com/example.com would be the

zone file for the zone example.com

Directory and zone file needs to be readable by group

named, have SELinux type named_zone_t


25/44

Generating the ZSK and KSK

Change to the zone file's directory in /var/named cd /var/named/example.com/

Create the zone-signing key (ZSK)

dnssec-keygen example.com

Create the key-signing key (KSK)

dnssec-keygen -fk example.com

Both dnssec-keygen commands should add the -3option if you want to use NSEC3 records


26/44

Add the keys to the zone file

Each command results in two key pair files Kexample.com+005+00000.{key,private}

Add the public key files to the zone file

cat *.key >> /var/named/example.com/example.com


27/44

Manually sign the zone file

Sign the zone manually: dnssec-signzone example.com

Add -3 option if you want NSEC3 records

Active keys in the zone are automatically used

Creates example.com.signed file

BIND 9.7 has a number of new features to supportautomatic signing on dynamic update, key rotation

management, and so on...see the documentation in/usr/share/doc/bind-9.7*/arm/


28/44

Update zone directive and reload zone

Zone directive in /etc/named.conf needs to be pointedat the signed file

zone example.com IN {type master;

file example.com/example.com.signed;};

Reload the zone to make changes take effect

service named reload or rndc reload


29/44

Provide DS record to parent zone operator

If the parent zone is DNSSEC signed and ready,provide your zone's DS record to your registrar

You can generate it from your zone file if necessary

cd /var/named/example.com/ dnssec-dsfromkey -f example.com

Creates dsset-example.com. file containing DSrecords


30/44

Plan B: Provide DLV records to ISC DLV registry

When the registrar for your parent zone is NOTreadyto accept DS records, you can temporarily registeryour DNSSEC public keys with ISC's DLV registry

Opt-in service to allow validation by recursive resolversbefore there is a signed DNSSEC chain from the root toyour zone

RHEL 6 BIND validating resolver configuration usesthis service by default

See https://dlv.isc.org/ for more information


31/44

Complexities of running DNSSEC


32/44

Troubleshooting

Normal stub resolvers on clients should just work

Validation is done by its nameserver; if validation failsthe server simply sends no records

dig can be used to determine if you're not gettingrecords because the zone is bogus

Add +cd to the dig command line; if you weren't getting

records before but that works, the records are being

suppressed because the zone is failing validation


33/44

Troubleshooting: Validation Failure

[bash]# dig invalid.example.com

;; ->>HEADERHEADER


34/44

Troubleshooting: Validation Failure

You can clear your nameserver's cache if you think ithas been cache poisoned

rndc flush

rndc flushname name

If this is one of your zones, you could have a key issue

Mismatch between your zone's DS in parent zone andyour zone's DNSKEY for KSK

Your key may have expired (With the options we showed you earlier, they don't expire)


35/44

Key management is critical

If your DNSKEYs expire, your zone vanishes

Replacing the ZSK DNSKEY is easy

Start using it at least (TTL + replication delay) before

removing the old one!

Replacing the KSK DNSKEY is harder

You have to update the parent zone DS record too

Otherwise rules for ZSKs also apply


36/44

Time synchronization matters

You are running NTP, right?

If your time synchronization is bad, DNS messagesmay not properly validate due to replay protection

k il


37/44

Network Filters

Filtering firewalls, routers, and load balancers maybreak DNSSEC traffic

Must allow EDNS0 UDP packets over 512 B in size

Must allow TCP DNS traffic

Must not rewrite the DNS packets

This does break ISP domain helper redirection

After all, DNSSEC is supposed to stop DNS hijacking!


38/44

Beyond the basics

O t b d


39/44

One step beyond...

BIND 9.7 has many more features to simplify DNSSECzone management

When creating keys, you can set parameters to indicatewhen they should start being used to sign and whenthey expire and should be removed

You can set zones to automatically sign dynamicallyadded records, and to automatically rotate keys

The key for the root zone and other trust anchors canbe updated automatically (RFC 5011)

Look at the documentation for more details

References


40/44

References

ISC BIND page on DNSSEC

http://www.isc.org/software/bind/dnssec

DNSSEC deployment at the root zone

http://www.root-dnssec.org/

DNSSEC information for .org

http://www.pir.org/dnssec/

ENISA Good Practices Guide for Deploying DNSSEC

http://www.enisa.europa.eu/act/res/technologies/tech/gpgdnssec


41/44


42/44

Supporting Material



43/44


One of two record types are used to validate that aname does not exist:

NSEC records are smaller, but allows all names in thezone to be discovered efficiently through DNS lookups

NSEC3 makes zone enumeration harder, but requireslarger records (performance impact) and are newer

Trust Anchor for your own zone


44/44

Trust Anchor for your own zone

You can also set a trust anchor for your own zone ifyou are using DNSSEC but your parent is not signed

Good practice even if you have a DS record at yourparent so that you aren't dependent on it

The trusted-keys directive in this example will need to

be manually updated when the ZSK changes

trusted-keys {example.com 257 3 5 AwAwEAAa0c8KIEfTZWSi7/yaFHOoBUu

CPL5MQw/po8/WYaPokehAmK8XBynqpu

LpaSFBIyW/RHlZxcIVk2Oq9s;};

Documents

Summit 2010 Dnssec