From owner-svn-doc-head@FreeBSD.ORG Fri Aug 9 21:49:13 2013 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DD111504; Fri, 9 Aug 2013 21:49:13 +0000 (UTC) (envelope-from wblock@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C8B1624EF; Fri, 9 Aug 2013 21:49:13 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r79LnDQ1040825; Fri, 9 Aug 2013 21:49:13 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r79LnD6X040824; Fri, 9 Aug 2013 21:49:13 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201308092149.r79LnD6X040824@svn.freebsd.org> From: Warren Block Date: Fri, 9 Aug 2013 21:49:13 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r42526 - head/en_US.ISO8859-1/books/handbook/network-servers X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:49:13 -0000 Author: wblock Date: Fri Aug 9 21:49:13 2013 New Revision: 42526 URL: http://svnweb.freebsd.org/changeset/doc/42526 Log: Whitespace-only fixes. Translators, please ignore. Modified: head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Fri Aug 9 20:37:45 2013 (r42525) +++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Fri Aug 9 21:49:13 2013 (r42526) @@ -32,7 +32,6 @@ By the end of this chapter, readers will know: - How to manage the inetd daemon. @@ -90,7 +89,6 @@ syslogd, to accept logs from remote hosts. - This chapter assumes a basic knowledge of: @@ -108,7 +106,6 @@ Installation of additional third-party software (). - @@ -164,15 +161,13 @@ Settings inetd is initialized through - the &man.rc.8; system. The - inetd_enable option is set to - NO by default. It can be enabled - by placing: + the &man.rc.8; system. The inetd_enable + option is set to NO by default. It can be + enabled by placing: inetd_enable="YES" - into - /etc/rc.conf. + into /etc/rc.conf. inetd will now start at boot time. The command: @@ -291,8 +286,8 @@ user[:group][/login-class] server-program server-program-arguments - An example entry for the &man.ftpd.8; daemon - using IPv4 might read: + An example entry for the &man.ftpd.8; daemon using IPv4 + might read: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l @@ -338,6 +333,7 @@ server-program-argumentsExplanation + tcp, tcp4 @@ -423,15 +419,15 @@ server-program-argumentsA stream-type multi-threaded daemon without any , or - limits - would simply be: nowait. + limits would simply + be: nowait. The same daemon with a maximum limit of ten daemons would read: nowait/10. - The same setup with a limit of twenty - connections per IP address per minute and a maximum - total limit of ten child daemons would read: + The same setup with a limit of twenty connections + per IP address per minute and a maximum total limit of + ten child daemons would read: nowait/10/20. These options are utilized by the default @@ -498,22 +494,22 @@ server-program-arguments# in front of the daemon in question in - /etc/inetd.conf, and then reload the - inetd configuration. Some daemons, such as + /etc/inetd.conf, and then + reload the + inetd configuration. Some daemons, such as fingerd, may not be desired at all - because they provide - information that may be useful to an attacker. + because they provide information that may be useful to an + attacker. Some daemons are not security-conscious and have long or non-existent timeouts for connection attempts. An attacker can send connections to a particular daemon, eventually - consuming available resources and resulting in a Denial of + consuming available resources and resulting in a Denial of Service (DoS). max-connections-per-ip-per-minute, max-child and - max-child-per-ip can be used to limit - such attacks. + max-child-per-ip can be used to limit such + attacks. By default, TCP wrapping is turned on. Consult the &man.hosts.access.5; manual page for more information on @@ -533,9 +529,8 @@ server-program-argumentsinetd. The auth service provides - identity network services, and is - configurable to a certain degree, whilst the others are simply - on or off. + identity network services, and is configurable to a certain + degree, whilst the others are simply on or off. Consult the &man.inetd.8; manual page for more in-depth information. @@ -636,6 +631,7 @@ server-program-argumentsDescription + nfsd @@ -718,10 +714,10 @@ mountd_flags="-r" export examples - The following examples give an idea of how to export - file systems, although the settings may be different depending - on the environment and network configuration. For instance, - to export the /cdrom directory to three + The following examples give an idea of how to export file + systems, although the settings may be different depending on + the environment and network configuration. For instance, to + export the /cdrom directory to three example machines that have the same domain name as the server (hence the lack of a domain name for each) or have entries in the /etc/hosts file. The @@ -826,8 +822,8 @@ mountd_flags="-r" Now everything should be ready to actually mount a remote file system. In these examples the server's name will be server and the client's name will be - client. For testing or to temporarily - mount a remote file system execute a command like this as + client. For testing or to temporarily mount + a remote file system execute a command like this as root on the client: @@ -842,8 +838,8 @@ mountd_flags="-r" visible and available in the /mnt directory. - To permanently mount a remote file system - each time the computer boots, add the file system to the + To permanently mount a remote file system each time the + computer boots, add the file system to the /etc/fstab file. Here is an example: @@ -940,12 +936,11 @@ rpc_statd_enable="YES" automatic mounter daemon - &man.amd.8; (the automatic mounter daemon) - automatically mounts a - remote file system whenever a file or directory within that - file system is accessed. Filesystems that are inactive for a - period of time will also be automatically unmounted by - amd. Using + &man.amd.8; (the automatic mounter daemon) automatically + mounts a remote file system whenever a file or directory + within that file system is accessed. Filesystems that are + inactive for a period of time will also be automatically + unmounted by amd. Using amd provides a simple alternative to permanent mounts, as permanent mounts are usually listed in /etc/fstab. @@ -957,8 +952,8 @@ rpc_statd_enable="YES" amd looks up the corresponding remote mount and automatically mounts it. /net is used to mount an exported file - system from an IP address, while /host - is used to mount an export from a remote hostname. + system from an IP address, while /host is + used to mount an export from a remote hostname. An access to a file within /host/foobar/usr would tell @@ -971,9 +966,8 @@ rpc_statd_enable="YES" amd The showmount command shows the - available mounts on a remote host. For example, to - view the mounts of a host named - foobar: + available mounts on a remote host. For example, to view the + mounts of a host named foobar: &prompt.user; showmount -e foobar Exports list on foobar: @@ -1208,10 +1202,10 @@ Exports list on foobar: <acronym>NIS</acronym>Terms and Processes - There are several terms and important user - processes that will be explained while attempting to - implement NIS on FreeBSD, regardless if the system is a - NIS server or a NIS client: + There are several terms and important user processes that + will be explained while attempting to implement NIS on + FreeBSD, regardless if the system is a NIS server or a NIS + client: rpcbind @@ -1231,6 +1225,7 @@ Exports list on foobar: Description + NIS domainname @@ -1296,7 +1291,6 @@ Exports list on foobar: - @@ -1380,15 +1374,14 @@ Exports list on foobar: Planning Let us assume that an administrator of a small - university lab, which consists of 15 FreeBSD - machines, currently has no centralized point of - administration. Each machine has its own - /etc/passwd and + university lab, which consists of 15 FreeBSD machines, + currently has no centralized point of administration. Each + machine has its own /etc/passwd and /etc/master.passwd. These files are kept in sync with each other only through manual intervention; currently, a user is added to the lab, the - process must be ran on all 15 machines. - The lab would clearly benefit from the addition of two + process must be ran on all 15 machines. The lab would + clearly benefit from the addition of two NIS servers. Therefore, the configuration of the lab now looks @@ -1403,6 +1396,7 @@ Exports list on foobar: Machine role + ellington @@ -1807,15 +1801,15 @@ Remember to update map ypservers on elli NIS client configuration - Setting up a FreeBSD machine to be a NIS - client is fairly straightforward. + Setting up a FreeBSD machine to be a NIS client is + fairly straightforward. - Edit /etc/rc.conf - and add the following lines in order to set the NIS - domainname and start ypbind during - network startup: + Edit /etc/rc.conf and add the + following lines in order to set the NIS domainname and + start ypbind during network + startup: nisdomainname="test-domain" nis_client_enable="YES" @@ -1835,10 +1829,9 @@ nis_client_enable="YES" account in the NIS server's password maps an account. There are many ways to configure the NIS client by changing this line. See the - netgroups - section below for more information. For more - detailed reading see O'Reilly's book on + netgroups + section below for more information. For + more detailed reading see O'Reilly's book on Managing NFS and NIS. @@ -1948,13 +1941,13 @@ nis_client_enable="YES" TCP Wrappers The use of TCP Wrapper - increases the latency of the NIS server. The - additional delay may be long enough to cause timeouts in - client programs, especially in busy networks or with slow - NIS servers. If one or more of the client systems - suffers from these symptoms, convert the client - systems in question into NIS slave servers and force them - to bind to themselves. + increases the latency of the NIS server. The additional + delay may be long enough to cause timeouts in client + programs, especially in busy networks or with slow NIS + servers. If one or more of the client systems suffers from + these symptoms, convert the client systems in question into + NIS slave servers and force them to bind to + themselves. @@ -1972,19 +1965,18 @@ nis_client_enable="YES" machine, even if they are present in the NIS database. To do this, add -username with - the correct number of colons like other entries to the - end of the /etc/master.passwd file on the - client machine, where username is - the username of the user to bar from logging in. - The line with the blocked user must be before the - + line for allowing NIS users. - This should preferably be done using vipw, - since vipw will sanity check the changes - to /etc/master.passwd, as well as - automatically rebuild the password database after - editing. For example, to bar user - bill from logging on to - basie: + the correct number of colons like other entries to the end of + the /etc/master.passwd file on the client + machine, where username is the + username of the user to bar from logging in. The line with + the blocked user must be before the + line + for allowing NIS users. This should preferably be done using + vipw, since vipw will + sanity check the changes to + /etc/master.passwd, as well as + automatically rebuild the password database after editing. + For example, to bar user bill from + logging on to basie: basie&prompt.root; vipw [add -bill::::::::: to the end, exit] @@ -2033,10 +2025,9 @@ basie&prompt.root; well for special rules in an environment with small numbers of users and/or machines. On larger networks, administrators will likely forget to bar some users from - logging onto sensitive machines, or may even have to - modify each machine separately, thus losing the main benefit - of NIS: centralized - administration. + logging onto sensitive machines, or may even have to modify + each machine separately, thus losing the main benefit of NIS: + centralized administration. The NIS developers' solution for this problem is called netgroups. Their purpose and semantics @@ -2047,18 +2038,16 @@ basie&prompt.root; Netgroups were developed to handle large, complex networks with hundreds of users and machines. On one hand, this is a - Good Thing in such a situation. - On the other hand, this complexity makes it almost impossible - to explain netgroups with really simple examples. The example - used in the remainder of this section demonstrates this - problem. + Good Thing in such a situation. On the other hand, this + complexity makes it almost impossible to explain netgroups + with really simple examples. The example used in the + remainder of this section demonstrates this problem. Let us assume that the successful introduction of NIS in - the laboratory caught a superiors' interest. The next - task is to extend the NIS domain to cover some of the other - machines on campus. The two tables contain the names of the - new users and new machines as well as brief descriptions of - them. + the laboratory caught a superiors' interest. The next task is + to extend the NIS domain to cover some of the other machines + on campus. The two tables contain the names of the new users + and new machines as well as brief descriptions of them. @@ -2159,21 +2148,21 @@ basie&prompt.root; Handling this situation with netgroups offers several advantages. Each user need not be handled separately; they - would be assigned to one or more netgroups and logins would - be allowed or forbidden for all members of the netgroup. - While adding a new - machine, login restrictions must be defined for all - netgroups. If a new user is added, they must be added - to one or more netgroups. Those changes are - independent of each other: no more for each combination - of user and machine do... If the NIS setup is planned - carefully, only one central configuration file - needs modification to grant or deny access to machines. + would be assigned to one or more netgroups and logins would be + allowed or forbidden for all members of the netgroup. While + adding a new machine, login restrictions must be defined for + all netgroups. If a new user is added, they must be added to + one or more netgroups. Those changes are independent of each + other: no more + for each combination of user and machine do... + If the NIS setup is planned carefully, only one central + configuration file needs modification to grant or deny access + to machines. The first step is the initialization of the NIS map - netgroup. &os;'s &man.ypinit.8; does not create this map - by default, but its NIS implementation will support it - after creation. To create an empty map, simply type + netgroup. &os;'s &man.ypinit.8; does not create this map by + default, but its NIS implementation will support it after + creation. To create an empty map, simply type ellington&prompt.root; vi /var/yp/netgroup @@ -2195,10 +2184,9 @@ INTERNS (,able,test-domain) (,baker, The name of the host(s) where the following items are - valid. If a hostname is not specified, the entry is - valid on all hosts. If a hostname is specified, it - will need to be micro-managed within this - configuration. + valid. If a hostname is not specified, the entry is valid + on all hosts. If a hostname is specified, it will need to + be micro-managed within this configuration. @@ -2218,11 +2206,11 @@ INTERNS (,able,test-domain) (,baker, netgroups Netgroup names longer than 8 characters should not be - used, especially with machines running other - operating systems within the NIS domain. The names are - case sensitive; using capital letters for netgroup - names is an easy way to distinguish between user, machine - and netgroup names. + used, especially with machines running other operating + systems within the NIS domain. The names are case + sensitive; using capital letters for netgroup names is an + easy way to distinguish between user, machine and netgroup + names. Some NIS clients (other than &os;) cannot handle netgroups with a large number of entries. For example, some @@ -2237,8 +2225,8 @@ BIGGRP2 (,joe16,domain) (,joe17,domain BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 - Repeat this process if more than 225 - users will exist within a single netgroup. + Repeat this process if more than 225 users will exist + within a single netgroup. Activating and distributing the new NIS map is @@ -2260,12 +2248,12 @@ ellington&prompt.user; ypcat The output of the first command should resemble the contents of /var/yp/netgroup. The second command will not produce output without specified - host-specific netgroups. The third command may be used to - get the list of netgroups for a user. + host-specific netgroups. The third command may be used to get + the list of netgroups for a user. The client setup is quite simple. To configure the server - war, use - &man.vipw.8; to replace the line + war, use &man.vipw.8; to replace the + line +::::::::: @@ -2275,19 +2263,19 @@ ellington&prompt.user; ypcat Now, only the data for the users defined in the netgroup IT_EMP is imported into - war's password database and only - these users are allowed to login. + war's password database and only these users + are allowed to login. Unfortunately, this limitation also applies to the ~ function of the shell and all routines converting between user names and numerical user IDs. In - other words, cd - ~user will not work, - ls -l will show the numerical ID instead of - the username and find . -user joe -print - will fail with No such user. To fix - this, import all user entries - without allowing them to login into the + other words, + cd ~user will + not work, ls -l will show the numerical ID + instead of the username and + find . -user joe -print will fail with + No such user. To fix this, import all + user entries without allowing them to login into the servers. This can be achieved by adding another line to @@ -2333,11 +2321,11 @@ ellington&prompt.user; ypcat change a few weeks later: The IT department starts hiring interns. The IT interns are allowed to use the normal workstations and the less important servers; and the IT - apprentices are allowed to login onto the main servers. - Add a new netgroup IT_INTERN, then add the - new IT interns to this netgroup and start to change the - configuration on each and every machine. As the old saying - goes: Errors in centralized planning lead to global + apprentices are allowed to login onto the main servers. Add a + new netgroup IT_INTERN, then add the new IT + interns to this netgroup and start to change the configuration + on each and every machine. As the old saying goes: + Errors in centralized planning lead to global mess. NIS' ability to create netgroups from other netgroups can @@ -2347,11 +2335,10 @@ ellington&prompt.user; ypcat the login restrictions for the important servers, another netgroup called SMALLSRV for the less important servers and a third netgroup called - USERBOX for the normal - workstations. Each of these netgroups contains the netgroups - that are allowed to login onto these machines. The new - entries for the NIS map netgroup should look like - this: + USERBOX for the normal workstations. Each + of these netgroups contains the netgroups that are allowed to + login onto these machines. The new entries for the NIS map + netgroup should look like this: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN @@ -2378,12 +2365,12 @@ USERBOX IT_EMP ITINTERN USERS+@BOXNAME::::::::: +:::::::::/sbin/nologin - Once this task is completed on all the machines, - there is no longer a need to modify the local versions of + Once this task is completed on all the machines, there is + no longer a need to modify the local versions of /etc/master.passwd ever again. All further changes can be handled by modifying the NIS map. Here - is an example of a possible netgroup map for this - scenario with some additional goodies: + is an example of a possible netgroup map for this scenario + with some additional goodies: # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) @@ -2443,8 +2430,8 @@ TWO (,hotel,test-domain) - Every time a new user is added to the lab, they - must be added to the master NIS server and the + Every time a new user is added to the lab, they must + be added to the master NIS server and the NIS maps will need rebuilt. If this step is omitted, the new user will not be able to login anywhere except on the NIS master. For example, if we @@ -2458,8 +2445,8 @@ TWO (,hotel,test-domain) The user may also be added using adduser jsmith instead of pw useradd jsmith. - + Keep the administration accounts out of the NIS maps. This is undesirable as it will @@ -2468,6 +2455,7 @@ TWO (,hotel,test-domain) machines will have users whom should not have access to those accounts. + Keep the NIS master and slave secure, and minimize their downtime. If somebody either @@ -2570,30 +2558,32 @@ nis_client_flags="-S NIS do &prompt.root; cap_mkdb /etc/login.conf - The format of passwords already in - /etc/master.passwd will not be updated - until a user changes his password for the first time - after the login capability database is - rebuilt. + + The format of passwords already in + /etc/master.passwd will not be updated + until a user changes his password for the first time + after the login capability database is + rebuilt. + Next, in order to ensure that passwords are encrypted with - the chosen format, check that - the crypt_default in + the chosen format, check that the + crypt_default in /etc/auth.conf gives precedence to the chosen password format. To do this, place the chosen format - first in the list. For example, when using DES - encrypted passwords, the entry would be: + first in the list. For example, when using DES encrypted + passwords, the entry would be: crypt_default = des blf md5 Having followed the above steps on each of the &os; based - NIS servers and clients, verify that they all agree - on which password format is used within the network. If users - have trouble authenticating on an NIS client, this is a pretty - good place to start looking for possible problems. Remember: - to deploy an NIS server for a heterogeneous - network, they will probably have to use DES on all systems - because it is the lowest common standard. + NIS servers and clients, verify that they all agree on which + password format is used within the network. If users have + trouble authenticating on an NIS client, this is a pretty good + place to start looking for possible problems. Remember: to + deploy an NIS server for a heterogeneous network, they will + probably have to use DES on all systems because it is the + lowest common standard. @@ -2840,8 +2830,8 @@ rootpw {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g Finally, enable the OpenLDAP service in rc.conf. At this time, setting up a URI and providing the group - and user to run as may be useful. - Edit /etc/rc.conf and add the following + and user to run as may be useful. Edit + /etc/rc.conf and add the following lines: slapd_enable="YES" @@ -3133,10 +3123,10 @@ dhclient_flags="" server The DHCP server, dhcpd, is - included as part of the net/isc-dhcp42-server port in - the ports collection. This port contains the ISC DHCP - server and documentation. + included as part of the + net/isc-dhcp42-server + port in the ports collection. This port contains the ISC + DHCP server and documentation. @@ -3188,7 +3178,7 @@ dhclient_flags="" The DHCP protocol is fully described in RFC - 2131. An informational resource has also been set + 2131. An informational resource has also been set up at . @@ -3654,16 +3644,15 @@ dhcpd_ifaces="dc0" - When one queries for www.FreeBSD.org, the resolver usually - queries the uplink ISP's name server, and - retrieves the reply. With a local, caching + When one queries for + www.FreeBSD.org, the resolver + usually queries the uplink ISP's name + server, and retrieves the reply. With a local, caching DNS server, the query only has to be made once to the outside world by the caching DNS server. Additional queries will not have to go outside the local network, since the information is - cached - locally. + cached locally. @@ -3708,14 +3697,14 @@ dhcpd_ifaces="dc0" Depending on how a given zone is configured on the server, - the files related to that zone can be found in the master, slave, or dynamic subdirectories of the - /etc/namedb directory. - These files contain the DNS information - that will be given out by the name server in response to - queries. + the files related to that zone can be found in the + master, + slave, or + dynamic subdirectories + of the /etc/namedb + directory. These files contain the DNS + information that will be given out by the name server in + response to queries. @@ -3731,10 +3720,10 @@ dhcpd_ifaces="dc0" The default named 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: + &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: &prompt.root; service named onestart @@ -3747,12 +3736,11 @@ dhcpd_ifaces="dc0" There are obviously many configuration options for /etc/namedb/named.conf that are beyond the scope of this document. There are other startup options - for named on - &os;, take a look at the - named_* flags in - /etc/defaults/rc.conf and consult the - &man.rc.conf.5; manual page. The section is also a good + for named on &os;, take a look at + the named_* + flags in /etc/defaults/rc.conf and + consult the &man.rc.conf.5; manual page. The + section is also a good read. @@ -3765,11 +3753,11 @@ dhcpd_ifaces="dc0" Configuration files for named - currently reside in /etc/namedb 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. + currently reside in + /etc/namedb 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. <filename>/etc/namedb/named.conf</filename> @@ -4128,10 +4116,10 @@ zone "1.168.192.in-addr.arpa" { zone files - An example master zone file for example.org (existing within - /etc/namedb/master/example.org) is as - follows: + An example master zone file for + example.org (existing + within /etc/namedb/master/example.org) + is as follows: $TTL 3600 ; 1 hour default TTL example.org. IN SOA ns1.example.org. admin.example.org. ( @@ -4296,21 +4284,21 @@ mail IN A 192.168. IN A 192.168.1.1 - This line assigns IP address 192.168.1.1 to the current origin, - in this case example.org. + This line assigns IP address + 192.168.1.1 to the current + origin, in this case + example.org. www IN CNAME @ The canonical name record is usually used for giving aliases to a machine. In the example, www is aliased to the master machine whose name - happens to be the same as the domain name example.org (192.168.1.1). CNAMEs can never be - used together with another kind of record - for the same hostname. + happens to be the same as the domain name + example.org + (192.168.1.1). CNAMEs can + never be used together with another kind of record for the + same hostname. MX record @@ -4318,11 +4306,11 @@ mail IN A 192.168. IN MX 10 mail.example.org. - The MX record indicates which mail - servers are responsible for handling incoming mail for the - zone. mail.example.org is the - hostname of a mail server, and 10 is the priority of - that mail server. + The MX record indicates which mail servers are + responsible for handling incoming mail for the zone. + mail.example.org is the + hostname of a mail server, and 10 is the priority of that + mail server. One can have several mail servers, with priorities of 10, 20 and so on. A mail server attempting to deliver to @@ -4466,22 +4454,22 @@ mail IN A 192.168. 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 . + 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 + . 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 + file containing these + RRs with &prompt.user; dnssec-dsfromkey -f root-dnskey . > root.ds @@ -4579,12 +4567,12 @@ dnssec-validation yes; 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 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 @@ -4594,29 +4582,29 @@ dnssec-validation yes; 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 + 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 + the KSK for + example.com, run &prompt.user; dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com @@ -4632,9 +4620,9 @@ dnssec-validation yes; (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: + 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 @@ -4651,8 +4639,8 @@ $include Kexample.com.+005+nnnnn.ZSK.key 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 + command to sign the zone + example.com, located in example.com.db would look similar to @@ -4672,11 +4660,11 @@ $include Kexample.com.+005+nnnnn.ZSK.key 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 + 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 @@ -4709,19 +4697,19 @@ $include Kexample.com.+005+nnnnn.ZSK.key 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 *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***