From owner-freebsd-doc@FreeBSD.ORG Sun May 22 20:39:00 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 10BBC106566C; Sun, 22 May 2011 20:39:00 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 41D4B8FC17; Sun, 22 May 2011 20:38:59 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 8F65119031; Sun, 22 May 2011 22:20:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id oWBfJCfGU2aV; Sun, 22 May 2011 22:20:04 +0200 (CEST) Received: from danger-mbp.local (adsl-dyn230.91-127-165.t-com.sk [91.127.165.230]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id F263219017; Sun, 22 May 2011 22:20:03 +0200 (CEST) Message-ID: <4DD96FF3.8080101@FreeBSD.org> Date: Sun, 22 May 2011 22:20:03 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18pre) Gecko/20110427 Lanikai/3.1.11pre MIME-Version: 1.0 To: freebsd-doc@freebsd.org, Doug Barton References: <201105220934.p4M9Y9JL041108@vincent.daemonic.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 20:39:00 -0000 On 22.5.2011 20:26, Benjamin Kaduk wrote: > 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. I believe the right person for the tech review is dougb@ (cc:ing him) >> >> --- 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" >> > _______________________________________________ > 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" -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer