karkarramba June 6, 2011 at 14:24

DNSSec: What is and Why

From the sandbox

Foreword

As it turned out, not many people know what DNSSec is, what it is for, what it is for, and whether it is worth implementing it at home. Since there is little information on this subject in Russian, I will try to shed light on these issues.

What is DNSSec

A bit of history

Initially, the domain name system did not have any mechanisms to protect against information spoofing in the response - the system architecture is such that both the request and the response are transmitted in clear text. At the same time, the resolver judged the fidelity of the information received only by the request identifier, the length of which is only 2 bytes. That is, to poison the cache, you just had to sort out 65,536 values. They started talking about this back in the 90s. At the same time, they began to slowly describe the first edition of DNSSec. She saw the light in 1997, two years later the next one appeared. In 2005, the current edition of DNSSec appeared, with which everyone works. A landmark event happened in 2008, when Dan Kaminsky showed the world that you can poison a cache in 10 seconds. Manufacturers of DNS software responded by saying that in addition to the request identifier, they began to randomly select the outgoing port.

How it works

DNSSec works the same way as a digital signature. That is, we sign it with a private key, we verify it with an open one.
The peculiarity is that DNSSec uses two types of keys - one is signing a zone (ZSK, zone signing key), the other is signing a set of keys (KSK, key signing key). This is done for such reasons: the zone can be large enough to be able to pick up the private key, so you need to change it more often, and you can make it shorter so that the zones are signed faster; KSK is used for small amounts of data, so it can be made more authentic and changed less frequently. Moreover, the hash from the open part of KSK is required to be sent to the parent zone, which I would like to do not too often.

Zsk

With this key, all record sets in the zone (RRSET) are signed, except for delegation points. That is, let's say you have an example.com zone and there is such a piece in it: And you decided to sign this zone. The following will be done:

$ORGIGIN example.com.
@       SOA dns.example.com ns.example.com {
                 Serial
                 Refresh
                 Retry
                 Expire
                 nTTL
                 }
        NS ns.example.com.
        NS ns1.example.com.
        DNSKEY  256 3 5 (
                                      AwEAAfETe4xtZy3Ml+9NceWE0zTUWk5WgTs5
                                      ogRJ1fVuJ5U2QmBb+t3ltA4BrZObLRjX2
                                      HcMmneVC4C3IdgluAiV6Jpj7hgRZIbbG8les
                                      LaiL0/wOoH/byPvNi5T0OQpG3vgXyhoBdWxl
                                      zghFU3eQSAnWF0xP/c323rtP0irdY7v5
                                      ) ; key id = 38754
         DNSKEY  257 3 5 (
                                      AwEAAdanjntZ82rOdV97sDS5+QH+w1pKnRJ/
                                      b8gmuRBC91q5fQ2YiQ5zzYKi9+gENlqx/1MN
                                      jAFXJ1Fvtf0pJYKjmkiBJoHdZoEVRnJz8ODx
                                      FYgFX/fx+SBKsG3ZioaHP3CEdZQ4k3kutN6o
                                      tawolvHfErSwnJT/3IhAplXDHZrLmwXgWU3M
                                      PvMhnJRR9jd7S4f3WF10oq+3qPkBbJrqxB3x
                                      RydCSaZYfVuJ5U2QmBb+t3ltA4BB8jL8jOLS
                                      zvP2lufa6P8f0TJxtcpx/t9IfvUyWHmr9H7r
                                      inl4k8xDTVvaPnmBScxbuBc=
                                      ) ; key id = 23179
doo     IN A 127.0.0.1
        IN A 127.0.0.2
        IN MX mail
foo      NS ns1.test.ru.
        NS ns2.test.ru.
bar     NS ns1.test.ru.
        NS ns2.test.ru.
        DS 4915 5 1 180DC61CD4A2772DC02EC18934AA4C024D77DC11
        DS 4915 5 2 03EE2B29404BDF6D8891C0E0C89F714FE865E1D59A621F6FB4642648 4BC8C852

A sequence of signed records will be created;
NSEC entries will be added (more on that below);
SOA records, NS set for example.com, address and MX records for doo, each NSEC RR and each DS set will be subscribed.
Depending on the software settings, a DNSKEY set may also be signed.

Delegation points, i.e. NS records for child zones will not be signed.

KSK

This key signs the set of DNSKEY records.
In addition, a hash is taken from the open part of KSK, which is then sent to the parent zone. In the above example, these are DS records (Delegation Signer).
In the case of the root zone, it is assumed that the open part of the key will be communicated to the resolver manually. And in order to not manually update it every time you change the key, there are mechanisms for automatically updating it, for example, BIND has the managed-keys option.
Obviously, the closed part of KSK should be stored as the apple of the eye - firstly, the whole point of DNSSec disappears, and secondly, in case of compromise, it will not be possible to quickly change KSK.

Next secure

Well, here we signed the zone, but still someone outsider can add their information to it and, even unsigned, it will be given by the server along with the signed one.

To prevent this from happening, when signing a zone, domain names are sorted alphabetically, an NSEC record is added to each of them, which indicates which next domain name is protected and what records for it are present in the zone. The last NSEC entry points to SOA.
If the authoritative server returns the response NXDOMAIN (RCODE = 3) or NODATA (RCODE = 0), then the NSEC record must be present in the response. An example of such a response:

