From owner-freebsd-doc@FreeBSD.ORG Sun May 22 18:41:57 2011 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA5C0106566C; Sun, 22 May 2011 18:41:57 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by mx1.freebsd.org (Postfix) with ESMTP id 5ABAD8FC08; Sun, 22 May 2011 18:41:56 +0000 (UTC) X-AuditID: 12074425-b7b78ae000007e02-ba-4dd955702f08 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 29.1A.32258.07559DD4; Sun, 22 May 2011 14:26:56 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p4MIQs3D013966; Sun, 22 May 2011 14:26:54 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p4MIQphX029803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 22 May 2011 14:26:53 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p4MIQpbr017112; Sun, 22 May 2011 14:26:51 -0400 (EDT) Date: Sun, 22 May 2011 14:26:50 -0400 (EDT) From: Benjamin Kaduk To: Niclas Zeising In-Reply-To: <201105220934.p4M9Y9JL041108@vincent.daemonic.se> Message-ID: References: <201105220934.p4M9Y9JL041108@vincent.daemonic.se> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixG6nrlsQetPX4NZjZYtTZ7pYLVqerGa3 eNN3mNGB2WPGp/ksHjtn3WUPYIrisklJzcksSy3St0vgyrh+5CpTwYZ1jBW97RuZGxi3dDB2 MXJySAiYSEw5cRHKFpO4cG89WxcjF4eQwD5GiYuTj0I5Gxglln+cxQThHGCS6N34FcppYJR4 u3wvWD+LgLbEwvXT2EBsNgEViZlvNoLZIgK6Eiuu3gGzmQVsJRbffgxkc3AIC6RL3F4kCRLm FLCTuNVyCCzMK+Ag8e4ID0hYCKi6ee15VhBbVEBHYvX+KSwgNq+AoMTJmU9YICZaSvxb+4t1 AqPgLCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFula6OVmluilppRuYgSHrYvqDsYJ h5QOMQpwMCrx8C7WvOkrxJpYVlyZe4hRkoNJSZTXPxgoxJeUn1KZkVicEV9UmpNafIhRgoNZ SYS3QfuGrxBvSmJlVWpRPkxKmoNFSZx3vqS6r5BAemJJanZqakFqEUxWhoNDSYJ3ZwjQUMGi 1PTUirTMnBKENBMHJ8hwHqDhfiCLeYsLEnOLM9Mh8qcYdTk6H/w4wCjEkpeflyolztsLMkgA pCijNA9uDizdvGIUB3pLmHc7SBUPMFXBTXoFtIQJaMnHvGsgS0oSEVJSDYwlaTNM9R8eOL2+ L3D+1MQs7QbdbZd/8/335wqZuv3TmRfHG2YvZhXuFPyT9bv50YpfGh1bRaWlP1Q2rlVscJpQ OFlutcrmI8uuNl5cIswqVz4lznPZeqkYIe9jJwwLdpzzigmyq2Tw7PlgmC47J+vJO7uv7cvC U/nXaVx8m/9ze+itLwlGaU5KLMUZiYZazEXFiQCrxXteEgMAAA== Cc: 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 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 18:41:57 -0000 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" >