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.
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.
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.
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:
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).
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.
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.
RSS Feed
