diff options
| author | Warren Block <wblock@FreeBSD.org> | 2016-04-03 18:57:15 +0000 |
|---|---|---|
| committer | Warren Block <wblock@FreeBSD.org> | 2016-04-03 18:57:15 +0000 |
| commit | 49e2a7fc5120bfefe17451b329b8e06733c59c6f (patch) | |
| tree | 1d0286c50e5919c90bbc5e1a3e25aa80047fde95 /en_US.ISO8859-1/books/handbook/network-servers/chapter.xml | |
| parent | 50eb129c54a2fb0869c33f29e1d2edd5b367be57 (diff) | |
| download | doc-49e2a7fc5120bfefe17451b329b8e06733c59c6f.tar.gz doc-49e2a7fc5120bfefe17451b329b8e06733c59c6f.zip | |
Whitespace-only fixes, translators please ignore.
Notes
Notes:
svn path=/head/; revision=48529
Diffstat (limited to 'en_US.ISO8859-1/books/handbook/network-servers/chapter.xml')
| -rw-r--r-- | en_US.ISO8859-1/books/handbook/network-servers/chapter.xml | 1448 |
1 files changed, 736 insertions, 712 deletions
diff --git a/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml b/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml index 13726050a0..ddf404eab3 100644 --- a/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml @@ -480,18 +480,19 @@ server-program-arguments</programlisting> <authorgroup> <author> <personname> - <firstname>Tom</firstname> - <surname>Rhodes</surname> - </personname> + <firstname>Tom</firstname> + <surname>Rhodes</surname> + </personname> <contrib>Reorganized and enhanced by </contrib> </author> </authorgroup> + <authorgroup> <author> <personname> - <firstname>Bill</firstname> - <surname>Swingle</surname> - </personname> + <firstname>Bill</firstname> + <surname>Swingle</surname> + </personname> <contrib>Written by </contrib> </author> </authorgroup> @@ -799,22 +800,23 @@ rpc_statd_enable="YES"</programlisting> <sect2 xml:id="network-amd"> <info> - <title>Automating Mounts with &man.amd.8;</title> + <title>Automating Mounts with &man.amd.8;</title> <authorgroup> <author> <personname> - <firstname>Wylie</firstname> - <surname>Stilwell</surname> - </personname> + <firstname>Wylie</firstname> + <surname>Stilwell</surname> + </personname> <contrib>Contributed by </contrib> </author> </authorgroup> + <authorgroup> <author> <personname> - <firstname>Chern</firstname> - <surname>Lee</surname> + <firstname>Chern</firstname> + <surname>Lee</surname> </personname> <contrib>Rewritten by </contrib> </author> @@ -1003,8 +1005,8 @@ Exports list on foobar: OS X document</link>.</para> <para>Consult the &man.automount.8;, &man.automountd.8;, - &man.autounmountd.8;, and &man.auto.master.5; manual pages for - more information.</para> + &man.autounmountd.8;, and &man.auto.master.5; manual pages for + more information.</para> </sect2> </sect1> @@ -1253,28 +1255,28 @@ Exports list on foobar: <row> <entry><systemitem>ellington</systemitem></entry> <entry><systemitem - class="ipaddress">10.0.0.2</systemitem></entry> + class="ipaddress">10.0.0.2</systemitem></entry> <entry><acronym>NIS</acronym> master</entry> </row> <row> <entry><systemitem>coltrane</systemitem></entry> <entry><systemitem - class="ipaddress">10.0.0.3</systemitem></entry> + class="ipaddress">10.0.0.3</systemitem></entry> <entry><acronym>NIS</acronym> slave</entry> </row> <row> <entry><systemitem>basie</systemitem></entry> <entry><systemitem - class="ipaddress">10.0.0.4</systemitem></entry> + class="ipaddress">10.0.0.4</systemitem></entry> <entry>Faculty workstation</entry> </row> <row> <entry><systemitem>bird</systemitem></entry> <entry><systemitem - class="ipaddress">10.0.0.5</systemitem></entry> + class="ipaddress">10.0.0.5</systemitem></entry> <entry>Client machine</entry> </row> @@ -1453,10 +1455,11 @@ nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</ the <systemitem class="username">root</systemitem> and any other administrative accounts.</para> - <note><para>Ensure that the - <filename>/var/yp/master.passwd</filename> is neither group - or world readable by setting its permissions to - <literal>600</literal>.</para> + <note> + <para>Ensure that the + <filename>/var/yp/master.passwd</filename> is neither + group or world readable by setting its permissions to + <literal>600</literal>.</para> </note> <para>After completing this task, initialize the @@ -2236,15 +2239,15 @@ TWO (,hotel,test-domain) <sect1 xml:id="network-ldap"> <info> - <title>Lightweight Directory Access Protocol - (<acronym>LDAP</acronym>)</title> + <title>Lightweight Directory Access Protocol + (<acronym>LDAP</acronym>)</title> <authorgroup> <author> - <personname> - <firstname>Tom</firstname> - <surname>Rhodes</surname> - </personname> + <personname> + <firstname>Tom</firstname> + <surname>Rhodes</surname> + </personname> <contrib>Written by </contrib> </author> </authorgroup> @@ -3279,62 +3282,60 @@ freebsd.org. (A) information that will be given out by the name server in response to queries.</para> - <sect3> - <title>Starting BIND</title> + <sect3> + <title>Starting BIND</title> - <indexterm> - <primary>BIND</primary> - <secondary>starting</secondary> - </indexterm> + <indexterm> + <primary>BIND</primary> + <secondary>starting</secondary> + </indexterm> - <para>Since BIND is installed by default, configuring it is - relatively simple.</para> + <para>Since BIND is installed by default, configuring it is + relatively simple.</para> - <para>The default <application>named</application> configuration - is that of a basic resolving name server, running in a - &man.chroot.8; environment, and restricted to listening on the - local IPv4 loopback address (127.0.0.1). To start the server - one time with this configuration, use the following - command:</para> + <para>The default <application>named</application> + configuration is that of a basic resolving name server, + running in a &man.chroot.8; environment, and restricted to + listening on the local IPv4 loopback address (127.0.0.1). + To start the server one time with this configuration, use + the following command:</para> - <screen>&prompt.root; <userinput>service named onestart</userinput></screen> + <screen>&prompt.root; <userinput>service named onestart</userinput></screen> - <para>To ensure the <application>named</application> daemon is - started at boot each time, put the following line into the - <filename>/etc/rc.conf</filename>:</para> + <para>To ensure the <application>named</application> daemon is + started at boot each time, put the following line into the + <filename>/etc/rc.conf</filename>:</para> - <programlisting>named_enable="YES"</programlisting> + <programlisting>named_enable="YES"</programlisting> - <para>There are many configuration options for - <filename>/etc/namedb/named.conf</filename> that are beyond - the scope of this document. Other startup options - for <application>named</application> on &os; can be found in - the <literal>named_<replaceable>*</replaceable></literal> - flags in <filename>/etc/defaults/rc.conf</filename> and in - &man.rc.conf.5;. The - <xref linkend="configtuning-rcd"/> section is also a good - read.</para> - </sect3> + <para>There are many configuration options for + <filename>/etc/namedb/named.conf</filename> that are beyond + the scope of this document. Other startup options for + <application>named</application> on &os; can be found in the + <literal>named_<replaceable>*</replaceable></literal> flags + in <filename>/etc/defaults/rc.conf</filename> and in + &man.rc.conf.5;. The <xref linkend="configtuning-rcd"/> + section is also a good read.</para> + </sect3> - <sect3> - <title>Configuration Files</title> + <sect3> + <title>Configuration Files</title> - <indexterm> - <primary>BIND</primary> - <secondary>configuration files</secondary> - </indexterm> + <indexterm> + <primary>BIND</primary> + <secondary>configuration files</secondary> + </indexterm> - <para>Configuration files for <application>named</application> - currently reside in - <filename>/etc/namedb</filename> directory - and will need modification before use unless all that is - needed is a simple resolver. This is where most of the - configuration will be performed.</para> + <para>Configuration files for <application>named</application> + currently reside in <filename>/etc/namedb</filename> + directory and will need modification before use unless all + that is needed is a simple resolver. This is where most of + the configuration will be performed.</para> - <sect4> - <title><filename>/etc/namedb/named.conf</filename></title> + <sect4> + <title><filename>/etc/namedb/named.conf</filename></title> - <programlisting>// $FreeBSD$ + <programlisting>// $FreeBSD$ // // Refer to the named.conf(5) and named(8) man pages, and the documentation // in /usr/share/doc/bind9 for more details. @@ -3390,24 +3391,25 @@ options { // named_auto_forward_only (the effect of which is described above). // include "/etc/namedb/auto_forward.conf";</programlisting> - <para>Just as the comment says, to benefit from an uplink's - cache, <literal>forwarders</literal> can be enabled here. - Under normal circumstances, a name server will recursively - query the Internet looking at certain name servers until it - finds the answer it is looking for. Having this enabled - will have it query the uplink's name server (or name server - provided) first, taking advantage of its cache. If the - uplink name server in question is a heavily trafficked, fast - name server, enabling this may be worthwhile.</para> - - <warning> - <para><systemitem class="ipaddress">127.0.0.1</systemitem> - will <emphasis>not</emphasis> work here. Change this - <acronym>IP</acronym> address to a name server at the - uplink.</para> - </warning> - - <programlisting> /* + <para>Just as the comment says, to benefit from an uplink's + cache, <literal>forwarders</literal> can be enabled here. + Under normal circumstances, a name server will recursively + query the Internet looking at certain name servers until + it finds the answer it is looking for. Having this + enabled will have it query the uplink's name server (or + name server provided) first, taking advantage of its + cache. If the uplink name server in question is a heavily + trafficked, fast name server, enabling this may be + worthwhile.</para> + + <warning> + <para><systemitem class="ipaddress">127.0.0.1</systemitem> + will <emphasis>not</emphasis> work here. Change this + <acronym>IP</acronym> address to a name server at the + uplink.</para> + </warning> + + <programlisting> /* Modern versions of BIND use a random <acronym>UDP</acronym> port for each outgoing query by default in order to dramatically reduce the possibility of cache poisoning. All users are strongly encouraged to utilize @@ -3646,54 +3648,55 @@ zone "1.168.192.in-addr.arpa" { }; */</programlisting> - <para>In <filename>named.conf</filename>, these are examples - of slave entries for a forward and reverse zone.</para> + <para>In <filename>named.conf</filename>, these are examples + of slave entries for a forward and reverse zone.</para> - <para>For each new zone served, a new zone entry must be added - to <filename>named.conf</filename>.</para> + <para>For each new zone served, a new zone entry must be + added to <filename>named.conf</filename>.</para> - <para>For example, the simplest zone entry for - <systemitem class="fqdomainname">example.org</systemitem> - can look like:</para> + <para>For example, the simplest zone entry for + <systemitem class="fqdomainname">example.org</systemitem> + can look like:</para> - <programlisting>zone "example.org" { + <programlisting>zone "example.org" { type master; file "master/example.org"; };</programlisting> - <para>The zone is a master, as indicated by the - <option>type</option> statement, holding its zone - information in - <filename>/etc/namedb/master/example.org</filename> - indicated by the <option>file</option> statement.</para> + <para>The zone is a master, as indicated by the + <option>type</option> statement, holding its zone + information in + <filename>/etc/namedb/master/example.org</filename> + indicated by the <option>file</option> statement.</para> - <programlisting>zone "example.org" { + <programlisting>zone "example.org" { type slave; file "slave/example.org"; };</programlisting> - <para>In the slave case, the zone information is transferred - from the master name server for the particular zone, and - saved in the file specified. If and when the master server - dies or is unreachable, the slave name server will have the - transferred zone information and will be able to serve - it.</para> - </sect4> - - <sect4> - <title>Zone Files</title> - - <indexterm> - <primary>BIND</primary> - <secondary>zone files</secondary> - </indexterm> - - <para>An example master zone file for <systemitem - class="fqdomainname">example.org</systemitem> (existing - within <filename>/etc/namedb/master/example.org</filename>) - is as follows:</para> - - <programlisting>$TTL 3600 ; 1 hour default TTL + <para>In the slave case, the zone information is transferred + from the master name server for the particular zone, and + saved in the file specified. If and when the master + server dies or is unreachable, the slave name server will + have the transferred zone information and will be able to + serve it.</para> + </sect4> + + <sect4> + <title>Zone Files</title> + + <indexterm> + <primary>BIND</primary> + <secondary>zone files</secondary> + </indexterm> + + <para>An example master zone file for + <systemitem class="fqdomainname">example.org</systemitem> + (existing within + <filename>/etc/namedb/master/example.org</filename>) is as + follows:</para> + + <programlisting>$TTL 3600 ; 1 hour default TTL example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh @@ -3722,186 +3725,194 @@ mail IN A 192.168.1.5 ; Aliases www IN CNAME example.org.</programlisting> - <para>Note that every hostname ending in a <quote>.</quote> is - an exact hostname, whereas everything without a trailing - <quote>.</quote> is relative to the origin. For example, - <literal>ns1</literal> is translated into - <literal>ns1.<replaceable>example.org.</replaceable></literal></para> + <para>Note that every hostname ending in a <quote>.</quote> + is an exact hostname, whereas everything without a + trailing <quote>.</quote> is relative to the origin. For + example, <literal>ns1</literal> is translated into + <literal>ns1.<replaceable>example.org.</replaceable></literal></para> - <para>The format of a zone file follows:</para> + <para>The format of a zone file follows:</para> - <programlisting>recordname IN recordtype value</programlisting> + <programlisting>recordname IN recordtype value</programlisting> - <indexterm> - <primary><acronym>DNS</acronym></primary> - <secondary>records</secondary> - </indexterm> + <indexterm> + <primary><acronym>DNS</acronym></primary> + <secondary>records</secondary> + </indexterm> - <para>The most commonly used <acronym>DNS</acronym> - records:</para> + <para>The most commonly used <acronym>DNS</acronym> + records:</para> - <variablelist> - <varlistentry> - <term>SOA</term> + <variablelist> + <varlistentry> + <term>SOA</term> - <listitem><para>start of zone authority</para></listitem> - </varlistentry> + <listitem> + <para>start of zone authority</para> + </listitem> + </varlistentry> - <varlistentry> - <term>NS</term> + <varlistentry> + <term>NS</term> - <listitem> - <para>an authoritative name server</para> - </listitem></varlistentry> + <listitem> + <para>an authoritative name server</para> + </listitem> + </varlistentry> - <varlistentry> - <term>A</term> + <varlistentry> + <term>A</term> - <listitem><para>a host address</para></listitem> - </varlistentry> + <listitem> + <para>a host address</para> + </listitem> + </varlistentry> - <varlistentry> - <term>CNAME</term> + <varlistentry> + <term>CNAME</term> - <listitem><para>the canonical name for an - alias</para></listitem> - </varlistentry> + <listitem> + <para>the canonical name for an alias</para> + </listitem> + </varlistentry> - <varlistentry> - <term>MX</term> + <varlistentry> + <term>MX</term> - <listitem><para>mail exchanger</para></listitem> - </varlistentry> + <listitem> + <para>mail exchanger</para> + </listitem> + </varlistentry> - <varlistentry> - <term>PTR</term> + <varlistentry> + <term>PTR</term> - <listitem> - <para>a domain name pointer (used in reverse - <acronym>DNS</acronym>)</para> - </listitem> - </varlistentry> - </variablelist> + <listitem> + <para>a domain name pointer (used in reverse + <acronym>DNS</acronym>)</para> + </listitem> + </varlistentry> + </variablelist> - <programlisting>example.org. IN SOA ns1.example.org. admin.example.org. ( + <programlisting>example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 300 ) ; Negative Response TTL</programlisting> - <variablelist> - <varlistentry> - <term><systemitem - class="fqdomainname">example.org.</systemitem></term> - - <listitem> - <para>the domain name, also the origin for this - zone file.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term><systemitem - class="fqdomainname">ns1.example.org.</systemitem></term> - - <listitem> - <para>the primary/authoritative name server for this - zone.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term><literal>admin.example.org.</literal></term> - - <listitem> - <para>the responsible person for this zone, - email address with <quote>@</quote> - replaced. (<email>admin@example.org</email> becomes - <literal>admin.example.org</literal>)</para> - </listitem> - </varlistentry> - - <varlistentry> - <term><literal>2006051501</literal></term> - - <listitem> - <para>the serial number of the file. This must be - incremented each time the zone file is modified. - Nowadays, many admins prefer a - <literal>yyyymmddrr</literal> format for the serial - number. <literal>2006051501</literal> would mean last - modified 05/15/2006, the latter <literal>01</literal> - being the first time the zone file has been modified - this day. The serial number is important as it alerts - slave name servers for a zone when it is - updated.</para> - </listitem> - </varlistentry> - </variablelist> - - <programlisting> IN NS ns1.example.org.</programlisting> - - <para>This is an NS entry. Every name server that is going to - reply authoritatively for the zone must have one of these - entries.</para> - - <programlisting>localhost IN A 127.0.0.1 + <variablelist> + <varlistentry> + <term><systemitem + class="fqdomainname">example.org.</systemitem></term> + + <listitem> + <para>the domain name, also the origin for this + zone file.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><systemitem + class="fqdomainname">ns1.example.org.</systemitem></term> + + <listitem> + <para>the primary/authoritative name server for this + zone.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>admin.example.org.</literal></term> + + <listitem> + <para>the responsible person for this zone, + email address with <quote>@</quote> + replaced. (<email>admin@example.org</email> becomes + <literal>admin.example.org</literal>)</para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>2006051501</literal></term> + + <listitem> + <para>the serial number of the file. This must be + incremented each time the zone file is modified. + Nowadays, many admins prefer a + <literal>yyyymmddrr</literal> format for the serial + number. <literal>2006051501</literal> would mean + last modified 05/15/2006, the latter + <literal>01</literal> being the first time the zone + file has been modified this day. The serial number + is important as it alerts slave name servers for a + zone when it is updated.</para> + </listitem> + </varlistentry> + </variablelist> + + <programlisting> IN NS ns1.example.org.</programlisting> + + <para>This is an NS entry. Every name server that is going + to reply authoritatively for the zone must have one of + these entries.</para> + + <programlisting>localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5</programlisting> - <para>The A record indicates machine names. As seen above, - <systemitem - class="fqdomainname">ns1.example.org</systemitem> would - resolve to <systemitem - class="ipaddress">192.168.1.2</systemitem>.</para> - - <programlisting> IN A 192.168.1.1</programlisting> - - <para>This line assigns <acronym>IP</acronym> address - <systemitem class="ipaddress">192.168.1.1</systemitem> to - the current origin, in this case <systemitem - class="fqdomainname">example.org</systemitem>.</para> - - <programlisting>www IN CNAME @</programlisting> - - <para>The canonical name record is usually used for giving - aliases to a machine. In the example, - <systemitem>www</systemitem> is aliased to the - <quote>master</quote> machine whose name happens to be the - same as the domain name <systemitem - class="fqdomainname">example.org</systemitem> - (<systemitem class="ipaddress">192.168.1.1</systemitem>). - CNAMEs can never be used together with another kind of - record for the same hostname.</para> - - <indexterm> - <primary>MX record</primary> - </indexterm> - - <programlisting> IN MX 10 mail.example.org.</programlisting> - - <para>The MX record indicates which mail servers are - responsible for handling incoming mail for the zone. - <systemitem - class="fqdomainname">mail.example.org</systemitem> is the - hostname of a mail server, and 10 is the priority of that - mail server.</para> - - <para>One can have several mail servers, with priorities of - 10, 20 and so on. A mail server attempting to deliver to - <systemitem class="fqdomainname">example.org</systemitem> - would first try the highest priority MX (the record with the - lowest priority number), then the second highest, etc, until - the mail can be properly delivered.</para> - - <para>For in-addr.arpa zone files (reverse - <acronym>DNS</acronym>), the same format is used, except - with PTR entries instead of A or CNAME.</para> - - <programlisting>$TTL 3600 + <para>The A record indicates machine names. As seen above, + <systemitem + class="fqdomainname">ns1.example.org</systemitem> would + resolve to <systemitem + class="ipaddress">192.168.1.2</systemitem>.</para> + + <programlisting> IN A 192.168.1.1</programlisting> + + <para>This line assigns <acronym>IP</acronym> address + <systemitem class="ipaddress">192.168.1.1</systemitem> to + the current origin, in this case <systemitem + class="fqdomainname">example.org</systemitem>.</para> + + <programlisting>www IN CNAME @</programlisting> + + <para>The canonical name record is usually used for giving + aliases to a machine. In the example, + <systemitem>www</systemitem> is aliased to the + <quote>master</quote> machine whose name happens to be the + same as the domain name + <systemitem class="fqdomainname">example.org</systemitem> + (<systemitem class="ipaddress">192.168.1.1</systemitem>). + CNAMEs can never be used together with another kind of + record for the same hostname.</para> + + <indexterm> + <primary>MX record</primary> + </indexterm> + + <programlisting> IN MX 10 mail.example.org.</programlisting> + + <para>The MX record indicates which mail servers are + responsible for handling incoming mail for the zone. + <systemitem + class="fqdomainname">mail.example.org</systemitem> is + the hostname of a mail server, and 10 is the priority of + that mail server.</para> + + <para>One can have several mail servers, with priorities of + 10, 20 and so on. A mail server attempting to deliver to + <systemitem class="fqdomainname">example.org</systemitem> + would first try the highest priority MX (the record with + the lowest priority number), then the second highest, etc, + until the mail can be properly delivered.</para> + + <para>For in-addr.arpa zone files (reverse + <acronym>DNS</acronym>), the same format is used, except + with PTR entries instead of A or CNAME.</para> + + <programlisting>$TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial @@ -3919,99 +3930,106 @@ mail IN A 192.168.1.5</programlisting> 4 IN PTR mx.example.org. 5 IN PTR mail.example.org.</programlisting> - <para>This file gives the proper <acronym>IP</acronym> address - to hostname mappings for the above fictitious domain.</para> + <para>This file gives the proper <acronym>IP</acronym> + address to hostname mappings for the above fictitious + domain.</para> - <para>It is worth noting that all names on the right side - of a PTR record need to be fully qualified (i.e., end in - a <quote>.</quote>).</para> - </sect4> - </sect3> + <para>It is worth noting that all names on the right side + of a PTR record need to be fully qualified (i.e., end in + a <quote>.</quote>).</para> + </sect4> + </sect3> - <sect3> - <title>Caching Name Server</title> + <sect3> + <title>Caching Name Server</title> - <indexterm> - <primary>BIND</primary> - <secondary>caching name server</secondary> - </indexterm> + <indexterm> + <primary>BIND</primary> + <secondary>caching name server</secondary> + </indexterm> - <para>A caching name server is a name server whose primary role - is to resolve recursive queries. It simply asks queries of - its own, and remembers the answers for later use.</para> - </sect3> + <para>A caching name server is a name server whose primary + role is to resolve recursive queries. It simply asks + queries of its own, and remembers the answers for later + use.</para> + </sect3> - <sect3> - <title><acronym role="Domain Name Security - Extensions">DNSSEC</acronym></title> + <sect3> + <title><acronym role="Domain Name Security + Extensions">DNSSEC</acronym></title> - <indexterm> - <primary>BIND</primary> - <secondary><acronym>DNS</acronym> security - extensions</secondary> - </indexterm> + <indexterm> + <primary>BIND</primary> + <secondary><acronym>DNS</acronym> security + extensions</secondary> + </indexterm> - <para>Domain Name System Security Extensions, or <acronym - role="Domain Name Security Extensions">DNSSEC</acronym> for - short, is a suite of specifications to protect resolving name - servers from forged <acronym>DNS</acronym> data, such as - spoofed <acronym>DNS</acronym> records. By using digital - signatures, a resolver can verify the integrity of the record. - Note that <acronym role="Domain Name Security - Extensions">DNSSEC</acronym> only provides integrity via - digitally signing the Resource Records (<acronym - role="Resource Record">RR</acronym>s). It provides neither - confidentiality nor protection against false end-user - assumptions. This means that it cannot protect against people - going to <systemitem - class="fqdomainname">example.net</systemitem> instead of - <systemitem class="fqdomainname">example.com</systemitem>. - The only thing <acronym>DNSSEC</acronym> does is authenticate - that the data has not been compromised in transit. The - security of <acronym>DNS</acronym> is an important step in - securing the Internet in general. For more in-depth details - of how <acronym>DNSSEC</acronym> works, the relevant - <acronym>RFC</acronym>s are a good place to start. See the - list in <xref linkend="dns-read"/>.</para> - - <para>The following sections will demonstrate how to enable - <acronym>DNSSEC</acronym> for an authoritative - <acronym>DNS</acronym> server and a recursive (or caching) - <acronym>DNS</acronym> server running <acronym>BIND</acronym> - 9. While all versions of <acronym>BIND</acronym> 9 support - <acronym>DNSSEC</acronym>, it is necessary to have at least - version 9.6.2 in order to be able to use the signed root zone - when validating <acronym>DNS</acronym> 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 - <acronym>BIND</acronym> 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.</para> - - <sect4> - <title>Recursive <acronym>DNS</acronym> Server - Configuration</title> - - <para>Enabling <acronym>DNSSEC</acronym> validation of queries - performed by a recursive <acronym>DNS</acronym> server - requires a few changes to <filename>named.conf</filename>. - 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 <acronym>BIND</acronym> - 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 <application>dig</application>. - By running</para> - - <screen>&prompt.user; <userinput>dig +multi +noall +answer DNSKEY . > root.dnskey</userinput></screen> - - <para>the key will end up in <filename>root.dnskey</filename>. - The contents should look something like this:</para> - - <programlisting>. 93910 IN DNSKEY 257 3 8 ( + <para>Domain Name System Security Extensions, or <acronym + role="Domain Name Security Extensions">DNSSEC</acronym> + for short, is a suite of specifications to protect resolving + name servers from forged <acronym>DNS</acronym> data, such + as spoofed <acronym>DNS</acronym> records. By using digital + signatures, a resolver can verify the integrity of the + record. Note that <acronym role="Domain Name Security + Extensions">DNSSEC</acronym> only provides integrity via + digitally signing the Resource Records (<acronym + role="Resource Record">RR</acronym>s). It provides + neither confidentiality nor protection against false + end-user assumptions. This means that it cannot protect + against people going to + <systemitem class="fqdomainname">example.net</systemitem> + instead of + <systemitem class="fqdomainname">example.com</systemitem>. + The only thing <acronym>DNSSEC</acronym> does is + authenticate that the data has not been compromised in + transit. The security of <acronym>DNS</acronym> is an + important step in securing the Internet in general. For + more in-depth details of how <acronym>DNSSEC</acronym> + works, the relevant <acronym>RFC</acronym>s are a good place + to start. See the list in + <xref linkend="dns-read"/>.</para> + + <para>The following sections will demonstrate how to enable + <acronym>DNSSEC</acronym> for an authoritative + <acronym>DNS</acronym> server and a recursive (or caching) + <acronym>DNS</acronym> server running + <acronym>BIND</acronym> 9. While all versions of + <acronym>BIND</acronym> 9 support <acronym>DNSSEC</acronym>, + it is necessary to have at least version 9.6.2 in order to + be able to use the signed root zone when validating + <acronym>DNS</acronym> 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 <acronym>BIND</acronym> 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.</para> + + <sect4> + <title>Recursive <acronym>DNS</acronym> Server + Configuration</title> + + <para>Enabling <acronym>DNSSEC</acronym> validation of + queries performed by a recursive <acronym>DNS</acronym> + server requires a few changes to + <filename>named.conf</filename>. 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 <acronym>BIND</acronym> 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 <application>dig</application>. By + running</para> + + <screen>&prompt.user; <userinput>dig +multi +noall +answer DNSKEY . > root.dnskey</userinput></screen> + + <para>the key will end up in + <filename>root.dnskey</filename>. The contents should + look something like this:</para> + + <programlisting>. 93910 IN DNSKEY 257 3 8 ( AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA @@ -4028,59 +4046,60 @@ mail IN A 192.168.1.5</programlisting> EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt ) ; key id = 34525</programlisting> - <para>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 - (<acronym role="Secure Entry Point">SEP</acronym>), commonly - known as a Key Signing Key - (<acronym role="Key Signing Key">KSK</acronym>). The second - key, with value 256, is a subordinate key, commonly called a - Zone Signing Key - (<acronym role="Zone Signing Key">ZSK</acronym>). More on - the different key types later in - <xref linkend="dns-dnssec-auth"/>.</para> - - <para>Now the key must be verified and formatted so that - <acronym>BIND</acronym> can use it. To verify the key, - generate a <acronym role="Delegation Signer">DS</acronym> - <acronym role="Resource Record">RR</acronym> set. Create a - file containing these - <acronym role="Resource Record">RR</acronym>s with</para> - - <screen>&prompt.user; <userinput>dnssec-dsfromkey -f root.dnskey . > root.ds</userinput></screen> - - <para>These records use SHA-1 and SHA-256 respectively, and - should look similar to the following example, where the - longer is using SHA-256.</para> - - <programlisting>. IN DS 19036 8 1 + <para>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 + (<acronym role="Secure Entry Point">SEP</acronym>), + commonly known as a Key Signing Key + (<acronym role="Key Signing Key">KSK</acronym>). The + second key, with value 256, is a subordinate key, commonly + called a Zone Signing Key + (<acronym role="Zone Signing Key">ZSK</acronym>). More on + the different key types later in + <xref linkend="dns-dnssec-auth"/>.</para> + + <para>Now the key must be verified and formatted so that + <acronym>BIND</acronym> can use it. To verify the key, + generate a <acronym role="Delegation Signer">DS</acronym> + <acronym role="Resource Record">RR</acronym> set. Create + a file containing these + <acronym role="Resource Record">RR</acronym>s with</para> + + <screen>&prompt.user; <userinput>dnssec-dsfromkey -f root.dnskey . > root.ds</userinput></screen> + + <para>These records use SHA-1 and SHA-256 respectively, and + should look similar to the following example, where the + longer is using SHA-256.</para> + + <programlisting>. IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</programlisting> - <para>The SHA-256 <acronym>RR</acronym> can now be compared to - the digest in <link - xlink:href="https://data.iana.org/root-anchors/root-anchors.xml">https://data.iana.org/root-anchors/root-anchors.xml</link>. - To be absolutely sure that the key has not been tampered - with the data in the <acronym>XML</acronym> file can be - verified using the <acronym>PGP</acronym> signature in - <link - xlink:href="https://data.iana.org/root-anchors/root-anchors.asc">https://data.iana.org/root-anchors/root-anchors.asc</link>.</para> - - <para>Next, the key must be formatted properly. This differs - a little between <acronym>BIND</acronym> 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 - <literal>managed-keys</literal> as seen in the example - below. When using the older version, the key is added using - a <literal>trusted-keys</literal> statement and updates must - be done manually. For <acronym>BIND</acronym> 9.6.2 the - format should look like:</para> - - <programlisting>trusted-keys { + <para>The SHA-256 <acronym>RR</acronym> can now be compared + to the digest in <link + xlink:href="https://data.iana.org/root-anchors/root-anchors.xml">https://data.iana.org/root-anchors/root-anchors.xml</link>. + To be absolutely sure that the key has not been tampered + with the data in the <acronym>XML</acronym> file can be + verified using the <acronym>PGP</acronym> signature in + <link + xlink:href="https://data.iana.org/root-anchors/root-anchors.asc">https://data.iana.org/root-anchors/root-anchors.asc</link>.</para> + + <para>Next, the key must be formatted properly. This + differs a little between <acronym>BIND</acronym> 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 + <literal>managed-keys</literal> as seen in the example + below. When using the older version, the key is added + using a <literal>trusted-keys</literal> statement and + updates must be done manually. For + <acronym>BIND</acronym> 9.6.2 the format should look + like:</para> + + <programlisting>trusted-keys { "." 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX @@ -4091,9 +4110,9 @@ mail IN A 192.168.1.5</programlisting> QxA+Uk1ihz0="; };</programlisting> - <para>For 9.7 the format will instead be:</para> + <para>For 9.7 the format will instead be:</para> - <programlisting>managed-keys { + <programlisting>managed-keys { "." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX @@ -4104,193 +4123,196 @@ mail IN A 192.168.1.5</programlisting> QxA+Uk1ihz0="; };</programlisting> - <para>The root key can now be added to - <filename>named.conf</filename> either directly or by - including a file containing the key. After these steps, - configure <acronym>BIND</acronym> to do - <acronym>DNSSEC</acronym> validation on queries by editing - <filename>named.conf</filename> and adding the following to - the <literal>options</literal> directive:</para> + <para>The root key can now be added to + <filename>named.conf</filename> either directly or by + including a file containing the key. After these steps, + configure <acronym>BIND</acronym> to do + <acronym>DNSSEC</acronym> validation on queries by editing + <filename>named.conf</filename> and adding the following + to the <literal>options</literal> directive:</para> - <programlisting>dnssec-enable yes; + <programlisting>dnssec-enable yes; dnssec-validation yes;</programlisting> - <para>To verify that it is actually working use - <application>dig</application> to make a query for a signed - zone using the resolver just configured. A successful reply - will contain the <literal>AD</literal> flag to indicate the - data was authenticated. Running a query such as</para> + <para>To verify that it is actually working use + <application>dig</application> to make a query for a + signed zone using the resolver just configured. A + successful reply will contain the <literal>AD</literal> + flag to indicate the data was authenticated. Running a + query such as</para> - <screen>&prompt.user; <userinput>dig @<replaceable>resolver</replaceable> +dnssec se ds </userinput></screen> + <screen>&prompt.user; <userinput>dig @<replaceable>resolver</replaceable> +dnssec se ds </userinput></screen> - <para>should return the <acronym>DS</acronym> - <acronym>RR</acronym> for the <literal>.se</literal> zone. - In the <literal>flags:</literal> section the - <literal>AD</literal> flag should be set, as seen - in:</para> + <para>should return the <acronym>DS</acronym> + <acronym>RR</acronym> for the <literal>.se</literal> zone. + In the <literal>flags:</literal> section the + <literal>AD</literal> flag should be set, as seen + in:</para> - <programlisting>... + <programlisting>... ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ...</programlisting> - <para>The resolver is now capable of authenticating - <acronym>DNS</acronym> queries.</para> - </sect4> - - <sect4 xml:id="dns-dnssec-auth"> - <title>Authoritative <acronym>DNS</acronym> Server - Configuration</title> - - <para>In order to get an authoritative name server to serve a - <acronym>DNSSEC</acronym> 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 - (<acronym role="Key Signing Key">KSK</acronym>) that is - not rotated very often and a Zone Signing Key - (<acronym role="Zone Signing Key">ZSK</acronym>) that is - rotated more frequently. Information on recommended - operational practices can be found in <link - xlink:href="http://tools.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym> - 4641: <acronym>DNSSEC</acronym> Operational - Practices</link>. Practices regarding the root zone can - be found in <link - xlink:href="http://www.root-dnssec.org/wp-content/uploads/2010/06/icann-dps-00.txt"><acronym>DNSSEC</acronym> - Practice Statement for the Root Zone - <acronym>KSK</acronym> operator</link> and <link - xlink:href="http://www.root-dnssec.org/wp-content/uploads/2010/06/vrsn-dps-00.txt"><acronym>DNSSEC</acronym> - Practice Statement for the Root Zone - <acronym>ZSK</acronym> operator</link>. The - <acronym role="Key Signing Key">KSK</acronym> 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 - (<acronym role="Secure Entry Point">SEP</acronym>) key. A - message digest of this key, called a Delegation Signer - (<acronym role="Delegation Signer">DS</acronym>) record, - must be published in the parent zone to establish the trust - chain. How this is accomplished depends on the parent zone - owner. The <acronym role="Zone Signing Key">ZSK</acronym> - is used to sign the zone, and only needs to be published - there.</para> - - <para>To enable <acronym>DNSSEC</acronym> for the <systemitem - class="fqdomainname">example.com</systemitem> zone - depicted in previous examples, the first step is to use - <application>dnssec-keygen</application> to generate the - <acronym>KSK</acronym> and <acronym>ZSK</acronym> 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 <acronym>KSK</acronym> for <systemitem - class="fqdomainname">example.com</systemitem>, run</para> - - <screen>&prompt.user; <userinput>dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen> - - <para>and to generate the <acronym>ZSK</acronym>, run</para> - - <screen>&prompt.user; <userinput>dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen> - - <para><application>dnssec-keygen</application> outputs two - files, the public and the private keys in files named - similar to <filename>Kexample.com.+005+nnnnn.key</filename> - (public) and - <filename>Kexample.com.+005+nnnnn.private</filename> - (private). The <literal>nnnnn</literal> 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 <acronym>KSK</acronym> file - do:</para> - - <screen>&prompt.user; <userinput>mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnnn.KSK.key</userinput> + <para>The resolver is now capable of authenticating + <acronym>DNS</acronym> queries.</para> + </sect4> + + <sect4 xml:id="dns-dnssec-auth"> + <title>Authoritative <acronym>DNS</acronym> Server + Configuration</title> + + <para>In order to get an authoritative name server to serve + a <acronym>DNSSEC</acronym> 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 + (<acronym role="Key Signing Key">KSK</acronym>) that is + not rotated very often and a Zone Signing Key + (<acronym role="Zone Signing Key">ZSK</acronym>) that is + rotated more frequently. Information on recommended + operational practices can be found in <link + xlink:href="http://tools.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym> + 4641: <acronym>DNSSEC</acronym> Operational + Practices</link>. Practices regarding the root zone can + be found in <link + xlink:href="http://www.root-dnssec.org/wp-content/uploads/2010/06/icann-dps-00.txt"><acronym>DNSSEC</acronym> + Practice Statement for the Root Zone + <acronym>KSK</acronym> operator</link> and <link + xlink:href="http://www.root-dnssec.org/wp-content/uploads/2010/06/vrsn-dps-00.txt"><acronym>DNSSEC</acronym> + Practice Statement for the Root Zone + <acronym>ZSK</acronym> operator</link>. The + <acronym role="Key Signing Key">KSK</acronym> 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 + (<acronym role="Secure Entry Point">SEP</acronym>) key. A + message digest of this key, called a Delegation Signer + (<acronym role="Delegation Signer">DS</acronym>) record, + must be published in the parent zone to establish the + trust chain. How this is accomplished depends on the + parent zone owner. The + <acronym role="Zone Signing Key">ZSK</acronym> is used to + sign the zone, and only needs to be published + there.</para> + + <para>To enable <acronym>DNSSEC</acronym> for the + <systemitem class="fqdomainname">example.com</systemitem> + zone depicted in previous examples, the first step is to + use <application>dnssec-keygen</application> to generate + the <acronym>KSK</acronym> and <acronym>ZSK</acronym> 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 <acronym>KSK</acronym> for + <systemitem class="fqdomainname">example.com</systemitem>, + run</para> + + <screen>&prompt.user; <userinput>dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen> + + <para>and to generate the <acronym>ZSK</acronym>, run</para> + + <screen>&prompt.user; <userinput>dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com</userinput></screen> + + <para><application>dnssec-keygen</application> outputs two + files, the public and the private keys in files named + similar to + <filename>Kexample.com.+005+nnnnn.key</filename> (public) + and <filename>Kexample.com.+005+nnnnn.private</filename> + (private). The <literal>nnnnn</literal> 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 <acronym>KSK</acronym> file + do:</para> + + <screen>&prompt.user; <userinput>mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnnn.KSK.key</userinput> &prompt.user; <userinput>mv Kexample.com.+005+nnnnn.private Kexample.com.+005+nnnnn.KSK.private</userinput></screen> - <para>For the <acronym>ZSK</acronym> files, substitute - <literal>KSK</literal> for <literal>ZSK</literal> as - necessary. The files can now be included in the zone file, - using the <literal>$include</literal> statement. It should - look something like this:</para> + <para>For the <acronym>ZSK</acronym> files, substitute + <literal>KSK</literal> for <literal>ZSK</literal> as + necessary. The files can now be included in the zone + file, using the <literal>$include</literal> statement. It + should look something like this:</para> - <programlisting>$include Kexample.com.+005+nnnnn.KSK.key ; KSK + <programlisting>$include Kexample.com.+005+nnnnn.KSK.key ; KSK $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting> - <para>Finally, sign the zone and tell <acronym>BIND</acronym> - to use the signed zone file. To sign a zone - <application>dnssec-signzone</application> is used. The - command to sign the zone <systemitem - class="fqdomainname">example.com</systemitem>, located in - <filename>example.com.db</filename> would look similar - to</para> + <para>Finally, sign the zone and tell + <acronym>BIND</acronym> to use the signed zone file. To + sign a zone <application>dnssec-signzone</application> is + used. The command to sign the zone + <systemitem class="fqdomainname">example.com</systemitem>, + located in <filename>example.com.db</filename> would look + similar to</para> - <screen>&prompt.user; <userinput>dnssec-signzone -o + <screen>&prompt.user; <userinput>dnssec-signzone -o example.com -k Kexample.com.+005+nnnnn.KSK example.com.db Kexample.com.+005+nnnnn.ZSK.key</userinput></screen> - <para>The key supplied to the <option>-k</option> argument is - the <acronym>KSK</acronym> and the other key file is the - <acronym>ZSK</acronym> that should be used in the signing. - It is possible to supply more than one - <acronym>KSK</acronym> and <acronym>ZSK</acronym>, 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 - <application>dnssec-signzone</application> is a zone file - with all <acronym>RR</acronym>s signed. This output will - end up in a file with the extension - <literal>.signed</literal>, such as - <filename>example.com.db.signed</filename>. The - <acronym role="Delegation Signer">DS</acronym> records will - also be written to a separate file - <filename>dsset-example.com</filename>. To use this signed - zone just modify the zone directive in - <filename>named.conf</filename> to use - <filename>example.com.db.signed</filename>. 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.</para> - - <para>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 - <acronym>DNS</acronym> data unavailable for a time, until - the new key has propagated through the - <acronym>DNS</acronym> hierarchy. For more information on - key rollovers and other <acronym>DNSSEC</acronym> - operational issues, see <link - xlink:href="http://www.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym> - 4641: <acronym>DNSSEC</acronym> Operational - practices</link>.</para> - </sect4> - - <sect4> - <title>Automation Using <acronym>BIND</acronym> 9.7 or - Later</title> - - <para>Beginning with <acronym>BIND</acronym> version 9.7 a new - feature called <emphasis>Smart Signing</emphasis> 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 - <emphasis>key repository</emphasis>, and using the new - option <literal>auto-dnssec</literal>, it is possible to - create a dynamic zone which will be resigned as needed. To - update this zone use <application>nsupdate</application> - with the new option <option>-l</option>. - <application>rndc</application> has also grown the ability - to sign zones with keys in the key repository, using the - option <option>sign</option>. To tell - <acronym>BIND</acronym> to use this automatic signing and - zone updating for <systemitem - class="fqdomainname">example.com</systemitem>, add the - following to <filename>named.conf</filename>:</para> - - <programlisting>zone example.com { + <para>The key supplied to the <option>-k</option> argument + is the <acronym>KSK</acronym> and the other key file is + the <acronym>ZSK</acronym> that should be used in the + signing. It is possible to supply more than one + <acronym>KSK</acronym> and <acronym>ZSK</acronym>, 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 + <application>dnssec-signzone</application> is a zone file + with all <acronym>RR</acronym>s signed. This output will + end up in a file with the extension + <literal>.signed</literal>, such as + <filename>example.com.db.signed</filename>. The + <acronym role="Delegation Signer">DS</acronym> records + will also be written to a separate file + <filename>dsset-example.com</filename>. To use this + signed zone just modify the zone directive in + <filename>named.conf</filename> to use + <filename>example.com.db.signed</filename>. 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.</para> + + <para>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 <acronym>DNS</acronym> data unavailable for a time, + until the new key has propagated through the + <acronym>DNS</acronym> hierarchy. For more information on + key rollovers and other <acronym>DNSSEC</acronym> + operational issues, see <link + xlink:href="http://www.ietf.org/rfc/rfc4641.txt"><acronym>RFC</acronym> + 4641: <acronym>DNSSEC</acronym> Operational + practices</link>.</para> + </sect4> + + <sect4> + <title>Automation Using <acronym>BIND</acronym> 9.7 or + Later</title> + + <para>Beginning with <acronym>BIND</acronym> version 9.7 a + new feature called <emphasis>Smart Signing</emphasis> 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 + <emphasis>key repository</emphasis>, and using the new + option <literal>auto-dnssec</literal>, it is possible to + create a dynamic zone which will be resigned as needed. + To update this zone use + <application>nsupdate</application> with the new option + <option>-l</option>. <application>rndc</application> has + also grown the ability to sign zones with keys in the key + repository, using the option <option>sign</option>. To + tell <acronym>BIND</acronym> to use this automatic signing + and zone updating for <systemitem + class="fqdomainname">example.com</systemitem>, add the + following to <filename>named.conf</filename>:</para> + + <programlisting>zone example.com { type master; key-directory "/etc/named/keys"; update-policy local; @@ -4298,147 +4320,149 @@ $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK</programlisting> file "/etc/named/dynamic/example.com.zone"; };</programlisting> - <para>After making these changes, generate keys for the zone - as explained in <xref linkend="dns-dnssec-auth"/>, put those - keys in the key repository given as the argument to the - <literal>key-directory</literal> in the zone configuration - and the zone will be signed automatically. Updates to a - zone configured this way must be done using - <application>nsupdate</application>, which will take care of - re-signing the zone with the new data added. For further - details, see <xref linkend="dns-read"/> and the - <acronym>BIND</acronym> documentation.</para> - </sect4> - </sect3> - - <sect3> - <title>Security</title> - - <para>Although BIND is the most common implementation of - <acronym>DNS</acronym>, there is always the issue of security. - Possible and exploitable security holes are sometimes - found.</para> - - <para>While &os; automatically drops - <application>named</application> into a &man.chroot.8; - environment; there are several other security mechanisms in - place which could help to lure off possible - <acronym>DNS</acronym> service attacks.</para> - - <para>It is always good idea to read - <link xlink:href="http://www.cert.org/">CERT</link>'s security - advisories and to subscribe to the &a.security-notifications; - to stay up to date with the current Internet and &os; security - issues.</para> - - <tip> - <para>If a problem arises, keeping sources up to date and - having a fresh build of <application>named</application> - may help.</para> - </tip> - </sect3> - - <sect3 xml:id="dns-read"> - <title>Further Reading</title> - - <para>BIND/<application>named</application> manual pages: - &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.1; - &man.dnssec-signzone.8; &man.dnssec-keygen.8;</para> + <para>After making these changes, generate keys for the zone + as explained in <xref linkend="dns-dnssec-auth"/>, put + those keys in the key repository given as the argument to + the <literal>key-directory</literal> in the zone + configuration and the zone will be signed automatically. + Updates to a zone configured this way must be done using + <application>nsupdate</application>, which will take care + of re-signing the zone with the new data added. For + further details, see <xref linkend="dns-read"/> and the + <acronym>BIND</acronym> documentation.</para> + </sect4> + </sect3> - <itemizedlist> - <listitem> - <para><link - xlink:href="https://www.isc.org/software/bind">Official - ISC BIND Page</link></para> - </listitem> + <sect3> + <title>Security</title> + + <para>Although BIND is the most common implementation of + <acronym>DNS</acronym>, there is always the issue of + security. Possible and exploitable security holes are + sometimes found.</para> + + <para>While &os; automatically drops + <application>named</application> into a &man.chroot.8; + environment; there are several other security mechanisms in + place which could help to lure off possible + <acronym>DNS</acronym> service attacks.</para> + + <para>It is always good idea to read + <link xlink:href="http://www.cert.org/">CERT</link>'s + security advisories and to subscribe to the + &a.security-notifications; to stay up to date with the + current Internet and &os; security issues.</para> + + <tip> + <para>If a problem arises, keeping sources up to date and + having a fresh build of <application>named</application> + may help.</para> + </tip> + </sect3> - <listitem> - <para><link - xlink:href="https://www.isc.org/software/guild">Official - ISC BIND Forum</link></para> - </listitem> + <sect3 xml:id="dns-read"> + <title>Further Reading</title> - <listitem> - <para><link - xlink:href="http://www.oreilly.com/catalog/dns5/">O'Reilly - <acronym>DNS</acronym> and BIND 5th - Edition</link></para> - </listitem> + <para>BIND/<application>named</application> manual pages: + &man.rndc.8; &man.named.8; &man.named.conf.5; + &man.nsupdate.1; &man.dnssec-signzone.8; + &man.dnssec-keygen.8;</para> - <listitem> - <para><link - xlink:href="http://www.root-dnssec.org/documentation/">Root - <acronym>DNSSEC</acronym></link></para> - </listitem> + <itemizedlist> + <listitem> + <para><link + xlink:href="https://www.isc.org/software/bind">Official + ISC BIND Page</link></para> + </listitem> - <listitem> - <para><link - xlink:href="http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html"><acronym>DNSSEC</acronym> - Trust Anchor Publication for the Root - Zone</link></para> - </listitem> + <listitem> + <para><link + xlink:href="https://www.isc.org/software/guild">Official + ISC BIND Forum</link></para> + </listitem> - <listitem> - <para><link - xlink:href="http://tools.ietf.org/html/rfc1034">RFC1034 - - Domain Names - Concepts and Facilities</link></para> - </listitem> + <listitem> + <para><link + xlink:href="http://www.oreilly.com/catalog/dns5/">O'Reilly + <acronym>DNS</acronym> and BIND 5th + Edition</link></para> + </listitem> - <listitem> - <para><link - xlink:href="http://tools.ietf.org/html/rfc1035">RFC1035 - - Domain Names - Implementation and - Specification</link></para> - </listitem> + <listitem> + <para><link + xlink:href="http://www.root-dnssec.org/documentation/">Root + <acronym>DNSSEC</acronym></link></para> + </listitem> - <listitem> - <para><link - xlink:href="http://tools.ietf.org/html/rfc4033">RFC4033 - - <acronym>DNS</acronym> Security Introduction and - Requirements</link></para> - </listitem> + <listitem> + <para><link + xlink:href="http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html"><acronym>DNSSEC</acronym> + Trust Anchor Publication for the Root + Zone</link></para> + </listitem> - <listitem> - <para><link - xlink:href="http://tools.ietf.org/html/rfc4034">RFC4034 - - Resource Records for the <acronym>DNS</acronym> - Security Extensions</link></para> - </listitem> + <listitem> + <para><link + xlink:href="http://tools.ietf.org/html/rfc1034">RFC1034 + - Domain Names - Concepts and Facilities</link></para> + </listitem> - <listitem> - <para><link - xlink:href="http://tools.ietf.org/html/rfc4035">RFC4035 - - Protocol Modifications for the <acronym>DNS</acronym> - Security Extensions</link></para> - </listitem> + <listitem> + <para><link + xlink:href="http://tools.ietf.org/html/rfc1035">RFC1035 + - Domain Names - Implementation and + Specification</link></para> + </listitem> - <listitem> - <para><link - xlink:href="http://tools.ietf.org/html/rfc4641">RFC4641 - - DNSSEC Operational Practices</link></para> - </listitem> + <listitem> + <para><link + xlink:href="http://tools.ietf.org/html/rfc4033">RFC4033 + - <acronym>DNS</acronym> Security Introduction and + Requirements</link></para> + </listitem> - <listitem> - <para><link - xlink:href="http://tools.ietf.org/html/rfc5011">RFC 5011 - - Automated Updates of <acronym>DNS</acronym> Security - (<acronym>DNSSEC</acronym> - Trust Anchors</link></para> - </listitem> - </itemizedlist> - </sect3> + <listitem> + <para><link + xlink:href="http://tools.ietf.org/html/rfc4034">RFC4034 + - Resource Records for the <acronym>DNS</acronym> + Security Extensions</link></para> + </listitem> + + <listitem> + <para><link + xlink:href="http://tools.ietf.org/html/rfc4035">RFC4035 + - Protocol Modifications for the + <acronym>DNS</acronym> Security + Extensions</link></para> + </listitem> + + <listitem> + <para><link + xlink:href="http://tools.ietf.org/html/rfc4641">RFC4641 + - DNSSEC Operational Practices</link></para> + </listitem> + + <listitem> + <para><link + xlink:href="http://tools.ietf.org/html/rfc5011">RFC + 5011 - Automated Updates of <acronym>DNS</acronym> + Security (<acronym>DNSSEC</acronym> + Trust Anchors</link></para> + </listitem> + </itemizedlist> + </sect3> </sect2> </sect1> <sect1 xml:id="network-apache"> <info> - <title>Apache HTTP Server</title> + <title>Apache HTTP Server</title> <authorgroup> <author> - <personname> - <firstname>Murray</firstname> - <surname>Stokely</surname> + <personname> + <firstname>Murray</firstname> + <surname>Stokely</surname> </personname> <contrib>Contributed by </contrib> </author> @@ -4701,14 +4725,14 @@ DocumentRoot <replaceable>/www/someotherdomain.tld</replaceable> <sect3> <info> - <title><filename>mod_php</filename></title> + <title><filename>mod_php</filename></title> <authorgroup> <author> - <personname> - <firstname>Tom</firstname> - <surname>Rhodes</surname> - </personname> + <personname> + <firstname>Tom</firstname> + <surname>Rhodes</surname> + </personname> <contrib>Written by </contrib> </author> </authorgroup> @@ -4835,7 +4859,7 @@ AddModule mod_php5.c <filename>httpd.conf</filename>, specifying the full path to the project directory:</para> - <screen><Location "/"> + <screen><Location "/"> SetHandler python-program PythonPath "['<replaceable>/dir/to/the/django/packages/</replaceable>'] + sys.path" PythonHandler django.core.handlers.modpython |