From zeising@daemonic.se Sun May 22 09:34:16 2011 Return-Path: Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C721B1065674 for ; Sun, 22 May 2011 09:34:16 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (unknown [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id C823D8FC0A for ; Sun, 22 May 2011 09:34:14 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 47E7540002 for ; Sun, 22 May 2011 11:34:13 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 3994940006; Sun, 22 May 2011 11:34:13 +0200 (CEST) Received: from mx.daemonic.se (h-90-99.A163.priv.bahnhof.se [79.136.90.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id C869940002 for ; Sun, 22 May 2011 11:34:10 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 53392119C04 for ; Sun, 22 May 2011 11:34:10 +0200 (CEST) Received: from vincent.daemonic.se (login.daemonic.se [IPv6:2001:470:dca9:0:1::10]) by mail.daemonic.se (Postfix) with ESMTPS id 2011012B2DA for ; Sun, 22 May 2011 11:34:10 +0200 (CEST) Received: (from zeising@localhost) by vincent.daemonic.se (8.14.4/8.14.4/Submit) id p4M9Y9JL041108; Sun, 22 May 2011 11:34:09 +0200 (CEST) (envelope-from zeising) Message-Id: <201105220934.p4M9Y9JL041108@vincent.daemonic.se> Date: Sun, 22 May 2011 11:34:09 +0200 (CEST) From: Niclas Zeising Reply-To: Niclas Zeising To: FreeBSD-gnats-submit@freebsd.org Cc: Subject: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook X-Send-Pr-Version: 3.113 X-GNATS-Notify: >Number: 157245 >Category: docs >Synopsis: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook >Confidential: no >Severity: non-critical >Priority: low >Responsible: bcr >State: closed >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Sun May 22 09:40:08 UTC 2011 >Closed-Date: Wed May 25 14:31:53 UTC 2011 >Last-Modified: Wed May 25 14:31:53 UTC 2011 >Originator: Niclas Zeising >Release: FreeBSD 8.2-RELEASE amd64 >Organization: >Environment: System: FreeBSD vincent.daemonic.se 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Wed Apr 20 17:22:47 CEST 2011 root@vincent.daemonic.se:/usr/obj/usr/src/sys/VINCENT amd64 >Description: DNSSEC is deemd to be very important in order to secure the Internet as a whole I have written a section about what DNSSEC is and how to configure BIND to use it, intended for the FreeBSD handbook. As a first step, I would like some review on my work, both from a technical and a linguistic point of view. >How-To-Repeat: >Fix: Attached patch contains my changes to the handbook to include information about DNSSEC. Please review it as a first step, so that I can work on getting it into the handbook. --- network-servers.chapter.sgml.diff begins here --- Index: chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v retrieving revision 1.130 diff -u -d -r1.130 chapter.sgml --- chapter.sgml 15 May 2011 20:41:30 -0000 1.130 +++ chapter.sgml 21 May 2011 19:13:24 -0000 @@ -3872,6 +3872,293 @@ + DNSSEC + + BIND + DNS security extensions + + + Domain Name System Security Extensions, or DNSSEC + for short, is a suite of specifications to protect the + DNS clients, i.e. Internet resolvers, from forged + DNS data, such as spoofed DNS + records. By using digital signatures, a resolver can verify the + integrity and authenticity of the record. It is worth noticing that + DNSSEC does only provide integrity, it does not + provide either confidentiality nor protection against false assumptions, + meaning that it cannot protect against people going to + example.com instead of + example.net and similar. The only + thing DNSSEC does is authenticate that the data is + from the domain owner and that it has not been compromised in transit. + The security of DNS is believed to be an important + step in securing the Internet in general. For a more in-depth + knowledge of how DNSSEC works, the relevant + RFCs is a good place to start. See the list at the + end of this chapter. + + The next two sections will demonstrate how to enable + DNSSEC for an authorative DNS + server and a recursive (or cashing) DNS server + running BIND9. While all versions of + BIND9 supports 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 + BIND 9.7 or later, to take advantage of the automatic + key updating function for the root key, as well as other functions 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 + + To enable DNSSEC validation of queries done by + a recursive DNS server, a few changes to + named.conf are needed. However, before changing + named.conf the root zone key, or trust anchor, + must be aquired. Currently the root zone key is not available in a + file format BIND understands, so this has to be + manually generated. 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 keys differ, they might + have changed since this was last updated. This output actually + contains two keys. The first key in the listing, with the value 257 + behind the DNSKEY record type, is the one needed. The value + indicates that this is a Secure Entry Point, more 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 section . + + Now that the key is obtained, it has to be verified to be + correct, and then made into a format BIND can + use. The next step is to generate a + DS + RR set. This is done by + running &propmt.user; dnssec-dsfromkey -f + root-dnskey . > root.ds, which will emit two + RRs into root.ds. These + records are using SHA-1 and SHA-256 respectively, and should look + similar to this, 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. + + The last step is to format the key to a format + BIND understand. This differs a little between + version 9.6.2 and 9.7 and later. Both uses a + managed-keys clause, but support for + initial-key was added in 9.7. + initial-key tells BIND + automatic tracking of the key. With BIND 9.6.2 + it is necessary to update the key manually when it is changed. The + format should look like, for BIND 9.6.2: + +managed-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 managed-keys directive can + now be added to named.conf either directly or + by including a file containing the key. After all this is done it + is just to tell BIND to do + DNSSEC validation on queries. This is achieved by + editing named.conf and add 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 set up. 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 +... + . This means that the resolver is now capable of + authenticate made DNSqueries. + + + + Authorative <acronym>DNS</acronym> server configuration + In order to get an authorative nameserver to serve a + DNSSEC signed zone, a little more work is + required. To sign a zone, two cryptographic keys for that zone must + be generated. These two keys are usually called the Key Signing Key + (KSK) and Zone Signing Key + (ZSK) respectively. The + KSK is used to build a chain + of authority to the data in need of validation and as such also called + a Secure Entry Point (SEP) key. This key needs to be published in the + parent zone as well, 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 keypair. This keypair + can utilize different cryptograhic algorithms. Currently the mandatory + algorithm is RSA/SHA-1. In the examples the key + length used is 2048 bits for the KSK and 1024 bits + for the ZSK. To generate the + KSK for example.com, run &promt.user; + dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE + example.com and to generate the + ZSK, run &promt.user; + dnssec-keygen -a RSASHA1 -b 1024 -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. The public key + files can now be included in the zone file, using the + $include statement. It should look something like + this: +$include Kexample.net.+005+nnnnn.key ; ZSK +$include Kexample.net.+005+nnnnn.key ; KSK + + + The only steps left is to sign the zone and tell + BIND to use the signed zonefile. 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 + &promt.user; dnssec-signzone -o example.com -k + Kexample.com+005+nnnnn example.com.db + Kexample.com+005+nnnnn.key. The key supplied to + the -k 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. To use this signed zone + just modify the zone directive in named.conf to + use this file. By default, the signatures are only valid 30 days, + meaning that the zone needs to be resigned within this time. It is + possible to make a script and a cron job to do this. See relevant + manuals for details. + Some cautionary words at the end. 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 key, 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. + Failiure to do this might render the DNS data + unavailable for a time, untill 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, + from now on 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 the tool + nsupdate with the new option + -l is used. rndc has + also grown the ability to sign zones with keys in the key repository, + using the option sign. To make this work, put + something similar to what is shown below into + named.conf. +zone example.com { + type master; + key-directory "keys"; + update-policy local; + auto-dnssec maintain; + file "dynamic/example.com.zone"; +}; + This will tell named to use automatic signing and + updating of the zone example.com. + After this is done just generate keys for the zone as explained in + , put these in the key repository + denoted by key-directory in the zone configuration + and sign the zone using rndc. Updates to + the zone is done using nsupdate which will + take care of resigning the zone with the new data added. For further + details, see and the + BIND documentation. + + + + + Security Although BIND is the most common implementation of DNS, @@ -3897,7 +4184,7 @@ - + Further Reading BIND/named manual pages: @@ -3932,6 +4219,38 @@ url="http://tools.ietf.org/html/rfc1035">RFC1035 - Domain Names - Implementation and Specification + + + RFC4033 + - DNS Security Introduction and Requirements + + + + RFC4034 + - Recource 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 + + --- network-servers.chapter.sgml.diff ends here --- >Release-Note: >Audit-Trail: From: Benjamin Kaduk To: Niclas Zeising Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-doc@freebsd.org Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Sun, 22 May 2011 14:26:50 -0400 (EDT) On Sun, 22 May 2011, Niclas Zeising wrote: > > >> Description: > DNSSEC is deemd to be very important in order to secure the Internet as a whole I have written a section about what DNSSEC is and how to configure BIND to use it, intended for the FreeBSD handbook. > As a first step, I would like some review on my work, both from a technical and a linguistic point of view. I can't do a technical review, but found a few language nits. > > --- network-servers.chapter.sgml.diff begins here --- > Index: chapter.sgml > =================================================================== > RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v > retrieving revision 1.130 > diff -u -d -r1.130 chapter.sgml > --- chapter.sgml 15 May 2011 20:41:30 -0000 1.130 > +++ chapter.sgml 21 May 2011 19:13:24 -0000 > @@ -3872,6 +3872,293 @@ > > > > + DNSSEC > + > + BIND > + DNS security extensions > + > + > + Domain Name System Security Extensions, or DNSSEC > + for short, is a suite of specifications to protect the s/ the$// > + DNS clients, i.e. Internet resolvers, from forged > + DNS data, such as spoofed DNS > + records. By using digital signatures, a resolver can verify the > + integrity and authenticity of the record. It is worth noticing that > + DNSSEC does only provide integrity, it does not This phrasing is a rather uncommon usage; "DNSSEC only provides integrity" is what would more commonly be seen. > + provide either confidentiality nor protection against false assumptions, I believe that "nor" should be "or" here, but I don't have a good reference with me at the moment to check. > + meaning that it cannot protect against people going to > + example.com instead of > + example.net and similar. The only > + thing DNSSEC does is authenticate that the data is > + from the domain owner and that it has not been compromised in transit. > + The security of DNS is believed to be an important > + step in securing the Internet in general. For a more in-depth > + knowledge of how DNSSEC works, the relevant > + RFCs is a good place to start. See the list at the s/is/are/ > + end of this chapter. > + > + The next two sections will demonstrate how to enable > + DNSSEC for an authorative DNS "authoritative" > + server and a recursive (or cashing) DNS server "caching" > + running BIND9. While all versions of > + BIND9 supports DNSSEC, it is s/supports/support/ > + 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 > + BIND 9.7 or later, to take advantage of the automatic > + key updating function for the root key, as well as other functions 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 > + > + To enable DNSSEC validation of queries done by > + a recursive DNS server, a few changes to > + named.conf are needed. However, before changing > + named.conf the root zone key, or trust anchor, > + must be aquired. Currently the root zone key is not available in a > + file format BIND understands, so this has to be > + manually generated. The key itself can be obtained by querying the I guess the point is that IANA doesn't distribute the key in this form? This sentence ("Currently...generated.") could probably be reworked to make it more clear that we need to get the root zone key and then convert it to a format that BIND understands. > + 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 keys differ, they might "the keys" is ambiguous. What we care about is the keys the reader gets as compared to the ones listed here, since the root key currently in use might have changed since our document was last updated. > + have changed since this was last updated. This output actually > + contains two keys. The first key in the listing, with the value 257 > + behind the DNSKEY record type, is the one needed. The value > + indicates that this is a Secure Entry Point, more 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 section + linkend="dns-dnssec-auth">. > + > + Now that the key is obtained, it has to be verified to be > + correct, and then made into a format BIND can > + use. The next step is to generate a > + DS > + RR set. This is done by > + running &propmt.user; dnssec-dsfromkey -f > + root-dnskey . > root.ds, which will emit two > + RRs into root.ds. These > + records are using SHA-1 and SHA-256 respectively, and should look > + similar to this, 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 + url="https://data.iana.org/root-anchors/root-anchors.xml"> > + 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 + url="https://data.iana.org/root-anchors/root-anchors.asc"> > + https://data.iana.org/root-anchors/root-anchors.asc. > + > + The last step is to format the key to a format > + BIND understand. This differs a little between "understands" > + version 9.6.2 and 9.7 and later. Both uses a "versions 9.6.2 and 9.7+", perhaps? Certainly "versions" should be plural. Also, s/uses/use/ > + managed-keys clause, but support for > + initial-key was added in 9.7. > + initial-key tells BIND > + automatic tracking of the key. With BIND 9.6.2 "initial-key tells BIND automatic tracking of the key" is not a complete sentence. If I had to guess, I'd say that the initial-key directive tells BIND to automatically track the key, but I'm not entirely sure that's the correct meaning. > + it is necessary to update the key manually when it is changed. The > + format should look like, for BIND 9.6.2: > + > +managed-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 managed-keys directive can > + now be added to named.conf either directly or s/now//, I think. > + by including a file containing the key. After all this is done it > + is just to tell BIND to do s/is just/only remains/ > + DNSSEC validation on queries. This is achieved by > + editing named.conf and add the following to the "adding", for consistency with "editing" > + 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 set up. A successful reply will contain s/just set up/as just configured/ would be less informal. > + the AD > + flag to indicate the data was authenticated. Running a > + query such as &prompt.user; dig @resolver +dnssec Is this "@resolver" supposed to be "@[IP address or hostname of resolver just configured]"? I suspect there is markup for this, if so. > + 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 > +... > + . This means that the resolver is now capable of > + authenticate made DNSqueries. The clause "now capable of authenticate made" doesn't make any sense to me. > + > + > + > + Authorative <acronym>DNS</acronym> server configuration "Authoritative", again. > + In order to get an authorative nameserver to serve a and here. > + DNSSEC signed zone, a little more work is > + required. To sign a zone, two cryptographic keys for that zone must > + be generated. These two keys are usually called the Key Signing Key > + (KSK) and Zone Signing Key > + (ZSK) respectively. The > + KSK is used to build a chain > + of authority to the data in need of validation and as such also called put an "is" in "and as such also called"; there's a couple of places to choose from. > + a Secure Entry Point (SEP) key. This key needs to be published in the > + parent zone as well, 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 + role="domainname">example.com zone depicted in previous > + examples, the first step is to use > + dnssec-keygen to generate the > + KSK and ZSK keypair. This keypair > + can utilize different cryptograhic algorithms. Currently the mandatory > + algorithm is RSA/SHA-1. In the examples the key > + length used is 2048 bits for the KSK and 1024 bits > + for the ZSK. To generate the > + KSK for + role="domainname">example.com, run &promt.user; > + dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE > + example.com and to generate the > + ZSK, run &promt.user; > + dnssec-keygen -a RSASHA1 -b 1024 -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. The public key > + files can now be included in the zone file, using the > + $include statement. It should look something like > + this: > +$include Kexample.net.+005+nnnnn.key ; ZSK > +$include Kexample.net.+005+nnnnn.key ; KSK > + > + > + The only steps left is to sign the zone and tell s/is/are/ > + BIND to use the signed zonefile. 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 > + &promt.user; dnssec-signzone -o example.com -k > + Kexample.com+005+nnnnn example.com.db > + Kexample.com+005+nnnnn.key. The key supplied to > + the -k 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. To use this signed zone > + just modify the zone directive in named.conf to > + use this file. By default, the signatures are only valid 30 days, > + meaning that the zone needs to be resigned within this time. It is > + possible to make a script and a cron job to do this. See relevant > + manuals for details. > + Some cautionary words at the end. 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 key, 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. > + Failiure to do this might render the DNS data > + unavailable for a time, untill the new key has propagated through the > + DNS hierarchy. For more information on key > + rollovers and other DNSSEC operational issues, see > + + url="http://www.ietf.org/rfc/rfc4641.txt">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, > + from now on 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 the tool > + nsupdate with the new option > + -l is used. rndc has > + also grown the ability to sign zones with keys in the key repository, > + using the option sign. To make this work, put > + something similar to what is shown below into > + named.conf. > +zone example.com { > + type master; > + key-directory "keys"; > + update-policy local; > + auto-dnssec maintain; > + file "dynamic/example.com.zone"; > +}; > + This will tell named to use automatic signing and > + updating of the zone example.com. > + After this is done just generate keys for the zone as explained in > + , put these in the key repository > + denoted by key-directory in the zone configuration "denoted by" could be ambiguous -- "given as the argument to the key-directory directive" might be better. > + and sign the zone using rndc. Updates to > + the zone is done using nsupdate which will I'm not sure what is intended, here. Is it trying to say that further updates to the zone must only be done using nsupdate, which will automatically re-sign the zone? > + take care of resigning the zone with the new data added. For further > + details, see and the > + BIND documentation. > + > + > + > + > + > Security > > Although BIND is the most common implementation of DNS, > @@ -3897,7 +4184,7 @@ > > > > - > + > Further Reading > > BIND/named manual pages: > @@ -3932,6 +4219,38 @@ > url="http://tools.ietf.org/html/rfc1035">RFC1035 > - Domain Names - Implementation and Specification > Hmm, I kind of want all of these to be —es. Thanks for putting together this DNSSEC section -- it will be really great to have it more widely deployed! -Ben Kaduk > + > + > + + url="http://tools.ietf.org/html/rfc4033">RFC4033 > + - DNS Security Introduction and Requirements > + > + > + > + + url="http://tools.ietf.org/html/rfc4034">RFC4034 > + - Recource Records for the DNS Security Extensions > + > + > + > + + url="http://tools.ietf.org/html/rfc4035">RFC4035 > + - Protocol Modifications for the DNS Security Extensions > + > + > + > + + url="http://tools.ietf.org/html/rfc4641">RFC4641 > + - DNSSEC Operational Practices > + > + > + > + + url="http://tools.ietf.org/html/rfc5011">RFC 5011 > + - Automated Updates of DNS Security (DNSSEC > + Trust Anchors > + > + > > > > --- network-servers.chapter.sgml.diff ends here --- > > >> Release-Note: >> Audit-Trail: >> Unformatted: > _______________________________________________ > freebsd-doc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-doc > To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org" > From: Chuck Swiger To: Benjamin Kaduk Cc: Niclas Zeising , freebsd-doc@freebsd.org, FreeBSD-gnats-submit@freebsd.org Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Sun, 22 May 2011 11:57:06 -0700 On May 22, 2011, at 11:26 AM, Benjamin Kaduk wrote: >> + provide either confidentiality nor protection against false assumptions, > > I believe that "nor" should be "or" here, but I don't have a good reference with me at the moment to check. Agreed. One uses "either" and "or" together, or "neither" and "nor". Regards, -- -Chuck From: Niclas Zeising To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Sun, 22 May 2011 23:45:05 +0200 This is a multi-part message in MIME format. --------------020301000301000000020306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi! Here is an updated patch with changes based on suggestions from Ben Kaduk and Warren Block. Thank you very much for your help! -- Niclas --------------020301000301000000020306 Content-Type: text/plain; name="network-servers.chapter.sgml.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="network-servers.chapter.sgml.diff" Index: chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v retrieving revision 1.130 diff -u -d -r1.130 chapter.sgml --- chapter.sgml 15 May 2011 20:41:30 -0000 1.130 +++ chapter.sgml 22 May 2011 20:40:32 -0000 @@ -3872,6 +3872,293 @@ + DNSSEC + + BIND + DNS security extensions + + + Domain Name System Security Extensions, or DNSSEC + for short, is a suite of specifications to protect + DNS clients, i.e. Internet resolvers, from forged + DNS data, such as spoofed DNS + records. By using digital signatures, a resolver can verify the + integrity and authenticity of the record. Note that + DNSSEC only provides integrity, it does not + provide neither confidentiality nor protection against false + assumptions. This meanins that it cannot protect against people going + to example.net instead of + example.com. The only + thing DNSSEC does is authenticate that the data is + from the domain owner and that it has not been compromised in transit. + The security of DNS is believed to be an important + step in securing the Internet in general. For a more in-depth + details of how DNSSEC works, the relevant + RFCs are a good place to start. See the list in + . + + The next two sections will demonstrate how to enable + DNSSEC for an authoritative DNS + server and a recursive (or caching) DNS server + running BIND9. While all versions of + BIND9 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 + 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 done by + a recursive DNS server reqires a few changes to + named.conf. Before making these changes + the root zone key, or trust anchor, must be aquired. 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 behind the DNSKEY record + type, is the one needed. This value indicates that this is a + Secure Entry Point (SEP, + more 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 section . + + Now the key must be verified 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. Both use a managed-keys clause, but + support for initial-key was added in 9.7. + initial-key makes BIND + automatically track changes to the key and update it as necesarry. + Users of BIND 9.6.2 must do this manually. + For BIND 9.6.2 the format should look like: + +managed-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 managed-keys directive can + now be added to named.conf either directly or + by including a file containing the key. After these steps, tell + 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 +... + . This means that the resolver is now capable of + authenticating DNSqueries. + + + + Authoritative <acronym>DNS</acronym> server configuration + In order to get an authoritative nameserver to serve a + DNSSEC signed zone, a little more work is + required. To sign a zone, two cryptographic keys for that zone must + be generated. These two keys are usually called the Key Signing Key + (KSK) and Zone Signing Key + (ZSK) respectively. 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. This key + needs to be published in the parent zone as well, 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 keypair. This keypair + can utilize different cryptograhic algorithms. Currently the mandatory + algorithm is RSA/SHA-1. In the examples the key + length used is 2048 bits for the KSK and 1024 bits + for the ZSK. To generate the + KSK for example.com, run &prompt.user; + dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE + example.com and to generate the + ZSK, run &prompt.user; + dnssec-keygen -a RSASHA1 -b 1024 -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. The public key + files can now be included in the zone file, using the + $include statement. It should look something like + this: +$include Kexample.net.+005+nnnnn.key ; ZSK +$include Kexample.net.+005+nnnnn.key ; KSK + + + Finally, sign the zone and tell BIND to use + the signed zonefile. 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 example.com.db + Kexample.com+005+nnnnn.key. The key supplied to + the -k 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. To use this signed zone + just modify the zone directive in named.conf to + use this file. By default, the signatures are only valid 30 days, + meaning that the zone needs to be resigned within this time. It is + possible to make a script and a cron job to do this. See relevant + manuals for details. + Some cautionary words at the end. 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 key, 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. + Failiure 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 exanple.com, add the + following to named.conf: +zone example.com { + type master; + key-directory "keys"; + update-policy local; + auto-dnssec maintain; + file "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 sign the zone using + rndc. 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 Although BIND is the most common implementation of DNS, @@ -3897,11 +4184,12 @@ - + 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; @@ -3932,6 +4220,38 @@ url="http://tools.ietf.org/html/rfc1035">RFC1035 - Domain Names - Implementation and Specification + + + RFC4033 + - DNS Security Introduction and Requirements + + + + RFC4034 + - Recource 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 + + --------------020301000301000000020306-- From: Niclas Zeising To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Mon, 23 May 2011 01:25:55 +0200 This is a multi-part message in MIME format. --------------040500050509000704050409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here is a further updated patch. It fixes some typos and other similar stuff. It also adds manual pages to man-refs.ent. Regards! -- Niclas --------------040500050509000704050409 Content-Type: text/plain; name="network-servers.chapter.sgml.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="network-servers.chapter.sgml.diff" Index: en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v retrieving revision 1.130 diff -u -d -r1.130 chapter.sgml --- en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 15 May 2011 20:41:30 -0000 1.130 +++ en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 22 May 2011 22:49:58 -0000 @@ -3872,6 +3872,292 @@ + DNSSEC + + BIND + DNS security extensions + + + Domain Name System Security Extensions, or DNSSEC + for short, is a suite of specifications to protect + DNS clients, i.e. Internet resolvers, from forged + DNS data, such as spoofed DNS + records. By using digital signatures, a resolver can verify the + integrity and authenticity of the record. Note that + DNSSEC only provides integrity, it does not + provide neither confidentiality nor protection against false + assumptions. This meanins that it cannot protect against people going + to example.net instead of + example.com. The only + thing DNSSEC does is authenticate that the data is + from the domain owner and that it has not been compromised in transit. + The security of DNS is believed to be an important + step in securing the Internet in general. For a more in-depth + details of how DNSSEC works, the relevant + RFCs are a good place to start. See the list in + . + + The next two sections will demonstrate how to enable + DNSSEC for an authoritative DNS + server and a recursive (or caching) DNS server + running BIND9. While all versions of + BIND9 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 + 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 done by + a recursive DNS server reqires a few changes to + named.conf. Before making these changes + the root zone key, or trust anchor, must be aquired. 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 behind the DNSKEY record + type, is the one needed. This value indicates that this is a + Secure Entry Point + (SEP), + more 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 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. Both use a managed-keys clause, but + support for initial-key was added in 9.7. + initial-key makes BIND + automatically track changes to the key and update it as necesarry. + Users of BIND 9.6.2 must do this manually. + For BIND 9.6.2 the format should look like: + +managed-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 managed-keys directive can + now be added to named.conf either directly or + by including a file containing the key. After these steps, tell + 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 +... + This means that the resolver is now capable of + authenticating DNS queries. + + + + Authoritative <acronym>DNS</acronym> server configuration + In order to get an authoritative nameserver to serve a + DNSSEC signed zone, a little more work is + required. To sign a zone, two cryptographic keys for that zone must + be generated. These two keys are usually called the Key Signing Key + (KSK) and Zone Signing Key + (ZSK) respectively. 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. This key + needs to be published in the parent zone as well, 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 keypair. This keypair + can utilize different cryptograhic algorithms. Currently the mandatory + algorithm is RSA/SHA-1. In the examples the key + length used is 2048 bits for the KSK and 1024 bits + for the ZSK. To generate the + KSK for example.com, run + &prompt.user; dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE example.com + and to generate the + ZSK, run + &prompt.user; dnssec-keygen -a RSASHA1 -b 1024 -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. The public key + files can now be included in the zone file, using the + $include statement. It should look something like + this: +$include Kexample.net.+005+nnnnn.key ; ZSK +$include Kexample.net.+005+nnnnn.key ; KSK + + + Finally, sign the zone and tell BIND to use + the signed zonefile. 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 example.com.db Kexample.com+005+nnnnn.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. To use this signed zone + just modify the zone directive in named.conf to + use this file. By default, the signatures are only valid 30 days, + meaning that the zone needs to be resigned within this time. It is + possible to make a script and a cron job to do this. See relevant + manuals for details. + + Some cautionary words at the end. 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 key, 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. + Failiure 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 exanple.com, add the + following to named.conf: +zone example.com { + type master; + key-directory "keys"; + update-policy local; + auto-dnssec maintain; + file "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 sign + the zone using rndc. 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 Although BIND is the most common implementation of DNS, @@ -3897,11 +4183,12 @@ - + 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; @@ -3932,6 +4219,38 @@ url="http://tools.ietf.org/html/rfc1035">RFC1035 - Domain Names - Implementation and Specification + + + RFC4033 + - DNS Security Introduction and Requirements + + + + RFC4034 + - Recource 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 + + Index: share/sgml/man-refs.ent =================================================================== RCS file: /home/ncvs/doc/share/sgml/man-refs.ent,v retrieving revision 1.511 diff -u -d -r1.511 man-refs.ent --- share/sgml/man-refs.ent 11 Feb 2011 16:15:44 -0000 1.511 +++ share/sgml/man-refs.ent 22 May 2011 22:50:40 -0000 @@ -4257,6 +4257,8 @@ + + --------------040500050509000704050409-- From: Niclas Zeising To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Mon, 23 May 2011 14:46:30 +0200 This is a multi-part message in MIME format. --------------090906090406000801020902 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit After comments from Doug Barton and more comments from Warren Block, here is a further refined patch with some changes and spelling fixes. It also contains the necessary changes to man-refs.ent. Thank you for the help and review! -- Niclas --------------090906090406000801020902 Content-Type: text/plain; name="network-servers.chapter.sgml.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="network-servers.chapter.sgml.diff" Index: en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v retrieving revision 1.130 diff -u -d -r1.130 chapter.sgml --- en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 15 May 2011 20:41:30 -0000 1.130 +++ en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 23 May 2011 12:10:10 -0000 @@ -3872,6 +3872,325 @@ + <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 ; ZSK +$include Kexample.com.+005+nnnnn.ZSK.key ; KSK + + 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 Although BIND is the most common implementation of DNS, @@ -3897,11 +4216,12 @@ - + 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; @@ -3922,6 +4242,17 @@ + Root + DNSSEC + + + + + DNSSEC Trust Anchor Publication for the Root + Zone + + + RFC1034 - Domain Names - Concepts and Facilities @@ -3932,6 +4263,38 @@ url="http://tools.ietf.org/html/rfc1035">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 + + Index: share/sgml/man-refs.ent =================================================================== RCS file: /home/ncvs/doc/share/sgml/man-refs.ent,v retrieving revision 1.511 diff -u -d -r1.511 man-refs.ent --- share/sgml/man-refs.ent 11 Feb 2011 16:15:44 -0000 1.511 +++ share/sgml/man-refs.ent 23 May 2011 12:10:56 -0000 @@ -4257,6 +4257,8 @@ + + --------------090906090406000801020902-- Responsible-Changed-From-To: freebsd-doc->bcr Responsible-Changed-By: bcr Responsible-Changed-When: Tue May 24 09:27:27 UTC 2011 Responsible-Changed-Why: Grab this PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=157245 From: Niclas Zeising To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Tue, 24 May 2011 18:29:20 +0200 This is a multi-part message in MIME format. --------------060709040109030203000004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here is another patch. This patch just contains some whitespace fixes and puts outside . Regards! -- Niclas --------------060709040109030203000004 Content-Type: text/plain; name="network-servers.chapter.sgml.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="network-servers.chapter.sgml.diff" Index: en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v retrieving revision 1.131 diff -u -d -r1.131 chapter.sgml --- en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 23 May 2011 15:32:34 -0000 1.131 +++ en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 23 May 2011 17:21:25 -0000 @@ -3872,6 +3872,340 @@ + <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 ; ZSK +$include Kexample.com.+005+nnnnn.ZSK.key ; KSK + + 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 Although BIND is the most common implementation of DNS, @@ -3897,11 +4231,12 @@ - + 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; @@ -3922,6 +4257,17 @@ + Root + DNSSEC + + + + + DNSSEC Trust Anchor Publication for the Root + Zone + + + RFC1034 - Domain Names - Concepts and Facilities @@ -3932,6 +4278,38 @@ url="http://tools.ietf.org/html/rfc1035">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 + + Index: share/sgml/man-refs.ent =================================================================== RCS file: /home/ncvs/doc/share/sgml/man-refs.ent,v retrieving revision 1.511 diff -u -d -r1.511 man-refs.ent --- share/sgml/man-refs.ent 11 Feb 2011 16:15:44 -0000 1.511 +++ share/sgml/man-refs.ent 23 May 2011 17:22:07 -0000 @@ -4257,6 +4257,8 @@ + + --------------060709040109030203000004-- From: Doug Barton To: Niclas Zeising Cc: freebsd-doc@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Tue, 24 May 2011 13:08:13 -0700 Excellent work! :) 2 small nits remain, otherwise this looks good to go. On 05/23/2011 05:50, Niclas Zeising wrote: > + found in The href should be http://tools.ietf.org/html/rfc4641 as they are in 29.6.10. The tools site has a much better overall viewing experience, and more importantly gives clear indications if an RFC has been obsoleted. > + $include Kexample.com.+005+nnnnn.KSK.key ; ZSK > +$include Kexample.com.+005+nnnnn.ZSK.key ; KSK The labels after the ;comment are reversed. The first should be KSK. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From: Niclas Zeising To: bug-followup@FreeBSD.org, niclas.zeising@gmail.com Cc: Subject: Re: docs/157245: [PATCH] [RFC] Add a section about DNSSEC to the DNS chapter in the handbook Date: Tue, 24 May 2011 22:25:51 +0200 This is a multi-part message in MIME format. --------------000703050907060405020802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here is a another new patch which fixes two more things pointed out by dougb@. Hopefully this is the last one. Thanks for all help! -- Niclas --------------000703050907060405020802 Content-Type: text/plain; name="network-servers.chapter.sgml.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="network-servers.chapter.sgml.diff" Index: en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml,v retrieving revision 1.131 diff -u -d -r1.131 chapter.sgml --- en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 23 May 2011 15:32:34 -0000 1.131 +++ en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 24 May 2011 19:54:23 -0000 @@ -3872,6 +3872,340 @@ + <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 Although BIND is the most common implementation of DNS, @@ -3897,11 +4231,12 @@ - + 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; @@ -3922,6 +4257,17 @@ + Root + DNSSEC + + + + + DNSSEC Trust Anchor Publication for the Root + Zone + + + RFC1034 - Domain Names - Concepts and Facilities @@ -3932,6 +4278,38 @@ url="http://tools.ietf.org/html/rfc1035">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 + + Index: share/sgml/man-refs.ent =================================================================== RCS file: /home/ncvs/doc/share/sgml/man-refs.ent,v retrieving revision 1.511 diff -u -d -r1.511 man-refs.ent --- share/sgml/man-refs.ent 11 Feb 2011 16:15:44 -0000 1.511 +++ share/sgml/man-refs.ent 24 May 2011 19:55:12 -0000 @@ -4257,6 +4257,8 @@ + + --------------000703050907060405020802-- From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: docs/157245: commit references a PR Date: Wed, 25 May 2011 14:18:28 +0000 (UTC) bcr 2011-05-25 14:18:20 UTC FreeBSD doc repository Modified files: share/sgml man-refs.ent en_US.ISO8859-1/books/handbook/network-servers chapter.sgml Log: Please welcome a new section about DNSSEC to the handbook. A detailed introduction to the problem is given, as well as examples for setting up DNSSEC with BIND and further readings are included. A big thank you to Niclas Zeising for the writeup and others who provided feedback and corrections/additions. PR: docs/157245 Submitted by: Niclas Zeising (niclas dot zeising at gmail dot com) Additions by: Benjamin Kaduk, Warren Block, dougb@ Revision Changes Path 1.132 +392 -30 doc/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml 1.512 +2 -0 doc/share/sgml/man-refs.ent _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" State-Changed-From-To: open->closed State-Changed-By: bcr State-Changed-When: Wed May 25 14:30:20 UTC 2011 State-Changed-Why: Patch committed. Thanks to all who were involved in this. Good teamwork between contributors and committers! PR closed. http://www.freebsd.org/cgi/query-pr.cgi?pr=157245 >Unformatted: