mail us  |  mail this page

contact us
training  | 
tech stuff  | 

BIND 9 Support

DNSSEC Lookaside Validation

Orignally written 2009.

DNSSEC is a powerful tool to combat, among others, Phishing and Pharming and other unpleasant side effects of life on the modern Internet. At a more strategic level it is the only method that can ensure integrity of the domain name space - it is the only method that can ensure that your domain name has not already been hijacked. To invoke DNSSEC, domain owners are required to sign their zones and DNS caching name servers must be configured to be security aware (by using the BIND named.conf dnssec-enable yes; statement in the options clause).

DNSSEC works by using trust anchors and chains of trust. A trust anchor is the public key of a signed zone (obtained using an out-of-band trusted process) and made visible to a name server which wishes to authenticate the zone (or domain). In BIND this is accomplished using the trusted-keys clause. A signed zone, which is authenticated by the trusted-keys clause, covers (allows authentication of) all domains (zones) below it in the domain name hierarchy by following the chain of trust through the delegation points - the Delegated Signer (DS) RRs - in the parent zone file. Figure 1-1 illustrates this process by showing that the trusted key for example.com also authenticates the zone sub.example.com.

trusted anchor for a domain

Figure 1 Secure Delegation - Chains of Trust

It will be obvious that these islands of security do not scale well and outside of affinity groups or critical infrastructure domains - where it is vital to ensure the integrity of the DNS data - have limited applicability. As the number of islands of security grow the number of trusted keys that need to be stored and maintained in any given security aware name server becomes impossibly large.

However by way of illustrating the change of effectiveness when the chain of trust moves up the domain name hierarchy consider Figure 2.

trusted anchor chain of trust

Figure 2 Securing the Domain Name Hierarchy

In this case a single trusted key for the .com zone will cover all signed .com zones - including example.com and sub.example.com in the example above. Clearly signing the root will have an even more significant effect - a single trusted key will cover the whole domain name space.

For a variety of political, technical, resource, commercial and cultural (read risk-averse) reasons it may be some time before the various gTLD, ccTLD, sTLD and root zone files are signed. In the meantime the entire DNS system is vulnerable to attack and hijacking.

An intolerable state of affairs for a core internet service.

DLV - A Tactical Alternative

There is a tactical alternative solution to the lack of TLD zone signing called DNSSEC Lookaside Validation (DLV). DLV enables one or more alternative chain of trust and functionally identical domain authentication without the need for any of the domain hierarchies (the TLDs) to have signed zone files. DLV is not an IETF standarized feature (RFC 4431 describes DLV but has Informational status only) and was released with BIND 9.3.0 (BIND 9.3.2 is the current recommended implementation version). DLV uses standard DNSSEC procedures and signed zone files but requires the addition of one or more dnssec-lookaside statements in a options clause. If a security aware name server reads a signed zone and fails to find either a signed parent - through which it can track secure delegation - or a trusted-keys clause for the zone it can use a secondary source, defined by the dnssec-lookaside statement(s), to authenticate the signed zone. The DLV service therefore creates an alternative chain of trust as illustrated by Figure 3.

DLV and trusted anchors

Figure 3 DLV chain of trust

In the case illustrated above if the query to the parent zone (.com) does not yield a secure delegation (through the DS RRs) a query is constructed to the lookaside domain - in the particular case shown the query would request DLV RRs (functionally identical to DS RRs) for example.com.dlv.example.net. Depending on how the DLV lookaside server was constructed a single DLV (and hence trusted-key) could be constructed to cover the entire domain name space or multiple DLV services could be constructed each of which would have different scope.

DLV uses standard name server software and zone files - there is nothing excessively magical about it. A more detailed description of DLV and how to configure both DLV servers and DLV aware caching name servers is available in this extract from Chapter 11 of Pro DNS and BIND.

