Securing DNS by Deploying DNSSEC

Steven Bonneville Manager Linux Curriculum, Red Hat June 2010

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

Expected Background

This session is targeted at an audience already familiar with 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

Why should I care about DNSSEC?

Why should I care about DNSSEC?

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

Why should I care about DNSSEC?

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

How does DNSSEC work?

How does DNSSEC work?

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

How does DNSSEC work?

Zone Signing Key

Signs all resource records with the same name and type
For example, all A records for www.redhat.com The resulting signature is stored in a RRSIG record The public part of the ZSK is in a DNSKEY record 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 the parent zone

Key Signing Key

How does DNSSEC work?

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

Validating A 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 . 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 right DNSKEY (ZSK)

In .org zone

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 temporary workaround (DLV) which we'll talk about in a bit....

Deploying DNSSEC

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

Validating Recursive Nameserver

Validating Recursive Nameserver

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

Validating Recursive Nameserver

This is the default BIND configuration in RHEL 6!
options { dnssec-enable yes; dnssec-validate yes; };

Trust Anchor for the Root Zone

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

managed-keys { /* not the real root key */ . initial-key 257 3 5 BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEf K3clRbGaTwSJxrGkxJWoZu6I7PzJu/E9 gx4UC1zGAHlXKdE4zYIpRhaBKnvcC2U9 mZhkdUpd1Vso/HAdjNe8L; };

Will auto-update to current key on startup if this is valid RHEL 6 expected to set this when the root key is available (after July 15)

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

Testing the validating recursive nameserver

[bash]# dig www.example.com +dnssec ;; ->>HEADER<<-- opcode: QUERY, status: NOERROR, id: 135 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 [ad=secure zone. if you see aa instead of ad, server is authoritative & isn't bothering with DNSSEC] [...omitted stuff...] ;; OPT PSEUDOSECTION ; EDNS: version: 0, flags: do, udp: 4096 ;; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION www.example.com. 86400 IN A 192.0.2.1 www.example.com 86400 IN RRSIG A 7 3 86400 20100717210129 20100617210129 23045 example.com. tW8lXaJaLpLQod4IlSGwiShFcqe6bA GyCcVjtvH0eII1Wos8RutwWYvEJzCaNmAFRWUSCoKP+aowjK5GjLvmxzVcsp3mKy Aq9IZvCtWIyfGLarT7 Nnqp16iGytQxjKmF1h0nWXkaj2iDCF1et8j+RmUX6Hp= [...omitted stuff...]

DNSSEC-enabled Authoritative Nameserver

Authoritative Server: Configuration Overview

1 2 3 4 5 6 7

Create a normal DNS zone file Generate the zone-signing key and key-signing key Add DNSKEY records for both keys to the zone file Sign the zone (creates RRSIG and NSEC/NSEC3) Point /etc/named.conf at the signed zone file Reload the zone 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....)

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

Generating the ZSK and KSK

Change to the zone file's directory in /var/named

cd /var/named/example.com/ dnssec-keygen example.com dnssec-keygen -fk example.com

Create the zone-signing key (ZSK)

Create the key-signing key (KSK)

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

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

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 support automatic signing on dynamic update, key rotation management, and so on...see the documentation in /usr/share/doc/bind-9.7*/arm/

Update zone directive and reload zone

Zone directive in /etc/named.conf needs to be pointed at 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

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 DS records

Plan B: Provide DLV records to ISC DLV registry

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

Opt-in service to allow validation by recursive resolvers before there is a signed DNSSEC chain from the root to your zone

RHEL 6 BIND validating resolver configuration uses this service by default See https://dlv.isc.org/ for more information

Complexities of running DNSSEC

Troubleshooting

Normal stub resolvers on clients should just work

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

dig can be used to determine if you're not getting records 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

Troubleshooting: Validation Failure

[bash]# dig invalid.example.com ;; ->>HEADER<<-- opcode: QUERY, status: SERVFAIL, id: 11403 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 [...omitted...] [bash]# dig +cd invalid.example.com ;; ->>HEADER<<-- opcode: QUERY, status: NOERROR, id: 1503 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 [...omitted...] ;; ANSWER SECTION invalid.example.com. 86400 IN A 192.0.2.10

The response for the name invalid.example.com is being reported as bogus here. By adding the +cd flag we get to see the bogus information which failed validation.

Troubleshooting: Validation Failure

You can clear your nameserver's cache if you think it has 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 and your zone's DNSKEY for KSK Your key may have expired

(With the options we showed you earlier, they don't expire)

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

Time synchronization matters

You are running NTP, right? If your time synchronization is bad, DNS messages may not properly validate due to replay protection

Network Filters

Filtering firewalls, routers, and load balancers may break 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!

Beyond the basics

One step beyond...

BIND 9.7 has many more features to simplify DNSSEC zone management

When creating keys, you can set parameters to indicate when they should start being used to sign and when they expire and should be removed You can set zones to automatically sign dynamically added records, and to automatically rotate keys The key for the root zone and other trust anchors can be updated automatically (RFC 5011)

Look at the documentation for more details

References

ISC BIND page on DNSSEC

http://www.isc.org/software/bind/dnssec http://www.root-dnssec.org/ http://www.pir.org/dnssec/

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

DNSSEC deployment at the root zone

DNSSEC information for .org

ENISA Good Practices Guide for Deploying DNSSEC

Supporting Material

How does DNSSEC work?

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

NSEC records are smaller, but allows all names in the zone to be discovered efficiently through DNS lookups NSEC3 makes zone enumeration harder, but requires larger records (performance impact) and are newer

Trust Anchor for your own zone

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

Good practice even if you have a DS record at your parent 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; };