Exit Zen
17
../../protocols/dnssec.rst:173
English
the `NSEC` record is used when non-existent domain names are queried. Its usage will be explained later
0/1030 · 103
18
../../protocols/dnssec.rst:176
English
The simplest way to understand the operation of DNSSEC is to rely on a simple example. Let us consider the `example.org` domain and assume that Alice wants to retrieve the `AAAA` record for `www.example.org` using DNSSEC.
0/2210 · 221
19
../../protocols/dnssec.rst:182
English
The security of DNSSEC relies on `anchored keys`. An `anchored key` is a public key that is considered as trusted by a resolver. In our example, we assume that Alice's resolver has obtained the public key of the servers that manage the root zone in a secure way. This key has been distributed outside of the DNS, e.g. it has been published in a newspaper or has been received in a sealed letter.
0/3950 · 395
20
../../protocols/dnssec.rst:189
English
To obtain an authenticated record for `www.example.org`, Alice's resolver first needs to retrieve the `NS` which is responsible for the `.org` Top-Level Domain (TLD). This record is served by the DNS root server and Alice's resolver can retrieve the signature (`RRSIG` record) for this `NS` record. Since Alice knows the `DNSKEY` of the root, she can verify the validity of this signature.
0/3890 · 389
21
../../protocols/dnssec.rst:196
English
The next step is to contact `ns.org`, the `NS` responsible for the `.org` TLD to retrieve the `NS` record for the `example.org` domain. This record is accompanied by a `RRSIG` record that authenticates it. This `RRSIG` record is signed with the key of the `.org` domain. Alice's resolver can retrieve this public key as the `DNSKEY` record for the `.org`, but how can it trust this key since it is distributed by using the DNS and could have been modified by attackers ? DNSSEC solves this problem by using the `DS` record that is stored in the parent zone (in this case, the root zone). This record contains a hash of a public key that is signed with a `RRSIG` signature. Since Alice's resolver's trusts the root key, it can validate the signature of the `DS` record for the `.org` domain. It can then retrieve the `DNSKEY` record for this domain from the DNS and compare the hash of this key with the `DS` record. If they match, the public key of the `.org` domain can be trusted. The same technique is used to obtain and validate the key of the `example.org` domain. Once this key is trusted, Alice's resolver can request the `AAAA` record for `www.example.org` and validate its signature.
0/11920 · 1192
22
../../protocols/dnssec.rst:215
English
Thanks to the `DS` record, a resolver can validate the public keys of client zones as long as their is a chain of `DS` -> `DNSKEY` records from an anchored key. If the resolver trusts the public key of the root zone, it can validate all DNS replies for which this chain exists.
0/2770 · 277
23
../../protocols/dnssec.rst:220
English
There are several details of the operation of DNSSEC that are worth being discussed. First, a server that supports DNSSEC must have a public-private key pair. The public key is distributed with the `DNSKEY` record. The private key is never distributed and it does not even need to be stored on the server that uses the public key. DNSSEC does not require the DNSSEC servers to perform any operation that requires a private key in real time. All the `RRSIG` records can be computed offline, possibly on a different server than the server that returns the DNSSEC replies. The initial motivation for this design choice was the CPU complexity of computing the `RRSIG` signatures for zones that contain millions of records. In the early days of DNSSEC, this was an operational constraint. Today, this is less an issue, but avoiding costly signature operations in real time has two important benefits. First, this reduces the risk of denial of service attacks since an attacker cannot force a DNSSEC server to perform computationally intensive signing operations. Second, the private key can be stored offline, which means that even if an attacker gains access to the DNSSEC server, it cannot retrieve its private key. Using offline signatures for the `RRSIG` records has some practical implications that are reflected in the content of this record. First, each `RRSIG` record contains the original TTL of the signed record. When DNS resolvers cache records, they change the value of the TTL of these cached records and then return the modified records to their clients. When a resolver receives a signed DNS record, it must replace the received TTL of the record with the original TTL (and check that the received TTL is smaller than the original one) before checking the signature. Second, the `RRSIG` records contain a validity period, i.e. a starting time and an ending time for the validity of the signature. This period is specified as two timestamps. This period is only the validity of the signature. It does not affect the TTL of the signed record and is independent from the TTL. In practice, the validity period is important to allow DNS server operators to update their public/private keys. When such a key is changed, e.g. because the private could have been compromised, there is some period of time during which records signed with the two keys coexist in the network. The validity period allows ensuring that old signatures do not remain in DNS caches for ever.
0/24710 · 2471
24
../../protocols/dnssec.rst:263
English
The last record introduced by DNSSEC is the `NSEC` record. It is used to authenticate a negative response returned by a DNS server. If a resolver requests a domain name that is not defined in the zone, the server replies with an error message. The designers of the original version of the DNS thought that these errors would not be very frequent and resolvers were not required to cache those negative responses. However, operational experience showed that queries for invalid domain names are more frequent than initially expected and a large fraction of the load on some servers is caused by repeated queries for invalid names. Typical examples include queries for invalid TLDs to the root DNS servers or queries caused by configuration errors [WF2003]_. Current DNS deployments allow resolvers to cache those negative answers to reduce the load on the entire DNS :rfc:`2308`.
0/8780 · 878
25
../../protocols/dnssec.rst:277
English
The simplest way to allow a DNSSEC server to return signed negative responses would be for the server to return a signed response that contains the received query and some information indicating the error. The client could then easily check the validity of the negative response. Unfortunately, this would force the DNSSEC server to generate signatures in real time. This implies that the private key must be stored in the server memory, which leads to risks if an attacker can take control of the server. Furthermore, those signatures are computationally complex and a simple denial of service attack would be to send invalid queries to a DNSSEC server.
0/6540 · 654
26
../../protocols/dnssec.rst:288
English
Given the above security risks, DNSSEC opted for a different approach that allows the negative replies to be authenticated by using offline signatures. The `NSEC` record exploits the lexicographical ordering of all the domain names. To understand its usage, consider a simple domain that contains three names (the associated `AAAA` and other records that are not shown) :
0/3710 · 371
27
../../protocols/dnssec.rst:302
English
In this domain, the DNSSEC server adds three `NSEC` records. A `RRSIG` signature is also computed for each of these records.
0/1240 · 124
28
../../protocols/dnssec.rst:317
English
If a resolver queries `delta.example.org`, the server will parse its zone. If this name were present, it would have been placed, in lexicographical order, between the `beta.example.org` and the `gamma.example.org` names. To confirm that the `delta.example.org` name does not exist, the server returns the `NSEC` record for `beta.example.org` that indicates that the next valid name after `beta.example.org` is `gamma.example.org`. If the server receives a query for `pi.example.org`, this is the `NSEC` record for `gamma.example.org` that will be returned. Since this record contains a name that is before `pi.example.org` in lexicographical order, this indicates that `pi.example.org` does not exist.
0/7010 · 701
29
../../protocols/dnssec.rst:331
English
Footnotes
0/100 · 9
30
../../protocols/dnssec.rst:332
English
See http://spoofer.caida.org/summary.php for an ongoing measurement study that analyses the networks where an attacker could send packets with any source IP address.
0/1650 · 165
The translation has come to an end.