Domain Name System Security Extensions

The Domain Name System Security Extensions (DNSSEC ) are a set of Internet standards, expand the Domain Name System (DNS) to security mechanisms to ensure the authenticity and integrity of the data. A DNS participant can verify the fact that the obtained DNS zone data also are in fact identical with those who has authorized the creator of the zone. DNSSEC was developed as a means to cache poisoning. It ensures the transfer of resource records with digital signatures. An authentication server or client does not occur.

Confidentiality is not provided in DNSSEC, DNS data will therefore not be encrypted.

• 5.1 A concrete example of the. TLD de -

Overview

DNSSEC uses an asymmetric cryptosystem. The "owner " of information - usually the master server on which the hedged zone is - signed each record using his secret key (german private key). DNS clients can validate this signature with the public key (german public key) of the owner and thus verify the authenticity and integrity. DNSSEC requires the extension EDNS, additional parameters can be transmitted with the in DNS messages. Furthermore EDNS raises the size limit of DNS messages over UDP 512 bytes. For the transmission of keys and signatures considerably longer DNS messages are required.

The original, in March 1999 defined in RFC 2535 DNSSEC version, proved in practice due to a complex key management as unfit. The distribution of DNSSEC was delayed by several years, to 2005, a complete rewrite was released. In order to eliminate incompatibilities with existing software, new resource record types have been introduced ( RRSIG replaced SIG, KEY replaced DNSKEY, NSEC replaced NXT ). In October 2005, with the Swedish. Se domain for the first time a top -level domain digitally signed. The leaders of some other top-level domains, so also. De, waiting for a solution to the zone Walkings and open organizational issues. With the introduction of the NSEC3 Resource Records in March 2008 Zone Walking was considered sufficiently difficult.

On 5 May 2010 DNSSEC was introduced on all 13 root servers; On 15 July, the Rootzonenschlüssel was published and the DNS root zone of the order of validated. Approximately 100 top -level domains signed with DNSSEC and most of them are marked in the root zone as signed. A few test DNSSEC still no entry in the root zone.

Operation

Information is provided in DNS Resource Records in (RR). DNSSEC ensures the authenticity of this information by a digital signature. Owner of a DNS information is the one master server that is authoritative for the zone in which the information is located. For any hedged zone is a separate zone key ( engl.: zone signing key) ( a pair consisting of a public and private key ) is generated. The public part of the key zone is taken as DNSKEY resource record in the zone file. The private key of each individual RR this zone is digitally signed. Therefore a new RR type is provided, the RRSIG resource record that contains the signature belonging to the DNS entry. Example of a signed A- Records:

Nsf.example.org. A 172.27.182.17                       RRSIG A 1 3 1000 20060616062444 (                                          20060517062444 9927 example.org.                                          mMBIXxXU6buN53GWHTPpwEbse4aR2gNI8rgs                                          g9/x1We23K3gkO5DBjFdty27Fj4FMbQzg0uB                                          uv9aFcPaMyILJg ==) For each transaction, in addition to the actual resource record and the associated RRSIG RR is included. In zone transfer the slaves get him in recursive resolution it is stored in the cache. Finally, he lands in the requesting resolver. This can then validate the signature using the public key zones.

A Resource Record (more precisely: a Resource Record Set - ie a set of RRs of the same type and name) can be signed ( with different keys ) several times. This is useful when the validity of a key will expire soon and you want to publish a successor early. The keys are identified by a number, the key day. A digital signature also contains DNSSEC in the date from which it is applicable and an end date on which it ceases to be valid. Moreover, the algorithm used is specified.

Key Management

To facilitate key management, a syntactically identical key Signature Key (English: key signing key, KSK ) was in addition to the keys for the signature of the zone ( zone signing key, ZSK ) defined. In the DNSKEY record flags field bit 7 is set if the key contained is used for the signature of Resource Record Sets the zone. This applies to KSKs and ZSKs: With the KSKs DNSKEY records are signed and with the ZSKs all other records. Bit 15 ( Secure Entry Point) is set if the key is the starting point for the validation of the zone - this applies to KSKs. Because other bits are not used so far, the flags field has the value 256 for ZSKs and 257 for KSKs.

This only KSK DNSKEY records are signed, which contain the actual zone key. Such key Signature key is for the formation of trust chains (English: chains of trust ) are used. A hash of the KSK is stored in the parent zone in a DS record, thus the authenticity of the signed zone key DNSKEY record can be ensured. In contrast to the frequently renewed key KSK zone has a long life.

Evaluation by Resolver

