diff --git a/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml b/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml index 584dbdbb82..5335ff8b49 100644 --- a/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml @@ -3871,6 +3871,333 @@ mail IN A 192.168.1.5 own, and remembers the answers for later use. + + <acronym + role="Doman Name Security Extensions">DNSSEC</acronym> + + BIND + DNS security extensions + + + Domain Name System Security Extensions, or DNSSEC for short, is a + suite of specifications to protect resolving name servers from forged + DNS data, such as spoofed DNS + records. By using digital signatures, a resolver can verify the + integrity of the record. Note that DNSSEC only provides + integrity via digitally signing the Resource Records (RRs). It provides neither + confidentiality nor protection against false end-user assumptions. + This means that it cannot protect against people going to example.net instead of example.com. The only thing + DNSSEC does is authenticate that the data has not + been compromised in transit. The security of DNS is + an important step in securing the Internet in general. For more + in-depth details of how DNSSEC works, the relevant + RFCs are a good place to start. See the list in + . + + The following sections will demonstrate how to enable + DNSSEC for an authoritative DNS + server and a recursive (or caching) DNS server + running BIND 9. While all versions of + BIND 9 support DNSSEC, it is + necessary to have at least version 9.6.2 in order to be able to use the + signed root zone when validating DNS queries. This + is because earlier versions lack the required algorithms to enable + validation using the root zone key. It is strongly recommended to use + the latest version of BIND 9.7 or later to take + advantage of automatic key updating for the root key, as well as other + features to automatically keep zones signed and signatures up to date. + Where configurations differ between 9.6.2 and 9.7 and later, + differences will be pointed out. + + + Recursive <acronym>DNS</acronym> server configuration + + Enabling DNSSEC validation of queries + performed by a recursive DNS server requires a few + changes to named.conf. Before making these + changes the root zone key, or trust anchor, must be acquired. + Currently the root zone key is not available in a file format + BIND understands, so it has to be manually + converted into the proper format. The key itself can be obtained by + querying the root zone for it using dig. + By running + + &prompt.user; dig +multi +noall +answer DNSKEY . > root.dnskey + + the key will end up in root.dnskey. The + contents should look something like this: + + . 93910 IN DNSKEY 257 3 8 ( + AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ + bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh + /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA + JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp + oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 + LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO + Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc + LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= + ) ; key id = 19036 +. 93910 IN DNSKEY 256 3 8 ( + AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf + UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE + g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V + EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt + ) ; key id = 34525 + + Do not be alarmed if the obtained keys differ from this example. + They might have changed since these instructions were last updated. + This output actually contains two keys. The first key in the + listing, with the value 257 after the DNSKEY record type, is the one + needed. This value indicates that this is a Secure Entry Point + (SEP), + commonly known as a Key Signing Key (KSK). The second key, with value + 256, is a subordinate key, commonly called a Zone Signing Key + (ZSK). More on the + different key types later in the . + + Now the key must be verified and formatted so that + BIND can use it. To verify the key, generate a + DS + RR set. Create a file + containing these RRs + with + + &prompt.user; dnssec-dsfromkey -f root-dnskey . > root.ds + + These records use SHA-1 and SHA-256 respectively, and should + look similar to the following example, where the longer is using + SHA-256. + + . IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E +. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 + + The SHA-256 RR can now be compared to the + digest in https://data.iana.org/root-anchors/root-anchors.xml. To be absolutely sure + that the key has not been tampered with the data in the + XML file can be verified using the + PGP signature in https://data.iana.org/root-anchors/root-anchors.asc. + + Next, the key must be formatted properly. This differs a + little between BIND versions 9.6.2 and 9.7 and + later. In version 9.7 support was added to automatically track + changes to the key and update it as necessary. This is done using + managed-keys as seen in the example below. When + using the older version, the key is added using a + trusted-keys statement and updates must be done + manually. For BIND 9.6.2 the format should look + like: + + trusted-keys { + "." 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + + For 9.7 the format will instead be: + + managed-keys { + "." initial-key 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + + The root key can now be added to named.conf + either directly or by including a file containing the key. After + these steps, configure BIND to do + DNSSEC validation on queries by editing + named.conf and adding the following to the + options directive: + + dnssec-enable yes; +dnssec-validation yes; + + To verify that it is actually working use + dig to make a query for a signed zone + using the resolver just configured. A successful reply will contain + the AD flag to indicate the data was + authenticated. Running a query such as + + &prompt.user; dig @resolver +dnssec se ds + + should return the DS RR for + the .se zone. In the flags: + section the AD flag should be set, as seen + in: + + ... +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 +... + + The resolver is now capable of authenticating + DNS queries. + + + + Authoritative <acronym>DNS</acronym> server configuration + + In order to get an authoritative name server to serve a + DNSSEC signed zone a little more work is + required. A zone is signed using cryptographic keys which must be + generated. It is possible to use only one key for this. The + preferred method however is to have a strong well-protected Key + Signing Key (KSK) that is + not rotated very often and a Zone Signing Key (ZSK) that is rotated more + frequently. Information on recommended operational practices can be + found in RFC 4641: DNSSEC Operational Practices. Practices + regarding the root zone can be found in DNSSEC Practice Statement for the Root Zone + KSK operator and DNSSEC Practice Statement for the Root Zone + ZSK operator. The KSK is used to build a chain + of authority to the data in need of validation and as such is also + called a Secure Entry Point (SEP) key. A message digest of + this key, called a Delegation Signer (DS) record, must be published in + the parent zone to establish the trust chain. How this is + accomplished depends on the parent zone owner. The ZSK is used to sign the zone, and + only needs to be published there. + + To enable DNSSEC for the example.com zone depicted in previous + examples, the first step is to use + dnssec-keygen to generate the + KSK and ZSK key pair. This + key pair can utilize different cryptographic algorithms. It is + recommended to use RSA/SHA256 for the keys and 2048 bits key length + should be enough. To generate the KSK for example.com, run + + &prompt.user; dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com + + and to generate the ZSK, run + + &prompt.user; dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com + + dnssec-keygen outputs two files, the + public and the private keys in files named similar to + Kexample.com.+005+nnnnn.key (public) and + Kexample.com.+005+nnnnn.private (private). The + nnnnn part of the file name is a five digit key + ID. Keep track of which key ID belongs to which key. This is + especially important when having more than one key in a zone. It is + also possible to rename the keys. For each KSK + file do: + + &prompt.user; mv Kexample.com+005+nnnnn.key Kexample.com+005+nnnnn.KSK.key +&prompt.user; mv Kexample.com+005+nnnnn.private Kexample.com+005+nnnnn.KSK.private + + For the ZSK files, substitute + KSK for ZSK as necessary. The + files can now be included in the zone file, using the + $include statement. It should look something like + this: + + $include Kexample.com.+005+nnnnn.KSK.key ; KSK +$include Kexample.com.+005+nnnnn.ZSK.key ; ZSK + + Finally, sign the zone and tell BIND to use + the signed zone file. To sign a zone + dnssec-signzone is used. The command to + sign the zone example.com, located + in example.com.db would look similar to + + &prompt.user; dnssec-signzone -o example.com -k Kexample.com+005+nnnnn.KSK example.com.db Kexample.com+005+nnnnn.ZSK.key + + The key supplied to the argument is the + KSK and the other key file is the + ZSK that should be used in the signing. It is + possible to supply more than one KSK and + ZSK, which will result in the zone being signed + with all supplied keys. This can be needed to supply zone data + signed using more than one algorithm. The output of + dnssec-signzone is a zone file with all + RRs signed. This output will end up in a file + with the extension .signed, such as + example.com.db.signed. The DS records will also be + written to a separate file dsset-example.com. + To use this signed zone just modify the zone directive in + named.conf to use + example.com.db.signed. By default, the + signatures are only valid 30 days, meaning that the zone needs to be + resigned in about 15 days to be sure that resolvers are not caching + records with stale signatures. It is possible to make a script and a + cron job to do this. See relevant manuals for details. + + Be sure to keep private keys confidential, as with all + cryptographic keys. When changing a key it is best to include the + new key into the zone, while still signing with the old one, and then + move over to using the new key to sign. After these steps are done + the old key can be removed from the zone. Failure to do this might + render the DNS data unavailable for a time, until + the new key has propagated through the DNS + hierarchy. For more information on key rollovers and other + DNSSEC operational issues, see RFC 4641: DNSSEC Operational practices. + + + + Automation using <acronym>BIND</acronym> 9.7 or later + + Beginning with BIND version 9.7 a new + feature called Smart Signing was introduced. + This feature aims to make the key management and signing process + simpler by automating parts of the task. By putting the keys into a + directory called a key repository, and using the + new option auto-dnssec, it is possible to create a + dynamic zone which will be resigned as needed. To update this zone + use nsupdate with the new option + . rndc has also grown + the ability to sign zones with keys in the key repository, using the + option . To tell BIND to use + this automatic signing and zone updating for example.com, add the following to + named.conf: + + zone example.com { + type master; + key-directory "/etc/named/keys"; + update-policy local; + auto-dnssec maintain; + file "/etc/named/dynamic/example.com.zone"; +}; + + After making these changes, generate keys for the zone as + explained in , put those keys in the + key repository given as the argument to the + key-directory in the zone configuration and the + zone will be signed automatically. Updates to a zone configured this + way must be done using nsupdate, which + will take care of re-signing the zone with the new data added. For + further details, see and the + BIND documentation. + + + Security @@ -3897,41 +4224,76 @@ mail IN A 192.168.1.5 - + Further Reading BIND/named manual pages: - &man.rndc.8; &man.named.8; &man.named.conf.5; + &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.8; + &man.dnssec-signzone.8; &man.dnssec-keygen.8; - - Official ISC BIND - Page - + + Official ISC + BIND Page + - - Official ISC BIND - Forum - + + Official ISC + BIND Forum + - - O'Reilly - DNS and BIND 5th Edition - + + O'Reilly + DNS and BIND 5th Edition + - - RFC1034 - - Domain Names - Concepts and Facilities - + + Root + DNSSEC + - - RFC1035 - - Domain Names - Implementation and Specification - + + DNSSEC Trust Anchor Publication for the Root + Zone + + + + RFC1034 + - Domain Names - Concepts and Facilities + + + + RFC1035 + - Domain Names - Implementation and Specification + + + + RFC4033 + - DNS Security Introduction and Requirements + + + + RFC4034 + - Resource Records for the DNS Security Extensions + + + + RFC4035 + - Protocol Modifications for the DNS Security + Extensions + + + + RFC4641 + - DNSSEC Operational Practices + + + + RFC 5011 + - Automated Updates of DNS Security (DNSSEC + Trust Anchors + diff --git a/share/sgml/man-refs.ent b/share/sgml/man-refs.ent index 3a9edaf785..5b5c353880 100644 --- a/share/sgml/man-refs.ent +++ b/share/sgml/man-refs.ent @@ -4257,6 +4257,8 @@ + +