Securing InteropNET with DNSSEC

Cory von WallensteinVP, Engineering – Dyn Inc.

Internet Infrastructure

as a Service

DynECT Managed DNS

& Email Delivery

• DNS is names to numberstwitter.com -> 199.59.148.82

• 5+ Million active users/clients

• 1000+ Enterprise clients

• 250,000+ Zones managed

• 100,000+ Domains registered

• 17 World-wide datacenters

• Billions of queries per day

• Billions of messages annually

User My Bank

Insecure HTTP… end user beware!

http – http://www.local.mybank.com

User My Bank

Add HTTPS… verify domain owner.

https – https://www.local.mybank.com

Is the domain correct?

User My Bank

But what verifies the IP in DNS?

https – https://www.local.mybank.com

Is the domain correct?

But what about the IP address 1.2.3.4 that www.local.mybank.com resolved to…

What verifies that?

www.local.mybank.com A 1.2.3.4

Quick DNS Terminology

Recap

• Authoritative DNS– The “authority” for DNS records– You as a web site owner or

operator designate your authoritative DNS servers at your registrar.

– Trusted information. Keys to the kingdom.

• Recursive DNS– Query authoritative servers on

behalf of clients (performing recursion as necessary) and caching answers for faster future lookups by other clients.

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

But I see the lock in the

browser window! I see “https” in the

URL!

Aren’t I safe?

• Partially!– The domain is verified– The IP address is not– Implicit trust in your

recursive DNS servers.

• Attack vectors– Single computer

• Edit /etc/hosts– One or more computers

• Man in the middle attack– Many, many computers

• Recursive DNS cache poisoning

DNS Cache Poisoning

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

Need a way to verify the

information in DNS.

Enter DNSSEC.

• Recursive resolvers and end users alike can verify the information in DNS.

• Chain of trust.– I trust the root nameservers.– The root servers trust .com,

and give me the information I need to verify .com hasn’t been tampered with.

– The .com servers trust mybank.com, and give me the information I need to verify mybank.com hasn’t been tampered with…

DNSSEC Secured

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

How do you 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”, publish to registrar!

dnsviz.net • Great visualization and debugging tool

• Verify chain of trust

• There’s a computer on this network called:– soloru.ny.enet.interop.n

et.

Get started with DNSSEC.

• Visit our booth - 236

• Reach out–cvw@dyn.com–@cvonwallenstei

n–@DynInc–Dyn.com