; <<>> DiG 9.7.3 <<>> jhbczxccva.se +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8766
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;jhbczxccva.se.                 IN      A
;; AUTHORITY SECTION:
se.                     300     IN      SOA     catcher-in-the-rye.nic.se. registry-default.nic.se. 2011053104 1800 1800 864000 7200
se.                     300     IN      RRSIG   SOA 5 1 172800 20110613123930 20110531090447 24825 se. JJGWAvmcB/Bq7t5z7iTQGLr9c0LzQkdwpNFsrIClJctZUn/Z3YN2EMVQ 0r6DvufTGk1L8JMvTaxkI43ZmvasFeNNzfUFjr+td8Mv9h7FF5kTfEO5 R7JMh4j0Kxl/Gy4j+Ofcm0ZiCZTtcnNdHwCIHaVpz9KA6uIubnlJNSLw YXI=

Since the NXDOMAIN response is always accompanied by an SOA record, the SOA and signature for it are returned in the signed zone.

se. 300 IN RRSIG NSEC 5 1 7200 20110613011140 20110530130445 24825 se. dKL3iGCxNI51FSNjx4p0NmAMtjhJVqLeAShrRH0rRmdV0Ej1nAH/Z/ip zn7PqB+7j6PguNPfEU4ySHfS8BTprvmod60J//Asi9/2ymadcNkB5VXg fJD1DMBpnCK1aUqG8ieJFsMQuMrrYRkhy0TdrCxGtZmTCpOOxfOMtmKR rcQ= se. 300 IN NSEC 0-0.se. NS SOA TXT RRSIG NSEC DNSKEY
This NSEC entry indicates that the specified name does not fall under the mask. And already this NSEC record says that the domain name was not found. The disadvantage of NSEC is obvious - anyone can get the contents of a zone simply by polling this entry for each name. In this regard, the mechanism was finalized and NSEC3 entries appeared in which domain names are hashed. NSEC3 can use salt to calculate the hash, in addition to salt, you can specify the number of iterations. It is worth noting that an increase in the number of iterations leads to an increase in the load on both the resolver and the authoritative server, and the latter to a greater extent. This is due to the fact that in order to return NXDOMAIN, the authoritative server must calculate the hash, and not one. The process is described in RFC 5155 .

jhbatar.se. 300 IN RRSIG NSEC 5 2 7200 20110613032526 20110530130445 24825 se. DWXq1ZlzuA9w0McNHWjpLO55H08rkWjtBDd8TewUCYnljM//1oXEvVcJ ORT9AxXoz9TMOEku2wFGydceX5zs4PZLwnEC+ieXu3ri/B0S533XpmKe 6CgQTda6maCvoF8d1gOc2nIbd7zKjdOl2ujMVJKCb6Bv3yoy4WjL3gka Ufk= jhbatar.se. 300 IN NSEC jhbeagleklubb.se. NS RRSIG NSEC

In addition, the NSEC3 entry has a flag field that NSEC does not have. At the moment, only one flag is defined - OPT-OUT, due to which it is possible to sign not the entire zone (which can be a very lengthy process for large sizes), but only those domain names for which there are DS records.
On the one hand, OPT-OUT can significantly reduce the signature time, however, when using it, having an attacker have access to a zone file allows him to add an unprotected entry, which can cause problems in the future.

Work mechanism

Suppose we want to know the address test.bar.example.com:

We request a domain name from the resolver;
The resolver sets the DO bit and requests test.bar.example.com from the root server;
The resolver knows that the root domain zone is signed - it has a key or key hash for it (the so-called trust-anchor), so it queries the root DNSKEY server for entries for the root zone and compares it with the existing one;
The root server does not know such a domain name, and indeed the maximum that it knows is on which servers the com zone is located, it reports the addresses of these servers to our resolver along with the DS record for the com zone;
The resolver validates the DS record with the received and verified ZSK root zone key;
Now the resolver knows that the com zone is signed, so it asks its DNS server DNSKEY and validates them, after which it is interested in bar.example.com. Naturally, the server of the zone com does not know about these, it only knows that the zone example.com lives on ns.example.com and ns1.example.com, and this is what it answers the resolver with, yes, yes, the DS record;
So the resolver built a chain of trust to example.com, where it recognizes the name servers of the bar.example.com zone and its DS;
In the end, the resolver iteratively learns the DNS addresses of the servers responsible for bar.example.com, goes to them and finally gets what it wants, validates all the information and gives us the address record, setting the AD bit in the response.

If it is impossible to validate something, the resolver will return servfail.

Effects

Outgoing traffic of a reputable DNS server increases by about 4 times;
The size of the zone file after signing (without OPT-OUT) grows 6-7 times;
An increase in the key length leads to a noticeable decrease in the qps of the resolver; it affects the authoritative server to a lesser extent;
On the contrary, there is an increase in the number of iterations when using NSEC3;
DNSSec leads to a significant increase in the DNS response and, therefore, it is necessary that all network equipment correctly work with DNS packets of more than 512 bytes.

Why is it necessary

This is a difficult question. Firstly, the created effects must be taken into account; secondly, it is required to organize a reliable storage for keys; thirdly, monitor key rotation; fourthly, to monitor the expiration date of signatures; fifth, DNSSec enhances the effect of amplified ddos.
All this is the price to be sure of the information received from authoritative DNS servers. Now, however, the community is thinking of what else can be included in DNSSec so that it can be monetized, and some even ask very bold and interesting questions, for example, Phil Regnauld, a member of the AFNIC scientific council who asked “Will DNSSEC bring down the certificate industry?” at the seminar of this council.

What to read on this topic

From here it is worth starting the excavation ;
A very detailed implementation guide ;
It tells about the zones RU, SU, XN - P1AI ;
And, of course, rfc 4033-4035.

Tags: