DNSSec: What is and why

Foreword

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

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 plain text. In this case, the resolver judged the accuracy of the information received only by the request identifier, which is only 2 bytes long. That is, to poison the cache, you just had to iterate through 65,536 values. We started talking about it 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 DNSSec edition 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. The manufacturers of DNS software responded that in addition to the request identifier they began to randomly select the outgoing port. Along the way, began hysteria about the introduction of DNSSec.

How it works

The principle of operation of DNSSec is the same as that of a digital signature. That is, we sign with the private key, we check with the open.

The special feature is that DNSSec uses two types of keys - one signs a zone (ZSK, zone signing key), the other signs a set of keys (KSK, key signing key). This is done from such considerations: the zone can be large enough to manage to pick up the private key, so it needs to be changed more often, and you can make it shorter so that the zones sign up faster; KSK is used for small amounts of data, so it can be made and changed more rarely. Moreover, the hash from the open part of the 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, suppose you have a zone example.com and in it such a piece:

 $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 
    

      
      
      
    

   

$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



And you decided to sign this zone. The following will be done:

1. A sequence of signed records will be created;
2. NSEC records will be added (more on this below);
3. The SOA records, NS set for example.com, address and MX entries for doo, each NSEC RR and each DS set will be subscribed.
4. Depending on the software settings, the DNSKEY set can also be signed.

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

KSK

This key is used to sign a set of DNSKEY records.

In addition, a hash is taken from the open part of the KSK, which is subsequently sent to the parent zone. In the example above, this is a DS record (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 when changing a key, not to manually update it every time, there are mechanisms for automatically updating it, for example, BIND has the option managed keys.

Obviously, the closed part of the KSK should be kept as the pupil of the eye - firstly, the whole meaning of DNSSec disappears, and secondly, in the event of a compromise, changing the KSK quickly will not work.

Next SECure

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



To prevent this from occurring, when a zone is signed, domain names are sorted alphabetically, an NSEC record is added to each of them, which indicates which of the following domain names is protected and which records for it are present in the zone. The latest NSEC record points to SOA.

If an authoritative server returns the response NXDOMAIN (RCODE = 3) or NODATA (RCODE = 0), then the NSEC entry 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 the 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 // Asi9 / 2ymadcNkB5VXg fJD1DMBpnCK1aUqG8ieJFsMQuMrrYRkhy0TdrCxGtZmTCpOOxfOMtmKR rcQ = 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 record indicates that the specified name does not fall under the mask.

 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 6CgQTda6maCvoF8d1gOc2nIbd7zKjdOl2ujMVJKCb6Bv3yoy4WjL3gka Ufk = 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 

And already this NSEC record says that the domain name is not detected.



The disadvantage of the NSEC is obvious - anyone can get the contents of the zone simply by querying this record for each name. In this regard, the mechanism was refined and NSEC3 records appeared in which domain names are hashed.

NSEC3 can use salt to calculate the hash; in addition to salt, you can set 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 degree. This is due to the fact that in order to return NXDOMAIN, an authoritative server must calculate a hash, and not one. The process is described in RFC 5155 .



In addition, the NSEC3 entry has a flag field that the NSEC does not have. At the moment, only one flag is defined - OPT-OUT, thanks to which it is possible to sign not the whole zone (which, for large sizes, can be a very lengthy process), but only those domain names for which there are DS records.

On the one hand, OPT-OUT makes it possible to significantly reduce the signature time, but when using it, the attacker’s access to the zone file allows the attacker to add an unprotected entry, which can later cause problems.

Work mechanism

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

1. We request a domain name from a resolver;
2. The resolver sets the DO bit and requests test.bar.example.com from the root server;
3. The resolver knows that the root domain zone is signed - it has a key or a hash key for it (the so-called trust-anchor), so it queries the root DNSKEY server for the root zone and compares it with the existing one;
4. The root server does not know such a domain name, and indeed the maximum that he knows on which servers the com zone is located, he reports the addresses of these servers to our resolver along with the DS record for the com zone;
5. Resolver validates the DS record with the root zone key received and verified by the ZSK;
6. Now the resolver knows that the com zone is signed, so he asks her DNSKEY DNS server and validates them, after which she is interested in bar.example.com. Naturally, the server of the com zone doesn’t know about such; he only knows that the example.com zone lives on ns.example.com and ns1.example.com, and that’s what he answers to the resolver along with — yes — yes — the DS record;
7. So the resolver has built a chain of trust to example.com, where he finds out the name servers of the zone bar.example.com and its DS;
8. In the end, the resolver iteratively finds the addresses of the DNS servers responsible for bar.example.com, goes to them and finally gets what we want, validates all the information and gives us the address record by setting the AD bit in the response.

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

Rendered effects

1. The outgoing traffic of a reputable DNS server increases approximately 4 times;
2. The size of the zone file after the signature (without OPT-OUT) grows 6-7 times;
3. Increasing the key length leads to a noticeable decrease in resolver qps, a less influential server influences it;
4. On the contrary, there is an increase in the number of iterations when using NSEC3;
5. DNSSec leads to a significant increase in the DNS response and, therefore, it is necessary that all network equipment work correctly with DNS packets of more than 512 bytes.

Why do you need it

It's a difficult question. First, the effects created must be taken into account; secondly, it is required to organize reliable storage for keys; thirdly, follow the rotation of keys; fourth, follow the shelf life of signatures; Fifth, DNSSec enhances the amplified ddos ​​effect.

All of this is a price to be sure of the information received from reputable DNS servers. Now, however, the community comes up with what else can be included in DNSSec, so that it can be monetized, and some even ask very bold and interesting questions, such as Phil Regnauld, a member of the AFNIC scientific council who asked “Will DNSSEC bring down the certificate industry?” at the workshop of this council.

What to read on this topic

• From here, start the excavation ;
• Highly detailed implementation guide ;
• Here it is told about zones RU, SU, XN - P1AI ;
• And, of course, rfc 4033-4035.