DNS resolver on devices such as personal computers or smart phones ( called in the DNS terminology Stubresolver ) are usually not able to validate digitally signed DNS records. According to the currently dominant DNS philosophy Stubresolver are very simply constructed programs that rely on the full name resolution to a recursive name server. A Stubresolver who wants to resolve a name, sends a request to a name server in the local network or the network of the internet service provider. By setting the bits DO (DNSSEC OK) in DNS header, the resolver can tell the name server that validation should be performed. To this end, the Stubresolver must support the EDNS extension, since there the DO bit has been specified. However, the recursive DNS servers can be configured to validate always be performed irrespective of the presence or the content of the DO bits. If authentication succeeds, the server sets the AD bit (Authenticated Data) in the response. If authentication fails, the server returns a generic error. For the Stubresolver it is not clear whether the error caused by a failed validation is triggered or not. Due to any cause, eg network failure or server failure name of the requested domain name

Non-existent name

One can use DNSSEC also prove that a certain name does not exist. To this end, all entries are arranged alphabetically and concatenated over a NSEC resource record when signing a zone file. The last name pointing to the first, so that an annular chain is formed. Example: name1 name2 →, → name2 name5, name5 → name1. For each name so that there is exactly one NSEC record, which is also signed. If now, for example, the interrogated by a resolver that does not exist name3, the name server returns a negative response, and in addition the NSEC record name2 → name5. Since this NSEC is signed, the resolver can be sure that there is no other entry is between name2 and name3 name5 and therefore does not exist. example:

Name2 A 172.27.182.17                 RRSIG A 1 3 1000 20060616062444 (                                  20060517062444 9927 example.org.                                  mMBIXxXU6buN53GWHTPpwEbse4aR2gNI8rgs                                  g9/x1We23K3gkO5DBjFdty27Fj4FMbQzg0uB                                  uv9aFcPaMyILJg ==)                 A RRSIG NSEC NSEC name5                 RRSIG NSEC 1 3 10000 20060616062444 (                                  20060517062444 9927 example.org.                                  vlDpyqQF8b6VEtRRt5dZd R2IVonLaJvpr6n                                  5flYJ90JYtaiwhPIQGsp44BH0pvcBCt9e/eD                                  QoBh4eGjbW49Yw ==) The concatenation of all records of a zone makes it possible to read out the entire contents by iteratively zone walking. Thus, an attacker may be revealed security or confidential information, such as a list of all customer domains. In March 2008, the NSEC3 record is defined by RFC5155, the hash values ​​of domain names returns instead of clear text domain name and so complicates the zone walking. An attacker must perform a computationally complex dictionary attack to obtain the hash values ​​from the domain name. To complicate this further, a repeated application of the hash function provided, and the use of salt. BIND supports NSEC3 since version 9.6 and NSD since version 3.1.

Chain of Trust

To ensure secure authentication, the public key of a zone must (or its hash ) are introduced into the central server to resolve the name manually. Since normally each zone has a different key, which also changes regularly, key management can be very complex.

The formation of chains of trust (English: Chains of Trust) simplifies key management dramatically. A moved as high as possible in the DNS tree zone contains the public keys of its delegated subzones and signs it digitally. The subzones can turn the signed public keys of its child zones contain, etc. For such a chain of trust must be in a central resolver name server, only the public key of the uppermost zone to be known. The total amount of the secured by a single key set of zones is also known as safety island (English: Iceland of Security ) refers. In the ideal case, there is only one such Iceland of Security for the entire name space and therefore only a single Trusted Key. For the formation of chains of trust DS resource records are used. A defined in the DS resource record hash of a key corresponds to the key signer key of the child zone.

Due to the formation of chains of Trust Although the key management simplifies considerably, but the resolver must go through in the worst case, the chain from the bottom up to the top zone and perform a variety of cryptographic operations. example:

There are two zones: the parent zone example.org. and the delegated subzone filiale1.example.org .. Both zones are connected via a DS record to a chain of trust, so that in the resolver of the central name server example.org only the key of the uppermost zone. must be known as a trusted key.

The highest zone example.org. has the key Signature key:

Example.org. IN DNSKEY 257 3 1 AQOW4333ZLdOHLRk 3 Xe ... ( abridged) and the zone keys

Example.org. IN DNSKEY 256 3 1 AQO / cFBgAR4HbTlBSoP ... ( abridged) In example.org a delegation point exists on the subzone filiale1.example.org. , The. Zone with the key of example.org Signed:

Branch1 DS 52037 1 1 ( 378929E92D7DA04267EE87E802D75C5CA1B5D280 )              RRSIG DS 1 3 1000 20060615115919 (                                  20060516115919 9927 example.org.                                  AnMxvfH64hbf3OsPzTXz4B7w3vZ9ZCto/ugw                                  AeKpbd0uijPe8Q ==) ( abridged) In the DS record, a hash of the key 's signature key of the child zone is filiale1.example.org ..

