The need for more than just SSL, locking down Interop with DNSSEC

Who is Dyn?The DNS and Email Experts

Powering the biggest and fastest growingbrands on the Internet

Providing DNS to InteropNET with our Enterprise Managed DNS service: Dynect Platform

First there was unsecured http....

To verify the correct domain name, https....

Add in DNSSEC to secure the entire lookup.

Quick reminder about the basics of DNS...

DNS maps names to numbers. You and I understand www.local.mybank.com but your computer only knows how to get to IP addresses. DNS bridges the two.

2 Types of DNS servers

Authoritative – Answers specific DNS queries: ie: What is the A record for www.local.mybank.com

Recursive – Query Authoritative servers for DNS information and store it (Cache it) for a period of time

DNS recursion is the process of a recursive server iteratively asking authoritative servers questions until it finds out a definitive answer.

DNS Recursion – Query the recursive server

DNS Recursion – Recursive server queries root...

DNS Recursion – Recursive server queries com

DNS Recursion – Recursive server queries mybank.com

DNS Recursion – Recursive server queries local.mybank.com

DNS Recursion – Recursive server responds to original request

I'm doing my online banking, I see the https lock is green but you're saying I'm not safe!?

Only Partly!

As we saw the name of the site you are going to is trusted

The ip address you are being brought to is at the mercy of DNS

Think about what would happen if someone changed your /etc/hosts file to point www.local.mybank.com to a fake site.... would your computer know?

This is basically what DNS cache poisoning or DNS man in the middle attacks are but on a larger scale

What types of security breaches occur at the DNS level?

Man in the middle attack

Malicious machine intercepts every packet going from one machine to another

When returning information changes DNS records to point to bad site

DNS cache poisoning Attack

Malicious machine continuously re-sends response for a site to the recursive DNS server

When recursive server eventually asks for the information the first reply that it sees is from the malicious machine

DNS Cache Poisoning

You would be securely connected... but to the wrong computer!

Need a way to do SSL like verification in DNS... Enter DNSSEC!

DNSSEC is a way for the recursive server to validate each of the replies it gets to make sure the correct response is given.

DNSSEC Secured

Interop and DNS … and DNSSEC

First the DNS layout Providing both Authoritative and Recursive DNS to interop

The starting point...

Cisco providing DHCP service through their CNR

CNR pushes updates to Dynect show floor hidden master

It's good to have redundancy plus redundancy is good to have

Sign the update and propagate it to Dynect

Need to handle DNS requests too!

Handle it by show floor anycast recursive servers.... and here is the complete DNS picture

So the authoritative zones are signed, how do you actually sign a zone... The BIND way (for each and every zone...)

– Generate the keys using dnssec-keygen twice, once for the ZSK and once for the KSK

– Store the private keys someplace safe (since anyone with the private keys can sign as you)

– Include the correct keys in the zone file

– Actually sign the zone using dnssec-signzone

The Dynect way...

Click “Add DNSSEC”!

Just one more step...

After the zone is signed, just publish the DS record to your registrar and you are trusted!

This isn't always the fastest thing. At the moment we are waiting for the interop.net registrar to update their DS record – being a newer technology this sometimes takes a while, particularly if it isn't something the registrar does all the time

DNSSEC tools

Being the DNS Experts we aren't going to leave you hanging in regards to a DNSSEC tool!

DNSCog: http://www.dnscog.com/ - Lets you verify the DNSSEC chain

Notice that interop.net is signed up to the registrar

Some other cool DNSSEC related stuff to check out

This is a site with a purposely broken DNSSEC chain that can be used to check untrusted handling: http://www.dnssec-failed.org/

FireFox DNSSEC plugin: http://www.dnssec-validator.cz/ - Adds a simple graphical interface for sites to let you know their DNSSEC status

Tools/patches for adding DNSSEC awareness into some common applications like postfix and sendmail: https://www.dnssec-tools.org/wiki/index.php/DNSSEC_Applications

A one stop shop for all your DNSSEC needs: http://www.dnssec.net/

Booth #715 in Cloud and Virtualization ZoneGet a free Dynect Platform trial and get started with

DNSSEC

DynOn the web: http://dyn.com/

Twitter: @DynInc

Kevin GrayTech IntegratorEmail: kgray@dyn.comTwitter: @tuftsmoose

