From owner-freebsd-doc@FreeBSD.ORG Mon May 23 12:50:17 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FFD8106568F for ; Mon, 23 May 2011 12:50:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 58D778FC22 for ; Mon, 23 May 2011 12:50:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4NCoED2050384 for ; Mon, 23 May 2011 12:50:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4NCoEId050383; Mon, 23 May 2011 12:50:14 GMT (envelope-from gnats) Date: Mon, 23 May 2011 12:50:14 GMT Message-Id: <201105231250.p4NCoEId050383@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Niclas Zeising 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 Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 12:50:17 -0000 The following reply was made to PR docs/157245; it has been noted by GNATS. 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--