DNSSEC is a procedure, with which authenticity and data integrity can be ensured by DNS transactions. DNS participants can thereby to verify that the server, with which it communicates is also actually that, to which it gives to be and that received DNS messages on the route of transportation were not falsified.

A coding of DNS data is not intended in contexts of DNSSEC. Since DNS information is put in principle to the public at the disposal, a coding would mean no considerable safety gain.

Overview

DNSSEC uses an asymmetrical Kryptosystem. The "“owner"” of information - usually the master server, on which the zone which can be secured abliegt - signs these with its secret key (English private keys). Arbitrary receivers can validate this signature with the public key (English public key) of the owner and examine thus authenticity and integrity.

The original, DNSSEC version defined in the RFC 2535, proved in practice due to a too key administration as unfit. The spreading of DNSSEC retarded thereby around several years until 2004 a complete revised version were published. In order to exclude with existing software, new resource records types were introduced (RRSIG replaces SIG, DNSKEY replaces KEY, NANOSECOND replaces NXT). In October 2005 with the Swedish SE-Domain a Top level Domain was digitally signed for the first time. Starting from this time DNSSEC is considered as imported standard. The responsible persons of other Top level Domains did so far without the introduction of DNSSEC, since the problem zone of the Walking is not yet solved.

Function mode

Owner of DNS information is for the zone, in which the information abliegt, autoritative master servers. For each zone which can be secured its own zone key (a pair, consisting of public and private key) is generated. The public part of the zone key is taken up as DNSKEY resource record to the zone file. With the private key each individual RR of this zone is digitally signed. In addition a new RR-type is made available, the RRSIG resource record, which contains the signature to the belonging to DNS entry. Example of a marked A-record:

nsf.f beispiel.de. A 172.27.182.17 RRSIG A 1 3 1000 20060616062444 (20060517062444 9927 f-beispiel.de. mMBIXxXU6buN53GWHTPpwEbse4aR2gNI8rgs g9/x1We23K3gkO5DBjFdty27Fj4FMbQzg0uB uv9aFcPaMyILJg==) 

With each transaction is provided beside actual resource the record also the associated RRSIG RR. With the zone transfer the Slaves receives it, when recursive dissolution it in the Cache is stored. Too better lastly it lands with the inquiring resolver. This can validate then on the basis the public zone key the signature.

Resource a record (more exact: resource a record set - thus a sentence of RRs of same type and name) can be signed also several times (with different keys). That is meaningful if the validity of a key will soon run off and one liked to publish promptly a successor. The keys are differentiated by a clear number, the keys ID (also "“key day"” mentioned). In addition a DNSSEC digital signature contains the date, starting from which it is valid as well as a final date, starting from which it loses its validity.

In order to facilitate the key management, a syntactically identical key signing key the zone key (English became additional: key signing keys) defines, with which excluding zone keys are signed. A such key signing key becomes for the formation of confidence chains (English: chain OF trusts) uses and additionally put down in the superordinate zone. Contrary to the frequently renewed zone key it possesses a long life span.

Evaluation by resolvers

Conventional DNS resolvers are not able to validate digitally signed DNS records. After DNS philosophy dominating at present resolvers are very simply developed programs, which would be overtaxed with complex DNSSEC operations. Instead the DNSSEC functions in a central - usually local - recursive name server are held, which has an efficient resolver. A Client, which would like to dissolve a name, sends an appropriate inquiry to this central server. By setting the DO bit (DNSSEC of OK ONE) in the DNS header it communicates that is to be authentifiziert. With successful Authentifizierung sets the central server in the answer the AD-bit (Authenticated DATA).

Non--existing names

With DNSSEC is also possible it to prove that a certain name does not exist. For this purpose with marking a zone file all entries are arranged alphabetically and concatenated over NANOSECOND resource record. The last name points thereby to first so that a circular chain develops. Example: name1->name2, name2->name5, name5->name1. To each name thereby exactly one nanosecond record which is marked likewise, exists. One inquires now by a resolver for example the not existing name3, then the name server supplies a negative answer and additionally the NANOSECOND record name2->name5. Since this NANOSECOND it is marked the resolver can be safe that between name2 and name5 no further entry is and thereby name3 does not exist. Example:

   name2 A 172.27.182.17 RRSIG A 1 3 1000 20060616062444 (20060517062444 9927 f-beispiel.de. mMBIXxXU6buN53GWHTPpwEbse4aR2gNI8rgs g9/x1We23K3gkO5DBjFdty27Fj4FMbQzg0uB uv9aFcPaMyILJg==) NANOSECOND name5 A RRSIG NANOSECOND RRSIG NANOSECOND 1 3 10000 20060616062444 (20060517062444 9927 f-beispiel.de. vlDpyqQF8b6VEtRRt5dZd+R2IVonLaJvpr6n 5flYJ90JYtaiwhPIQGsp44BH0pvcBCt9e/eD QoBh4eGjbW49Yw==) 

The concatenation of all records of a zone makes possible it to pick all contents out by zone Walking iterative. Thus safety-relevant information is possibly revealed to a potential aggressor.

Chain OF Trust

In order to ensure a safe Authentifizierung, the Public key of a zone (and/or its finger print) must be brought into the central server manually. Since normally each zone possesses another key, which besides regularly changes, the key administration can become very

The formation of chain OF Trusts (English: ) The key management facilitates confidence chains dramatically. One as highly as possible in the DNS tree settled zone contains the Public key of their delegated Subzonen and signs these digitally. The Subzonen knows again the marked Public key of their subordinated zones contained etc. for a such chain OF Trust must in the resolver of a central name server only the Public key of the highest zone admits to be. The total quantity of the quantity of zones, secured by only one key, becomes also as safety island (English: Iceland OF Security) designates. Ideally only one such Iceland OF Security for the entire name area and thus only one Trusted key exists. For the formation of confidence chains DS resource record are used. In the DS resource record of defined keys (more exact: A Hash of a key) corresponds to the key signer key of the subordinated zone.

By the formation of chain OF Trusts is simplified the key administration considerably, the resolvers must however in the most unfavorable case the chain from downside up to the highest zone go through and a multiplicity of cryptographic operations implement. Example:

 Two zones exist: the superordinate zone f-beispiel.de and the delegated Subzone filiale1.f-beispiel.de. Both zones are connected by a DS record to a chain OF Trust, so that in the resolver of the central name server only the key of the highest zone admits f-beispiel.de as Trusted keys be must. The highest zone f-beispiel.de has the key signing key: f-beispiel.de. IN DNSKEY 257 3 1 AQOW4333ZLdOHLRk+3Xe"… (shortened) and the zone key f-beispiel.de. IN DNSKEY 256 3 1 AQO+/cFBgAR4HbTlBSoP"… (shortened)

 into f-beispiel.de one point of delegation exists on the Subzone filiale1.f-beispiel.de, which is marked with the zone key of f-beispiel.de: filiale1 DS 52037 1 1 (378929E92D7DA04267EE87E802D75C5CA1B5D280) RRSIG DS1 3 1000 20060615115919 (20060516115919 9927 f-beispiel.de. AnMxvfH64hbf3OsPzTXz4B7w3vZ9ZCto/ugw AeKpbd0uijPe8Q==) (shortened) in the DS record is a Hash key signing keys of the subordinated zone filiale1.f-beispiel.de. 
 

 The subordinated zone filiale1.f-beispiel.de has the key signing keys: filiale1.f-beispiel.de. DNSKEY 257 3 1 AQOtPCW58VdBIOnKJaOzd"… (shortened)

 in the resolvers the key signing key of the highest zone f-beispiel.de as Trusted keys is registered manually: trusted key {"“f-beispiel.de."” 257 3 1 "“AQOW4333ZLdOH+"…"”; ); (shortened) 
  

Safety-relevant weak points of DNSSEC

• Denial OF service attacks are not prevented by DNSSEC but are even facilitated due to the higher cost of computation on the servers.
• Distributing the keys to the formation of chains OF Trust must take place manually and offers thereby points of attack.
• By means of DNSSEC Walking can be selected contents of zones completely or in parts.

Reference

• RFC 2065 (become outdated)
• RFC 2535 (become outdated)
• DNSSEC delegation Signer (RFC 3658)
• DNSSEC Intro RFC (RFC 4033)
• DNSSEC record RFC (RFC 4034)
• DNSSEC Protocol RFC (RFC 4035)

• DNSsec portal side
• Introduction to Secure DNS

Articles in category "DNSSEC"

We found here 15 articles.

Related Websites

We found here 3 related websites.

• DNSSEC - DNS Security Extensions
  Offers information about DNSSEC: Security Extensions for DNS. Includes DNSSEC projects, articles,...


• DNSSEC - Wikipedia, the free encyclopedia
  DNSSEC (short for DNS Security Extensions) is a suite of IETF ... It is widely believed that deploying DNSSEC is critically important for securing the ...


• ONLamp.com -- The Basics of DNSSEC
  David Gordon and Ibrahim Haddad provide a technical tutorial on DNS Security Extensions (DNSSEC), a technique for securing the Domain Name System.