DLV is an alternative way to provide fully functional DNSSEC authentication services to bring much needed security to a currently vulnerable resource - the DNS - rather than wait for the various organisations charged with implementing DNSSEC functionality to continue at their, with the notable exceptions of Sweden and RIPE, glacial like progress. Though with the current effect of global warming on the world's glaciers there may be good reason to suspect that glaciers are moving significantly faster than ICANN and most of the gTLD, ccTLD and sTLD registry operators.

DLV offers an immediate - perhaps tactical - solution which may be used in one or more of the following ways to bring immediate benefits to DNS:

  1. As a test bed. DNSSEC brings significant new complexities to running DNS servers. New procedures and operational practices need to be developed and honed to perfection before committing to live operations. DLV brings 'near' live exposure and in the event of unacceptable delays could be made fully live. Such test beds could be run internally, by industry or affinity groups or ccTLD, gTLD registry operators (indeed Verisign Labs are already running one such public test-bed).

  2. As a live service to protect critical infrastructure. Governments and other agencies and organizations deemed part of the critical national infrastructure should already be using DLV style service (and exerting significant pressure on their respective ccTLD operators for full DNSSEC implementation) and be using security aware caching name servers to ensure that in the event of a national crisis, core communications are not paralyzed. Image for a second the amplification effect of a terrorist attack if at the same time the same terrorist organization had hijacked the DNS such that Internet communication were rendered useless or, more subtly, dis-information was provided.

  3. As a commercial service for security conscious organizations. Organizations for whom security is a priority - and this should include any organization which maintains sensitive or personal data on its clients (including but not limited to financial institutions, e-commerce sites, government agencies) - should already be using DNSSEC/DLV on their domains. In addition they should also be mandating (or even operating) security aware caching name servers and providing security aware resolvers to ensure end-to-end security for their clients. This a business opportunity that could already be yielding results, revenue - and peace of mind.

Today, right now, using the DNS services provided by all the worthy agencies referred to above I have absolutely no way of knowing that when I access my on-line banking account that it has, or has not, been hijacked. Actually that is not quite right - after my identity has been stolen, after my bank account has been cleaned out and after my credit cards are maxed out - then I would know. And some people are worried about SPAM. When the bad guys start hijacking the DNS we'll all long for the days when we only had to worry about SPAM.



Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.

Copyright © 1994 - 2024 ZyTrax, Inc.
All rights reserved. Legal and Privacy
site by zytrax
hosted by javapipe.com
web-master at zytrax
Page modified: January 20 2022.

Pro DNS and BIND by Ron Aitchison

Contents

tech info
guides home
dns articles
intro
contents
1 objectives
big picture
2 concepts
3 reverse map
4 dns types
quickstart
5 install bind
6 samples
reference
7 named.conf
8 zone records
operations
9 howtos
10 tools
11 trouble
programming
12 bind api's
security
13 dns security
bits & bytes
15 messages
resources
notes & tips
registration FAQ
dns resources
dns rfcs
change log

Creative Commons License
This work is licensed under a Creative Commons License.

If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox

web zytrax.com

Share Page

share page via facebook tweet this page submit page to stumbleupon submit page to reddit.com

Page Features

Page comment feature Send to a friend feature print this page Decrease font size Increase font size

RSS Feed Icon RSS Feed

Resources

Systems

FreeBSD
NetBSD
OpenBSD
DragonFlyBSD
Linux.org
Debian Linux

Applications

LibreOffice
OpenOffice
Mozilla
SourceForge
GNU-Free SW Foundation

Organisations

Open Source Initiative
Creative Commons

Misc.

Ibiblio - Library
Open Book Project
Open Directory
Wikipedia

SPF Resources

Draft RFC
SPF Web Site
SPF Testing
SPF Testing (member only)

Site

CSS Technology SPF Record Conformant Domain
Copyright © 1994 - 2024 ZyTrax, Inc.
All rights reserved. Legal and Privacy
site by zytrax
hosted by javapipe.com
web-master at zytrax
Page modified: January 20 2022.