Providing Application-Level Assurances Using

DNSSECSuresh Krishnaswamy

SPARTA, Inc. dba Cobham Analytic Solutions

(suresh AT sparta DOT com)

Domain Name Service

•Internet infrastructure protocol that provides mapping between a human memorable name and some information about that name (e.g. IP address)

•Hierarchical, Decentralized, Scalable, redundant, highly available service that makes the Internet as useful as it currently is.

•Very easy to spoof!

Spoofing DNS Responses

• Difficulty level roughly that of correctly guessing two random 16-bit values

• Difficulty is even less

• … if one of the two 16-bit values is predictable

• … if the two 16-bit values are not *that* random

• … if name server sends out multiple queries for the same name in parallel, with different values for the two 16-bit values

• … if some NAT device reduces the effectiveness of any name server randomization technique

Why is this Important

•DNS resolution is normally the first step in most Internet communications

•Web site can be replaced with a false site without ever touching the victim site

•E-mail can be re-routed (SPF and DKIM also rely on the DNS)

•Login compromised through man in the middle attack

•Any technology that relies on DNS will be affected: Anti-spam, ENUM, SIP, etc

The DNS is transparent

Weather.com Foxnews.com

1 address = multiple DNS lookups

Spoof Example

Zone Data Administrators/ Name

Server Operators

The DNSSEC Piecescom

owasp

Registrants/Registrars Resolvers

DNS Namespace

(publish DNS content)

(lookup DNS data)(define the

namespace)

Root

org

edu

Dnssec-tools

test

Sign ZonesAdd Secure Delegations

Validate signed answers using a

Trust Anchor

EPP extensions, Registrar Interfaces

Zone Re-signing, Key

Rollover

TA Rollover

DNSSEC at the publication end

•The Root is signed!

•62/294 TLDs signed

•NET to be signed Dec 2010

•COM to be signed by March 2011

•Number of registrars are capable of accepting secure delegation information for their registrants.

•About 26K production DNSSEC-enabled zones according to SecSpider (http://secspider.cs.ucla.edu/)

DNSSEC at the validation end

•The Root is signed! (implies a single Trust Anchor)

•Top 4 Swedish ISPs

•COMCAST

•UCBerkeley

DNSSEC and FISMA•Applies to all systems that "host,

store, or process Federal information”.

•Requires DNSSEC signing of all zone data - internal and external zones, at all levels of the DNS tree.

•Validation required for high impact zones only, but will soon apply to lower impact levels.

The Last Mile

Stub

Recursive NS

Coffee shopsConferences

Airports

Actual response

Query

Spoofed response

First Response wins

Stub

Recursive NS

Certain ISPsHotels

NXDOMAIN rewriting

Query

Actual response

The Last Mile

In-application validation

•Central resolver can refuse to relay bad/insecure answers and can still be spoofed locally.

•Even if users are behind a central validating resolver at work, they may not be when they are traveling/using their phone to check email.

•Provides for validation up to the application. Important if we want to use the DNS for bootstrapping other security mechanisms.

•Provides better error codes to the applications

Retrofitting DNSSEC

•Internet applications have been using DNS for over 20 years.

•Significant liberties taken when processing error conditions based on the invalid assumption that no further changes would occur to the DNS.

•Example: error handling loops that do not have proper fallback cases to default “unknown error” handling code.

•No propagation of the DNS error code up multiple levels of the stack.

Authentication Chains

• Various error codes possible

• Maybe the name server failed to respond?

• Multiple records may be returned for a function call. E.g. getaddrinfo() can return A and AAAA; CNAME and its target may have completely different authentication chains.

• Each element in the authentication chain has its own validation status.

getaddrinfo(): badsign-alias.netsec.tislabs.com

CNAME

A

AAAA

Towards a validator API

•Standardizing the API is important.

•Starting from scratch would be great, but we have legacy code to worry about. Small code change footprint would be nice.

•Should be possible to take advantage of new error codes that DNSSEC returns.

•Bogus is bad, un-signed does not necessarily mean bad, validated is generally good, you may trust something even if you know it is bogus, and you may decide that you won’t accept some answers at all.

Proposed API

•Documented in “DNSSEC Validator API” draft-hayatnagarkar-dnsext-validator-api

•Two levels of DNSSEC-awareness

•High-level: “just tell me if I can use this answer or not”.

•Low-level: “need more information on why DNSSEC validation failed; was this answer actually validated or implicitly trusted?”.

•Different validation “contexts” for different validation policies, if needed.

Libval and its extensions

•C Library that implements the proposed API

•Perl module Net::DNS::Sec::Validator that wraps around the C library

•All available from www.dnssec-tools.org

DNSSEC-capable Apps

•SPF, MX validation

•Jabberd, wget, etc

% ./ssh ssh.example.com

The authenticity of host 'ssh.example.com

(192.168.1.1)' was validated via DNSSEC.

Warning: Permanently added

'ssh.example.com,192.168.1.1' (RSA) to the list

of known hosts.

Last login: Thu Sep 20 19:49:53 2007

Welcome to Darwin!

$

•Secure bootstrapping of the SSH key through the SSHFP record

Libval_shim

• LD_PRELOAD-based approach for adding DNSSEC capability to existing applications

• The shim library implements most of the commonly-used resolver functions

• Applications that use these functions can automatically become DNSSEC-capable if they run within an LD_PRELOAD environment with libval_shim.

• Many applications are known to work out of the box with libval_shim

Firefox with libval_shim

Validating within a browser

• DNS intensive application, with immediate visible effect when resolution fails.

• What if validation fails?

• Should the user be told that this was a DNSSEC issue?

• Avoid “Security check failed. Continue? Yes/No?”

Modifying Firefox

•Could not merely be an extension, had to be a patch.

•Allow user to enable/disable DNSSEC. All other policy knobs are within the validator library, libval.

•Content not loaded from domains that fail validation

•Better error messages when names do not exist.

•Somewhat of a challenge to throw the error to the user

•DNS error “lost” in the stack.

•Firefox does pre-fetching of names

DNSSEC-enabled Firefox

Some DNSSEC Indicators

Name does not exist. At All!

Other Possibilities

•Public keys in the DNS

•Force HTTPS

•ENUM

•Gaming Community

On the phone!

N900 Users: it's “lookup” in extras-testing

List of Resources

• http://www.dnssec-tools.org

• DNSSEC-enabled applications: firefox, thunderbird, openssh, postfix, sendmail libspf, wget, ncftp

• Zone Maintenance Tools: zonesigner, rollerd, donuts, mapper

• Troubleshooting Utilities:, dnspktflow, validate, getds, logwatch, test zone

• Validator C library, PERL modules

• http://www.dnssec-deployment.org

• Blog/News site devoted to DNSSEC Deployment.

• https://www.iana.org/dnssec

• Getting the Root Key

Summary/Next Steps

• We have been using DNS for the last 20 years as though it were already secure, when it really wasn’t.

• With DNSSEC we now have the basis for this security (and a signed Root!) such that that we can begin to use DNSSEC effectively.

• It’s possible to come up with innovative ways of using DNSSEC assurances within applications. As we develop new APIs consider how DNSSEC can be leveraged by the higher layers.

• As a web developer do you really need to fetch those remote javascript/css? If you do, are those names under a signed domain?

• What would you need from a DNSSEC capable browser so that your web apps can fail “smart”?

• Turn on validation!

Questions?