• Ron Aitchison


When a name server receives the response to a query for, say, the A record of a web site, for instance,, it can only hope that the data is correct. It has no way of proving that this is the case. In fact, it could have been duped or spoofed in a variety of ways, such as the query response may have been supplied from a poisoned zone file, or the query may have been intercepted and bad data substituted in the response. Another possibility is the query may have been redirected by a poisoned resolver cache to a bogus server for the domain in question, or the response could be perfectly valid, containing good data from the correct source. In a situation where revenues, reputation, or security (commercial or national) are at stake, such uncertainty may be unacceptable. DNSSEC, originally defined in RFC 2535, was designed to eliminate the doubt involved in DNS query operations by providing verifiable certainty to suitably configured name servers. Significant efforts were expended over many years by multiple organizations, notably ISC (, Nlnetlabs (, some of the root-server operators (, and regional Internet registries (, to build and test secure DNS systems such that they can be scaled and deployed in operational environments. This Herculean effort led to what became known colloquially as DNSSEC.bis, but is now simply known as DNSSEC (defined by RFCs 4033, 4034, and 4035 and augmented by 4470, 4509, 5011, and 5155) and constitutes a substantial enhancement to the original specifications.


Universal Coordinate Time Secure Delegation Security Aware Zone File Private File 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Copyright information

© Ron Aitchison 2011

Authors and Affiliations

  • Ron Aitchison

There are no affiliations available

Personalised recommendations