Interested in hearing the DNSSEC details... keep going!

How does DNSSEC work? Implemented as a pair (2) of public key/private key pairs

A zone signing key pair (ZSK) used to sign every record type except for DNSKEY records

A key signing key pair (KSK) used to sign DNSKEY records

A zone uses it's ZSK private key to sign each of it's record sets, the signature is stored in an RRSIG record type which is a DNSSEC specific DNS record type

A zone stores the public ZSK in a DNSKEY record which is another DNSSEC specific DNS record type, this record is then signed with the private KSK

The zone administrator then sends a DS record to the parent zone owner. The DS record is the public KSK. This DS record exists only on the parent zone and is signed by the parent zone to verify it's validity.

Now to validate a zone one takes the validated DS record from the parent zone to get the zone's public KSK, uses this KSK to validate the DNSKEY record of the zone then uses the public ZSK stored in the validated DNSKEY record to validate every other record set in the zone.

The DNSSEC Chain of Trust

In the manner just described each validated parent is able to give the validated public KSK for it's signed children. This linking is called the DNSSEC Chain of Trust

Basics of the Chain (where is www.local.mybank.com?):

root KSK validates root DNSKEY with ZSK → ZSK validates .com DS record which contains .com KSK

.com KSK validates .com DNSKEY with ZSK → ZSK validates mybank.com DS record which contains mybank.com KSK

mybank.com KSK validates mybank.com DNSKEY with ZSK → ZSK validates local.mybank.com DS record which contains local.mybank.com KSK

local.mybank.com KSK validates local.mybank.com DNSKEY with ZSK → ZSK validates www.local.mybank.com A record

Wait! What about root?

Need a trust starting point just like you need a DNS look up starting point

Validators maintain list of KSKs for trusted zones. These are updated either by hand, through some secure method or through Automated Updates of DNSSEC Trust Anchors (RFC 5011)

RFC 5011, in a nutshell is using current trust anchors to validate new ones. Software implementing this is just starting to gain traction but many lists are still maintain using other methods.

As of July 2010 root is signed (Yeah!)

What if a domain doesn't exist?

NXDOMAIN is returned, how do you sign it?

NSEC records fill this void

NSEC is a signed negative response. It spans a gap between two consecutive existing zones and includes the types of records the first of of the zones has

In this way the NXDOMAIN or NOERROR with no records can be signed too Consecutive zones... so there is an order? Yes!

Domain names in a zone are sorted rightmost label then the next label to the left and so on. Sorting is done case insensitive in dictionary order.

Order local.mybank.com, mybank.com, mybank.net, local.mybank.net, national.mybank.net and national.mybank.com:

mybank.com national.mybank.com local.mybank.com mybank.net national.mybank.net local.mybank.net

Yes, there is another option to NSEC...

More recently NSEC3 records have begun being used instead of NSEC

NSEC3 is a signed record with a hash of the name

Intent is to thwart automatic walking of all the names in a zone in an attack attempt.

RFC 5155

If this is still relatively new, what happens if someone in my chain isn’t signed?

A good number of zones are still unsigned and don't support DNSSEC, if one of those is above you in the trust chain you need to follow a slightly different method to DNSSEC secure yourself

To get a pseudo trust chain you can use DNSSEC Lookaside Validation (DLV)

DLV essentially uses a DLV service like the ISC (Internet Systems Consortium) as the trusted source for your DS records thus allowing the security aware resolver to “look aside” to the ISC server for the DS verification of the next step in the trust chain.

This requires you to trust the DLV service ahead of time and then upload your DS record for a signed zone to the DLV service

Since everyone in the world isn't using this there must be a reason or two...

It is still relatively new and takes a while to propagate

Root was just recently signed... It took a while politically, think about it, the trusted root signature is done by organizations strongly tied to the US and believe it or not the US isn't the favorite country of some nations.

It is more work to maintain → need to roll over the KSK roughly every 30 days and the ZSK about once a year which requires generating and storing the keys, resigning the zones then propagating the new DS records.

Many people think HTTPS is good enough.

Many end user tools don't have native support for DNSSEC checking. For example, no browser monitors it natively and a search revealed only FireFox has a free production level plugin supporting it.

Truthfully, DNSSEC isn't the most intuitive to setup/maintain which makes the barrier to entry on setting it up not worth it to many (which Dyn is trying to fix!)