Domain Name System Security Extensions

from Wikipedia, the free encyclopedia
DNSSEC in the TCP / IP protocol stack :
application DNSSEC
transport UDP TCP
Internet IP ( IPv4 , IPv6 )
Network access Ethernet Token
bus 		Token
ring 		FDDI ...

The Domain Name System Security Extensions ( DNSSEC ) are a series of Internet standards that add security mechanisms to the Domain Name System (DNS) to guarantee the authenticity and integrity of data. A DNS participant can use this to verify that the DNS zone data received are actually identical to those authorized by the creator of the zone. DNSSEC was developed as a remedy against cache poisoning . It secures the transmission of resource records through digital signatures . There is no authentication of servers or clients.

DNSSEC does not provide confidentiality , therefore DNS data is not encrypted .

overview

DNSSEC uses an asymmetric cryptosystem . The "owner" of information - usually the master server on which the hedged zone is - signed every single record using its secret key (Engl. Private key ). DNS clients can use this signature with the public key (Engl. Public key ) the owner validate and verify authenticity and integrity. DNSSEC requires the Extended DNS extension , which can be used to transfer additional parameters in DNS messages. EDNS also removes the 512 bytes size limit for DNS messages over UDP . Significantly longer DNS messages are required to transmit keys and signatures.

The original DNSSEC version, defined in RFC 2535 in March 1999 , turned out to be unsuitable in practice because the key management was too complex. The spread of DNSSEC was delayed by several years until a complete new version was published in 2005. In order to rule out incompatibilities with existing software, new resource record types have been introduced ( RRSIG replaces SIG , DNSKEY replaces KEY , NSEC replaces NXT). In October 2005 a top-level domain was digitally signed for the first time with the Swedish .se domain . Since May 2011 DNSSEC has also been available for .de domains in principle, after zone walking was made more difficult by the introduction of the NSEC3 Resource Record in March 2008.

On May 5, 2010, DNSSEC was introduced on all 13 root servers ; on July 15th the root zone key was published and the DNS can be validated from the root zone. In the meantime, 90% of the top-level domains are signed with DNSSEC and marked as signed in the root zone. A few are testing DNSSEC without an entry in the root zone. The spread of DNSSEC at domain level is now 50% or more for some TLDs. On average, around 10% of the domains validate.

functionality

Information is provided in Resource Records (RR) at DNS . DNSSEC ensures the authenticity of this information by means of a digital signature . The owner of DNS information is the master server that is authoritative for the zone in which the information is located. Is a separate zone for each hedged zone keys (engl .: zone signing key ) (a pair consisting of the public and private key) is generated. The public part of the zone key is included in the zone file as a DNSKEY resource record . Each individual RR in this zone is digitally signed with the private key. A new RR type is provided for this purpose, the RRSIG Resource Record , which contains the signature for the associated DNS entry. Example of a signed A record: 

nsf.example.org. A       172.27.182.17
                     RRSIG   A 1 3 1000 20060616062444 (
                                        20060517062444 9927 example.org.
                                        mMBIXxXU6buN53GWHTPpwEbse4aR2gNI8rgs
                                        g9/x1We23K3gkO5DBjFdty27Fj4FMbQzg0uB
                                        uv9aFcPaMyILJg== )

In addition to the actual resource record , the associated RRSIG-RR is also supplied with every transaction . During zone transfer him get the slaves with recursive resolution it is stored in the cache. Finally, it ends up at the requesting resolver. This can then validate the signature using the public zone key.

A resource record (more precisely: a resource record set - i.e. a set of RRs of the same type and name) can also be signed multiple times (with different keys). This makes sense if the validity of a key is about to expire and you want to publish a successor at an early stage. The keys are identified by a number, the key tag . In DNSSEC, a digital signature also contains the date from which it is valid and an end date from which it becomes invalid. The algorithm used is also specified.

Key management

To facilitate Keymanagement was in addition to the key for the signature of the zone ( zone signing key , ZSK) a syntactically identical Key Signature Key (engl .: key signing key , KSK) are defined. Bit 7 is set in the flags field of the DNSKEY record if the key contained is used to sign resource record sets in the zone. This applies to KSKs and ZSKs: DNSKEY records are signed with the KSKs and all other records are signed with the ZSKs. Bit 15 (Secure Entry Point) is set if the key is the starting point for validating the zone - this applies to KSKs. Since other bits have not yet been used, the flags field has the value 256 for ZSKs and 257 for KSKs.

This KSK only signs DNSKEY records that contain the actual zone keys. Such Key Signature key is for the formation of confidence chains (ger .: chains of trust used). A hash value of the KSK is stored in the higher-level zone in a DNS record, which means that the authenticity of the zone keys in the signed DNSKEY record can be ensured. In contrast to the frequently renewed zone key, a KSK has a long service life.

Evaluation by resolver

DNS resolvers on end devices such as workstations or smartphones ( called stub resolvers in DNS terminology ) are usually not able to validate digitally signed DNS records. According to the currently dominant DNS philosophy, stub resolvers are very simply structured programs that rely on a recursive name server for complete name resolution . A stub resolver that wants to resolve a name sends a corresponding request to a name server in the local network or in the network of the Internet service provider . By setting the DO bit ( DNSSEC OK ) in the DNS header, the resolver can inform the name server that the validation should be carried out. To do this, the stub resolver must support the Extended DNS extension , since the DO bit was specified there. However, the recursive name server can also be configured to always carry out the validation, regardless of the presence or content of the DO bit. If the authentication is successful, the server sets the AD bit ( Authenticated Data ) in the response . If the authentication fails, the server returns a general error. The stub resolver cannot tell whether the error was triggered by a failed validation or by another cause, for example network failure or name server failure of the requested domain name.

Non-existent names

You can also use DNSSEC to prove that a certain name does not exist. For this purpose, when a zone file is signed, all entries are sorted alphabetically and linked via an NSEC resource record . The last name points to the first, so that a ring-shaped chain is created. Example: name1 → name2, name2 → name5, name5 → name1. For each name there is exactly one NSEC record, which is also signed. If, for example, the non-existent name3 is requested by a resolver , the name server delivers a negative response and also the NSEC record name2 → name5 . Since this NSEC is signed, the resolver can be sure that there is no further entry between name2 and name5 and that name3 does not exist. Example: 

   name2       A       172.27.182.17
               RRSIG   A 1 3    1000 20060616062444 (
                                20060517062444 9927 example.org.
                                mMBIXxXU6buN53GWHTPpwEbse4aR2gNI8rgs
                                g9/x1We23K3gkO5DBjFdty27Fj4FMbQzg0uB
                                uv9aFcPaMyILJg== )
               NSEC    name5  A RRSIG NSEC
               RRSIG   NSEC 1 3 10000 20060616062444 (
                                20060517062444 9927 example.org.
                                vlDpyqQF8b6VEtRRt5dZd+R2IVonLaJvpr6n
                                5flYJ90JYtaiwhPIQGsp44BH0pvcBCt9e/eD
                                QoBh4eGjbW49Yw== )

The chaining of all records of a zone makes it possible to read out the entire content iteratively by zone walking . This may reveal security-relevant or confidential information to an attacker, such as a list of all customer domains. In March 2008, the NSEC3 entry was defined with RFC5155, which returns the hash values ​​of domain names instead of plain text domain names and thus makes zone walking more difficult. An attacker would have to carry out a computationally intensive dictionary attack in order to obtain the domain names from the hash values. To make this even more difficult, repeated use of the hash function is planned, as well as the use of salt . BIND supports NSEC3 from version 9.6 and NSD from version 3.1.

Chain of trust

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

The formation of confidence chains (ger .: Chains of Trust ) facilitates key management dramatically. A zone located as high as possible in the DNS tree contains the public keys of its delegated subzones and signs them digitally. The sub-zones can in turn contain the signed public keys of their subordinate zones, etc. For such a chain of trust, only the public key of the uppermost zone needs to be known in the resolver of a central name server. The total amount of the secured by a single key set of zones as a safety island (ger .: Iceland of Security called). Ideally, there is only one such island of security for the entire namespace and therefore only one trusted key . DS Resource Records are used to create chains of trust . A hash of a key defined in the DS Resource Record corresponds to the key-signer key of the subordinate zone.

The formation of chains of trust simplifies key management considerably, but in the worst case the resolvers have to run through the chain from the bottom to the top zone and perform a large number of cryptographic operations. Example:

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

The parent zone example.org. has the key signature key: 

  example.org. IN DNSKEY 257 3 1 AQOW4333ZLdOHLRk+3Xe...           (gekürzt)

and the zone key 

  example.org. IN DNSKEY 256 3 1 AQO+/cFBgAR4HbTlBSoP...           (gekürzt)

In example.org there is a delegation point to the subzone filiale1.example.org. that is created with the zone key from example.org. is signed: 

 filiale1   DS      52037 1 1 ( 378929E92D7DA04267EE87E802D75C5CA1B5D280 )
            RRSIG   DS 1 3 1000 20060615115919 (
                                20060516115919 9927 example.org.
                                AnMxvfH64hbf3OsPzTXz4B7w3vZ9ZCto/ugw
                                AeKpbd0uijPe8Q== )                     (gekürzt)

The DS record contains a hash of the key signing key of the sub-zone filiale1.example.org. .

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

 filiale1.example.org. DNSKEY 257 3 1 AQOtPCW58VdBIOnKJaOzd...   (gekürzt)

In the resolvers, the key signature key of the higher-level zone example.org. entered manually as trusted key : 

 trusted-keys { "example.org." 257 3 1 "AQOW4333ZLdOH+..."; };  (gekürzt)

A concrete example at the .de TLD

