1.. Copyright (C) Internet Systems Consortium, Inc. ("ISC") 2.. 3.. SPDX-License-Identifier: MPL-2.0 4.. 5.. This Source Code Form is subject to the terms of the Mozilla Public 6.. License, v. 2.0. If a copy of the MPL was not distributed with this 7.. file, you can obtain one at https://mozilla.org/MPL/2.0/. 8.. 9.. See the COPYRIGHT file distributed with this work for additional 10.. information regarding copyright ownership. 11 12.. _config_auth_samples: 13 14Authoritative Name Servers 15-------------------------- 16 17These provide authoritative answers to user queries for the zones 18they support: for instance, the zone data describing the domain name **example.com**. An 19authoritative name server may support one or many zones. 20 21Each zone may be defined as either a **primary** or a **secondary**. A primary zone 22reads its zone data directly from a file system. A secondary zone obtains its zone 23data from the primary zone using a process called **zone transfer**. Both the primary 24and the secondary zones provide authoritative data for their zone; there is no difference 25in the answer to a query from a primary or a secondary zone. An authoritative name server 26may support any combination of primary and secondary zones. 27 28.. Note:: The terms **primary** and **secondary** do not imply any access 29 priority. Resolvers (name servers that provide the complete answers to user 30 queries) are not aware of (and cannot find out) whether an authoritative 31 answer comes from the primary or secondary name server. Instead, the 32 resolver uses the list of authoritative servers for the zone (there must be 33 at least two) and maintains a Round Trip Time (RTT) - the time taken to 34 respond to the query - for each server in the list. The resolver uses the 35 lowest-value server (the fastest) as its preferred server for the zone and 36 continues to do so until its RTT becomes higher than the next slowest in its 37 list, at which time that one becomes the preferred server. 38 39 For reasons of backward compatibility BIND 9 treats "primary" and "master" as 40 synonyms, as well as "secondary" and "slave." 41 42The following diagram shows the relationship between the primary and secondary 43name servers. The text below explains the process in detail. 44 45.. figure:: primary-secondary.png 46 :align: center 47 48 Authoritative Primary and Secondary Name Servers 49 50The numbers in parentheses in the following text refer to the numbered items in the diagram above. 51 521. The authoritative primary name server always loads (or reloads) its zone 53 files from (1) a local or networked filestore. 54 552. The authoritative secondary name server always loads its zone data from a 56 primary via a **zone transfer** operation. Zone transfer may use **AXFR** 57 (complete zone transfer) or **IXFR** (incremental zone transfer), but only 58 if both primary and secondary name servers support the service. The zone 59 transfer process (either AXFR or IXFR) works as follows: 60 61 a) The secondary name server for the zone reads (3 and 4) the 62 :ref:`SOA RR<soa_rr>` periodically. The interval is defined by the **refresh** 63 parameter of the Start of Authority (SOA) RR. 64 65 b) The secondary compares the **serial number** parameter of the SOA RR 66 received from the primary with the serial number in the SOA RR of its 67 current zone data. 68 69 c) If the received serial number is arithmetically greater (higher) than the 70 current one, the secondary initiates a zone transfer (5) using AXFR or IXFR 71 (depending on the primary and secondary configuration), using TCP over 72 port 53 (6). 73 743. The typically recommended zone refresh times for the SOA RR (the time 75 interval when the secondary reads or polls the primary for the zone SOA RR) 76 are multiples of hours to reduce traffic loads. Worst-case zone change 77 propagation can therefore take extended periods. 78 794. The optional NOTIFY (:rfc:`1996`) feature (2) is automatically configured; 80 use the :namedconf:ref:`notify` statement to turn off the feature. 81 Whenever the primary loads or reloads a zone, it sends a NOTIFY message to 82 the configured secondary (or secondaries) and may optionally be configured 83 to send the NOTIFY message to other hosts using the 84 :any:`also-notify` statement. The NOTIFY message simply 85 indicates to the secondary that the primary has loaded or reloaded the zone. 86 On receipt of the NOTIFY message, the secondary respons to indicate it has received the NOTIFY and immediately reads the SOA RR 87 from the primary (as described in section 2 a. above). If the zone file has 88 changed, propagation is practically immediate. 89 90The authoritative samples all use NOTIFY but identify the statements used, so 91that they can be removed if not required. 92 93.. _sample_primary: 94 95Primary Authoritative Name Server 96~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 97 98The zone files are unmodified :ref:`from the base samples<base_zone_file>` but 99the :iscman:`named.conf` file has been modified as shown: 100 101.. code-block:: c 102 103 // authoritative primary named.conf file 104 // options clause defining the server-wide properties 105 options { 106 // all relative paths use this directory as a base 107 directory "/var"; 108 // version statement for security to avoid hacking known weaknesses 109 // if the real version number is revealed 110 version "not currently available"; 111 // This is the default - allows user queries from any IP 112 allow-query { any; }; 113 // normal server operations may place items in the cache 114 // this prevents any user query from accessing these items 115 // only authoritative zone data will be returned 116 allow-query-cache { none; }; 117 // Do not provide recursive service to user queries 118 recursion no; 119 }; 120 // logging clause 121 // log to /var/log/named/example.log all events from info UP in severity (no debug) 122 // uses 3 files in rotation swaps files when size reaches 250K 123 // failure messages that occur before logging is established are 124 // in syslog (/var/log/messages) 125 // 126 logging { 127 channel example_log { 128 // uses a relative path name and the directory statement to 129 // expand to /var/log/named/example.log 130 file "log/named/example.log" versions 3 size 250k; 131 // only log info and up messages - all others discarded 132 severity info; 133 }; 134 category default { 135 example_log; 136 }; 137 }; 138 // Provide forward mapping zone for localhost 139 // (optional) 140 zone "localhost" { 141 type primary; 142 file "master/localhost-forward.db"; 143 notify no; 144 }; 145 // Provide reverse mapping zone for the loopback 146 // address 127.0.0.1 147 zone "0.0.127.in-addr.arpa" { 148 type primary; 149 file "localhost.rev"; 150 notify no; 151 }; 152 // We are the primary server for example.com 153 zone "example.com" { 154 // this is the primary name server for the zone 155 type primary; 156 file "example.com"; 157 // this is the default 158 notify yes; 159 // IP addresses of secondary servers allowed to 160 // transfer example.com from this server 161 allow-transfer { 162 192.168.4.14; 163 192.168.5.53; 164 }; 165 }; 166 167The added statements and blocks are commented in the above file. 168 169The :any:`zone` block, and :any:`allow-query`, 170:any:`allow-query-cache`, 171:any:`allow-transfer`, :any:`file`, 172:namedconf:ref:`notify`, :any:`recursion`, and :any:`type` 173statements are described in detail in the appropriate sections. 174 175.. _sample_secondary: 176 177Secondary Authoritative Name Server 178~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 179 180The zone files ``local-host-forward.db`` and ``localhost.rev`` are unmodified 181:ref:`from the base samples<base_zone_file>`. The **example.com** zone file is 182not required (the zone file is obtained from the primary via zone transfer). 183The :ref:`named.conf<named_conf>` file has been modified as shown: 184 185.. code-block:: c 186 187 // authoritative secondary named.conf file 188 // options clause defining the server-wide properties 189 options { 190 // all relative paths use this directory as a base 191 directory "/var"; 192 // version statement for security to avoid hacking known weaknesses 193 // if the real version number is revealed 194 version "not currently available"; 195 // This is the default - allows user queries from any IP 196 allow-query { any; }; 197 // normal server operations may place items in the cache 198 // this prevents any user query from accessing these items 199 // only authoritative zone data will be returned 200 allow-query-cache { none; }; 201 // Do not provide recursive service to user queries 202 recursion no; 203 }; 204 // logging clause 205 // log to /var/log/named/example.log all events from info UP in severity (no debug) 206 // uses 3 files in rotation swaps files when size reaches 250K 207 // failure messages that occur before logging is established are 208 // in syslog (/var/log/messages) 209 // 210 logging { 211 channel example_log { 212 // uses a relative path name and the directory statement to 213 // expand to /var/log/named/example.log 214 file "log/named/example.log" versions 3 size 250k; 215 // only log info and up messages - all others discarded 216 severity info; 217 }; 218 category default { 219 example_log; 220 }; 221 }; 222 // Provide forward mapping zone for localhost 223 // (optional) 224 zone "localhost" { 225 type primary; 226 file "master/localhost-forward.db"; 227 notify no; 228 }; 229 // Provide reverse mapping zone for the loopback 230 // address 127.0.0.1 231 zone "0.0.127.in-addr.arpa" { 232 type primary; 233 file "localhost.rev"; 234 notify no; 235 }; 236 // We are the secondary server for example.com 237 zone "example.com" { 238 // this is a secondary server for the zone 239 type secondary; 240 // the file statement here allows the secondary to save 241 // each zone transfer so that in the event of a program restart 242 // the zone can be loaded immediately and the server can start 243 // to respond to queries without waiting for a zone transfer 244 file "example.com.saved"; 245 // IP address of example.com primary server 246 primaries { 192.168.254.2; }; 247 }; 248 249The statements and blocks added are all commented in the above file. 250 251The :any:`zone` block, and :any:`allow-query`, 252:any:`allow-query-cache`, 253:any:`allow-transfer`, :any:`file`, 254:namedconf:ref:`primaries`, 255:any:`recursion`, and :any:`type` statements are described in 256detail in the appropriate sections. 257 258If NOTIFY is not being used, no changes are required in this 259:ref:`named.conf<named_conf>` file, since it is the primary that initiates the NOTIFY 260message. 261 262.. note:: 263 Just when the reader thought they understood primary and secondary, things 264 can get more complicated. A secondary zone can also be a primary to other 265 secondaries: :iscman:`named`, by default, sends NOTIFY messages for every 266 zone it loads. Specifying :ref:`notify primary-only;<notify>` in the 267 :any:`zone` block for the secondary causes :iscman:`named` to 268 only send NOTIFY messages for primary zones that it loads. 269