The child zone filiale1.example.org. has the key Signature key:

Filiale1.example.org. DNSKEY 257 3 1 AQOtPCW58VdBIOnKJaOzd ... ( abridged) In the resolvers of key Signature key of the highest zone is example.org. manually entered as Trusted Key:

Trusted-keys ( " example.org. " 257 3 1 " AQOW4333ZLdOH ..."; ); (shortened) A concrete example of the. TLD de -

The root name server to support DNSSEC since 2010. . To a de domain with a chain of trust to secure exist the following measures:

• The root servers provide a DS record from the de. - zone. This contains a hash of the key German signing key ( Key signing key):

De. IN DS 24220 8 2 FFE926ACA67ED94089390250F1F294AC84A6D84F9121DF73A79E439F 42E820C2. The DS record is signed with the zone key of the root zone.

• The key signing key (indicated by the number 257) of the German zone (whose hash in the DS record is on the root servers ) is

De. IN DNSKEY 257 3 8 AwEAAYbcKo2IA8l6arSIiSC l97v2vgNXrxjBJ ... ( abridged)

• With this key signing key again, the DNSKEY record of the German zone is signed (by RRSIG ) that contains the zone key (indicated by the number 256). A resolver knows now that the German zone key is genuine, because it is locked with a key, which is confirmed by the root servers as real.

De. IN DNSKEY 256 3 8 AwEAAZ4e4Nf1SpBWMhSK6ha YeJyq ... ( abridged)

• In order to secure a German domain by DNSSEC, in the de. - zone alongside the usual delegation Record ( NS) is in turn creates a DS record with the key signing key of the domain. A resolver can recognize the authenticity of the zone key of the domain now turn, as the DNSKEY record, which contains the zone key is signed by a key ( RRSIG! ) whose hash is DENIC.

View

Securing the name server queries using DNSSEC provides no guarantee that the communication is genuine or even encrypted with the so- determined IP address. Corrupt routing for example, could see packets that are sent to a properly identified with DNSSEC destination IP address to the wrong computer. However, there are considerations not only destination addresses, but also public keys or certificates for communication with IPsec or TLS secured by DNSSEC to spread (see Recource Record types and ipseckey CERT ). This could be as distributed, self-signed certificates in competition issued by certification bodies occur, which often only verify the domain name of the server. Since the resolver infrastructure will make are not reliably available to DNSSEC foreseeable future, there are further considerations to take off the entire chain of trust by an appropriate certificate and can be used similar to certificates of certification bodies by the applications. The safety level would correspond to the trust model of DNSSEC.

Reported vulnerabilities of DNSSEC

• Denial- of-service attacks on nameservers are not prevented by DNSSEC, but even easier due to the higher load on the servers.
• DNS Amplification Attacks taking advantage of the public DNS infrastructure to be effective, as DNS replies with DNSSEC are significantly longer.
• The public key for verification is also distributed through the DNS system. This attack opportunities arise on the chains of trust. This can be prevented if the public key of the trust origin (English: Trust Anchor ) is (for example, with the operating system or the server or client software) distributed by means other than the DNS infrastructure.
• Using DNSSEC Walking can be completely read out the content of zones ( complicated by NSEC3 ).
• Since Stubresolver often not validate the DNS responses itself, an attack on the communications link to their recursive name server can take place. Also, the recursive name server itself may be compromised.

Practical Problems

Currently finds the key generation and management instead of only two U.S. sites. After much RIPE experts, a location outside the U.S. is essential. Critics of ICANN prior to jeopardize the independence of the Internet by DNSSEC key management in the United States. As Signierungspartner ICANN had only provided the American company Verisign. The U.S. Department of Homeland Security called for in the same year to put the key management completely in the hands of the U.S. government. Discuss the ICANN subgroup Internet Assigned Numbers Authority (IANA) has also been an alternative to entrust the management of the root key. The U.S. government initially said the publication of a corresponding ICANN proposal. ICANN is formally independent, but still the U.S. government reserves the right to supervision.

Political decisions had been cases in the context of armed conflict ICANN. So was exposed as part of the Afghanistan War, the administration of the Afghan zone until a new government was in power. North Korea's delegation was - prevented three years in the management of their zone - with reference to the form error. The operators of the Iraqi address zone (. Iq ) were convicted in 2006 in the United States for violations of the Foreign Trade Law and the support of a member of Hamas to prison terms of between five and a half and seven years. Iq- zone remained without administrator long.