The root name servers have supported DNSSEC since 2010. The following measures are in place to secure a .de domain with a chain of trust:

  • The root servers deliver a DS record for the de. zone. This contains a hash of the German 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 (recognizable by the number 257) of the German zone (whose hash is in the DS record on the root servers) is

de. IN DNSKEY 257 3 8 AwEAAYbcKo2IA8l6arSIiSC + l97v2vgNXrxjBJ ... (shortened)

  • This key signing key in turn signs the DNSKEY record of the German zone (using RRSIG), which contains the zone key (recognizable by the number 256). A resolver now knows that the German zone key is genuine, as it is secured with a key that is confirmed as genuine by the root servers.

de. IN DNSKEY 256 3 8 AwEAAZ4e4Nf1SpBWMhSK6ha + YeJyq ... (shortened)

  • In order to secure a German domain via DNSSEC, a DS record with the hash of the key signing key of the domain is created in the de. zone in addition to the usual delegation record (NS) . A resolver can in turn recognize the authenticity of the domain's zone key, since the DNSKEY record containing the zone key was signed by a key (RRSIG!) Whose hash is held by DENIC .

Limits of DNSSEC

Only the name server queries are secured by DNSSEC. This is mainly useful in connection with encrypting transmission protocols such as TLS . The combination of DNSSEC and TLS still has weak points. Corrupt routing could, for example, deliver packets that are sent to a destination IP address correctly determined with DNSSEC to the wrong computer. If this computer can identify itself through a compromised or accidentally issued certificate, this is not noticed. This is where DANE comes in , for example , to secure the interaction between DNSSEC and TLS.

Security-relevant vulnerabilities of DNSSEC

  • Denial-of-service attacks on name servers are not prevented by DNSSEC, but are even made easier due to the higher load on the servers.
  • DNS amplification attacks using the public DNS infrastructure become more effective, as DNS responses with DNSSEC are significantly longer.
  • The public keys for verification are also distributed via the DNS system. This creates opportunities for attacks on the chains of trust. This can be prevented if the public key of the origin of trust (Trust Anchor) is distributed in a way other than the DNS infrastructure (for example with the operating system or the server or client software).
  • The content of zones can be read out completely using DNSSEC Walking (made more difficult by NSEC3 ).
  • Since stub resolvers often do not validate the DNS responses themselves, an attack can take place on the communication path to your recursive name server. The recursive name server itself can also be compromised.

Management of the root zone key

Currently, the DNSSEC key for the root zone is only managed at two US locations. According to many RIPE experts, a location outside the USA is essential. Critics accuse ICANN of jeopardizing the independence of the Internet through DNSSEC key management in the USA. ICANN had only designated the American company Verisign as the signature partner. In 2007, the US Department of Homeland Security requested that key management be completely in the hands of the US government. It was also discussed, alternatively, entrusting the ICANN subgroup Internet Assigned Numbers Authority (IANA) with the administration of the root key. The US government initially prohibited the publication of a corresponding ICANN proposal. ICANN is formally independent, but the US government retained supervision until September 2016.

See also

literature

  • Christoph Sorge, Nils Gruschka, Luigi Lo Iacono: Security in communication networks. Oldenbourg Wissenschaftsverlag, Munich 2013, ISBN 978-3-486-72016-7 .

Norms and standards

Web links

Individual evidence

  1. ↑ DNSSEC: www.denic.de. In: DENIC . May 12, 2014, accessed May 12, 2014 .
  2. ↑ DNSSEC started in the root zone . Heise news
  3. ^ TLD DNSSEC report. In: ICANN . November 21, 2017, accessed November 21, 2017 .
  4. ↑ .nl stats and data - Insight into the use of .nl. In: SIDN . November 21, 2017, accessed November 21, 2017 .
  5. ↑ Dashboard - CZ. Statistics. In: CZ.NIC . November 21, 2017, accessed November 21, 2017 .
  6. ↑ Eurid in 2016 - Annual report 2016. In: EURid . April 3, 2017, accessed November 21, 2017 .
  7. ↑ DNSSEC Validation Capability Metrics - Use of DNSSEC Validation for World (XA). In: APNIC . November 21, 2017, accessed November 21, 2017 .
  8. ↑ DNS Security Algorithm Numbers
  9. ↑ DNSSEC on all root servers . Heise News, May 6, 2010
  10. ↑ Question of Power - Who Controls the Internet? In: c't , 5/2010
  11. ^ IGF: Political and Technical Problems with DNSSEC . Heise News, November 14, 2007
  12. ↑ Department of Homeland Security wants the master key for the DNS . Heise News, March 29, 2007
  13. ↑ VeriSign wants to share DNSSEC keys (a bit) . Heise News, October 3, 2008
  14. ↑ Monika Ermert: Last Formal Tie To Historic US Internet Control Is Cut. In: Intellectual Property Watch. October 1, 2016, accessed November 28, 2016 .