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.. _advanced: 13 14Advanced Configurations 15======================= 16 17.. _dynamic_update: 18 19Dynamic Update 20-------------- 21 22Dynamic update is a method for adding, replacing, or deleting records in 23a primary server by sending it a special form of DNS messages. The format 24and meaning of these messages is specified in :rfc:`2136`. 25 26Dynamic update is enabled by including an :any:`allow-update` or an 27:any:`update-policy` clause in the :any:`zone` statement. 28 29If the zone's :any:`update-policy` is set to ``local``, updates to the zone 30are permitted for the key ``local-ddns``, which is generated by 31:iscman:`named` at startup. See :ref:`dynamic_update_policies` for more details. 32 33Dynamic updates using Kerberos-signed requests can be made using the 34TKEY/GSS protocol, either by setting the :any:`tkey-gssapi-keytab` option 35or by setting both the :any:`tkey-gssapi-credential` and 36:any:`tkey-domain` options. Once enabled, Kerberos-signed requests are 37matched against the update policies for the zone, using the Kerberos 38principal as the signer for the request. 39 40Updating of secure zones (zones using DNSSEC) follows :rfc:`3007`: RRSIG, 41NSEC, and NSEC3 records affected by updates are automatically regenerated 42by the server using an online zone key. Update authorization is based on 43transaction signatures and an explicit server policy. 44 45.. _journal: 46 47The Journal File 48~~~~~~~~~~~~~~~~ 49 50All changes made to a zone using dynamic update are stored in the zone's 51journal file. This file is automatically created by the server when the 52first dynamic update takes place. The name of the journal file is formed 53by appending the extension ``.jnl`` to the name of the corresponding 54zone file unless specifically overridden. The journal file is in a 55binary format and should not be edited manually. 56 57The server also occasionally writes ("dumps") the complete contents 58of the updated zone to its zone file. This is not done immediately after 59each dynamic update because that would be too slow when a large zone is 60updated frequently. Instead, the dump is delayed by up to 15 minutes, 61allowing additional updates to take place. During the dump process, 62transient files are created with the extensions ``.jnw`` and 63``.jbk``; under ordinary circumstances, these are removed when the 64dump is complete, and can be safely ignored. 65 66When a server is restarted after a shutdown or crash, it replays the 67journal file to incorporate into the zone any updates that took place 68after the last zone dump. 69 70Changes that result from incoming incremental zone transfers are also 71journaled in a similar way. 72 73The zone files of dynamic zones cannot normally be edited by hand 74because they are not guaranteed to contain the most recent dynamic 75changes; those are only in the journal file. The only way to ensure 76that the zone file of a dynamic zone is up-to-date is to run 77:option:`rndc stop`. 78 79To make changes to a dynamic zone manually, follow these steps: 80first, disable dynamic updates to the zone using 81:option:`rndc freeze zone <rndc freeze>`. This updates the zone file with the 82changes stored in its ``.jnl`` file. Then, edit the zone file. Finally, run 83:option:`rndc thaw zone <rndc thaw>` to reload the changed zone and re-enable dynamic 84updates. 85 86:option:`rndc sync zone <rndc sync>` updates the zone file with changes from the 87journal file without stopping dynamic updates; this may be useful for 88viewing the current zone state. To remove the ``.jnl`` file after 89updating the zone file, use :option:`rndc sync -clean <rndc sync>`. 90 91.. _notify: 92 93NOTIFY 94------ 95 96DNS NOTIFY is a mechanism that allows primary servers to notify their 97secondary servers of changes to a zone's data. In response to a NOTIFY message 98from a primary server, the secondary checks to see that its version of 99the zone is the current version and, if not, initiates a zone transfer. 100 101For more information about DNS NOTIFY, see the description of the 102:namedconf:ref:`notify` and :namedconf:ref`also-notify` statements. 103The NOTIFY protocol is specified in :rfc:`1996`. 104 105.. note:: 106 107 As a secondary zone can also be a primary to other secondaries, :iscman:`named`, by 108 default, sends NOTIFY messages for every zone it loads. 109 110.. _incremental_zone_transfers: 111 112Incremental Zone Transfers (IXFR) 113--------------------------------- 114 115The incremental zone transfer (IXFR) protocol is a way for secondary servers 116to transfer only changed data, instead of having to transfer an entire 117zone. The IXFR protocol is specified in :rfc:`1995`. 118 119When acting as a primary server, BIND 9 supports IXFR for those zones where the 120necessary change history information is available. These include primary 121zones maintained by dynamic update and secondary zones whose data was 122obtained by IXFR. For manually maintained primary zones, and for secondary 123zones obtained by performing a full zone transfer (AXFR), IXFR is 124supported only if the option :any:`ixfr-from-differences` is set to 125``yes``. 126 127When acting as a secondary server, BIND 9 attempts to use IXFR unless it is 128explicitly disabled. For more information about disabling IXFR, see the 129description of the :any:`request-ixfr` clause of the :namedconf:ref:`server` statement. 130 131When a secondary server receives a zone via AXFR, it creates a new copy of the 132zone database and then swaps it into place; during the loading process, queries 133continue to be served from the old database with no interference. When receiving 134a zone via IXFR, however, changes are applied to the running zone, which may 135degrade query performance during the transfer. If a server receiving an IXFR 136request determines that the response size would be similar in size to an AXFR 137response, it may wish to send AXFR instead. The threshold at which this 138determination is made can be configured using the 139:any:`max-ixfr-ratio` option. 140 141.. _split_dns: 142 143Split DNS 144--------- 145 146Setting up different views of the DNS space to internal 147and external resolvers is usually referred to as a *split DNS* setup. 148There are several reasons an organization might want to set up its DNS 149this way. 150 151One common reason to use split DNS is to hide 152"internal" DNS information from "external" clients on the Internet. 153There is some debate as to whether this is actually useful. 154Internal DNS information leaks out in many ways (via email headers, for 155example) and most savvy "attackers" can find the information they need 156using other means. However, since listing addresses of internal servers 157that external clients cannot possibly reach can result in connection 158delays and other annoyances, an organization may choose to use split 159DNS to present a consistent view of itself to the outside world. 160 161Another common reason for setting up a split DNS system is to allow 162internal networks that are behind filters or in :rfc:`1918` space (reserved 163IP space, as documented in :rfc:`1918`) to resolve DNS on the Internet. 164Split DNS can also be used to allow mail from outside back into the 165internal network. 166 167.. _split_dns_sample: 168 169Example Split DNS Setup 170~~~~~~~~~~~~~~~~~~~~~~~ 171 172Let's say a company named *Example, Inc.* (``example.com``) has several 173corporate sites that have an internal network with reserved Internet 174Protocol (IP) space and an external demilitarized zone (DMZ), or 175"outside" section of a network, that is available to the public. 176 177Example, Inc. wants its internal clients to be able to resolve 178external hostnames and to exchange mail with people on the outside. The 179company also wants its internal resolvers to have access to certain 180internal-only zones that are not available at all outside of the 181internal network. 182 183To accomplish this, the company sets up two sets of name 184servers. One set is on the inside network (in the reserved IP 185space) and the other set is on bastion hosts, which are "proxy" 186hosts in the DMZ that can talk to both sides of its network. 187 188The internal servers are configured to forward all queries, except 189queries for ``site1.internal``, ``site2.internal``, 190``site1.example.com``, and ``site2.example.com``, to the servers in the 191DMZ. These internal servers have complete sets of information for 192``site1.example.com``, ``site2.example.com``, ``site1.internal``, and 193``site2.internal``. 194 195To protect the ``site1.internal`` and ``site2.internal`` domains, the 196internal name servers must be configured to disallow all queries to 197these domains from any external hosts, including the bastion hosts. 198 199The external servers, which are on the bastion hosts, are configured 200to serve the "public" version of the ``site1.example.com`` and ``site2.example.com`` 201zones. This could include things such as the host records for public 202servers (``www.example.com`` and ``ftp.example.com``) and mail exchange 203(MX) records (``a.mx.example.com`` and ``b.mx.example.com``). 204 205In addition, the public ``site1.example.com`` and ``site2.example.com`` zones should 206have special MX records that contain wildcard (``*``) records pointing to 207the bastion hosts. This is needed because external mail servers 208have no other way of determining how to deliver mail to those internal 209hosts. With the wildcard records, the mail is delivered to the 210bastion host, which can then forward it on to internal hosts. 211 212Here's an example of a wildcard MX record: 213 214:: 215 216 * IN MX 10 external1.example.com. 217 218Now that they accept mail on behalf of anything in the internal network, 219the bastion hosts need to know how to deliver mail to internal 220hosts. The resolvers on the bastion 221hosts need to be configured to point to the internal name servers 222for DNS resolution. 223 224Queries for internal hostnames are answered by the internal servers, 225and queries for external hostnames are forwarded back out to the DNS 226servers on the bastion hosts. 227 228For all of this to work properly, internal clients need to be 229configured to query *only* the internal name servers for DNS queries. 230This could also be enforced via selective filtering on the network. 231 232If everything has been set properly, Example, Inc.'s internal clients 233are now able to: 234 235- Look up any hostnames in the ``site1.example.com`` and ``site2.example.com`` 236 zones. 237 238- Look up any hostnames in the ``site1.internal`` and 239 ``site2.internal`` domains. 240 241- Look up any hostnames on the Internet. 242 243- Exchange mail with both internal and external users. 244 245Hosts on the Internet are able to: 246 247- Look up any hostnames in the ``site1.example.com`` and ``site2.example.com`` 248 zones. 249 250- Exchange mail with anyone in the ``site1.example.com`` and ``site2.example.com`` 251 zones. 252 253Here is an example configuration for the setup just described above. 254Note that this is only configuration information; for information on how 255to configure the zone files, see :ref:`sample_configuration`. 256 257Internal DNS server config: 258 259:: 260 261 262 acl internals { 172.16.72.0/24; 192.168.1.0/24; }; 263 264 acl externals { bastion-ips-go-here; }; 265 266 options { 267 ... 268 ... 269 forward only; 270 // forward to external servers 271 forwarders { 272 bastion-ips-go-here; 273 }; 274 // sample allow-transfer (no one) 275 allow-transfer { none; }; 276 // restrict query access 277 allow-query { internals; externals; }; 278 // restrict recursion 279 allow-recursion { internals; }; 280 ... 281 ... 282 }; 283 284 // sample primary zone 285 zone "site1.example.com" { 286 type primary; 287 file "m/site1.example.com"; 288 // do normal iterative resolution (do not forward) 289 forwarders { }; 290 allow-query { internals; externals; }; 291 allow-transfer { internals; }; 292 }; 293 294 // sample secondary zone 295 zone "site2.example.com" { 296 type secondary; 297 file "s/site2.example.com"; 298 primaries { 172.16.72.3; }; 299 forwarders { }; 300 allow-query { internals; externals; }; 301 allow-transfer { internals; }; 302 }; 303 304 zone "site1.internal" { 305 type primary; 306 file "m/site1.internal"; 307 forwarders { }; 308 allow-query { internals; }; 309 allow-transfer { internals; } 310 }; 311 312 zone "site2.internal" { 313 type secondary; 314 file "s/site2.internal"; 315 primaries { 172.16.72.3; }; 316 forwarders { }; 317 allow-query { internals }; 318 allow-transfer { internals; } 319 }; 320 321External (bastion host) DNS server configuration: 322 323:: 324 325 acl internals { 172.16.72.0/24; 192.168.1.0/24; }; 326 327 acl externals { bastion-ips-go-here; }; 328 329 options { 330 ... 331 ... 332 // sample allow-transfer (no one) 333 allow-transfer { none; }; 334 // default query access 335 allow-query { any; }; 336 // restrict cache access 337 allow-query-cache { internals; externals; }; 338 // restrict recursion 339 allow-recursion { internals; externals; }; 340 ... 341 ... 342 }; 343 344 // sample secondary zone 345 zone "site1.example.com" { 346 type primary; 347 file "m/site1.foo.com"; 348 allow-transfer { internals; externals; }; 349 }; 350 351 zone "site2.example.com" { 352 type secondary; 353 file "s/site2.foo.com"; 354 primaries { another_bastion_host_maybe; }; 355 allow-transfer { internals; externals; } 356 }; 357 358In the ``resolv.conf`` (or equivalent) on the bastion host(s): 359 360:: 361 362 search ... 363 nameserver 172.16.72.2 364 nameserver 172.16.72.3 365 nameserver 172.16.72.4 366 367.. _ipv6: 368 369IPv6 Support in BIND 9 370---------------------- 371 372BIND 9 fully supports all currently defined forms of IPv6 name-to-address 373and address-to-name lookups. It also uses IPv6 addresses to 374make queries when running on an IPv6-capable system. 375 376For forward lookups, BIND 9 supports only AAAA records. :rfc:`3363` 377deprecated the use of A6 records, and client-side support for A6 records 378was accordingly removed from BIND 9. However, authoritative BIND 9 name 379servers still load zone files containing A6 records correctly, answer 380queries for A6 records, and accept zone transfer for a zone containing 381A6 records. 382 383For IPv6 reverse lookups, BIND 9 supports the traditional "nibble" 384format used in the ``ip6.arpa`` domain, as well as the older, deprecated 385``ip6.int`` domain. Older versions of BIND 9 supported the "binary label" 386(also known as "bitstring") format, but support of binary labels has 387been completely removed per :rfc:`3363`. Many applications in BIND 9 do not 388understand the binary label format at all anymore, and return an 389error if one is given. In particular, an authoritative BIND 9 name server will 390not load a zone file containing binary labels. 391 392Address Lookups Using AAAA Records 393~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 394 395The IPv6 AAAA record is a parallel to the IPv4 A record, and, unlike the 396deprecated A6 record, specifies the entire IPv6 address in a single 397record. For example: 398 399:: 400 401 $ORIGIN example.com. 402 host 3600 IN AAAA 2001:db8::1 403 404Use of IPv4-in-IPv6 mapped addresses is not recommended. If a host has 405an IPv4 address, use an A record, not a AAAA, with 406``::ffff:192.168.42.1`` as the address. 407 408Address-to-Name Lookups Using Nibble Format 409~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 410 411When looking up an address in nibble format, the address components are 412simply reversed, just as in IPv4, and ``ip6.arpa.`` is appended to the 413resulting name. For example, the following commands produce a reverse name 414lookup for a host with address ``2001:db8::1``: 415 416:: 417 418 $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 419 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 14400 IN PTR ( 420 host.example.com. ) 421