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.. Security: 13 14BIND 9 Security Considerations 15============================== 16 17.. _Access_Control_Lists: 18 19Access Control Lists 20-------------------- 21 22Access Control Lists (ACLs) are address match lists that can be set up 23and nicknamed for future use in ``allow-notify``, ``allow-query``, 24``allow-query-on``, ``allow-recursion``, ``blackhole``, 25``allow-transfer``, ``match-clients``, etc. 26 27ACLs give users finer control over who can access the 28name server, without cluttering up configuration files with huge lists of 29IP addresses. 30 31It is a *good idea* to use ACLs, and to control access. 32Limiting access to the server by outside parties can help prevent 33spoofing and denial of service (DoS) attacks against the server. 34 35ACLs match clients on the basis of up to three characteristics: 1) The 36client's IP address; 2) the TSIG or SIG(0) key that was used to sign the 37request, if any; and 3) an address prefix encoded in an EDNS 38Client-Subnet option, if any. 39 40Here is an example of ACLs based on client addresses: 41 42:: 43 44 // Set up an ACL named "bogusnets" that blocks 45 // RFC1918 space and some reserved space, which is 46 // commonly used in spoofing attacks. 47 acl bogusnets { 48 0.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; 49 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; 50 }; 51 52 // Set up an ACL called our-nets. Replace this with the 53 // real IP numbers. 54 acl our-nets { x.x.x.x/24; x.x.x.x/21; }; 55 options { 56 ... 57 ... 58 allow-query { our-nets; }; 59 allow-recursion { our-nets; }; 60 ... 61 blackhole { bogusnets; }; 62 ... 63 }; 64 65 zone "example.com" { 66 type primary; 67 file "m/example.com"; 68 allow-query { any; }; 69 }; 70 71This allows authoritative queries for ``example.com`` from any address, 72but recursive queries only from the networks specified in ``our-nets``, 73and no queries at all from the networks specified in ``bogusnets``. 74 75In addition to network addresses and prefixes, which are matched against 76the source address of the DNS request, ACLs may include ``key`` 77elements, which specify the name of a TSIG or SIG(0) key. 78 79When BIND 9 is built with GeoIP support, ACLs can also be used for 80geographic access restrictions. This is done by specifying an ACL 81element of the form: ``geoip db database field value``. 82 83The ``field`` parameter indicates which field to search for a match. Available fields 84are ``country``, ``region``, ``city``, ``continent``, ``postal`` (postal code), 85``metro`` (metro code), ``area`` (area code), ``tz`` (timezone), ``isp``, 86``asnum``, and ``domain``. 87 88``value`` is the value to search for within the database. A string may be quoted 89if it contains spaces or other special characters. An ``asnum`` search for 90autonomous system number can be specified using the string "ASNNNN" or the 91integer NNNN. If a ``country`` search is specified with a string that is two characters 92long, it must be a standard ISO-3166-1 two-letter country code; otherwise, 93it is interpreted as the full name of the country. Similarly, if 94``region`` is the search term and the string is two characters long, it is treated as a 95standard two-letter state or province abbreviation; otherwise, it is treated as the 96full name of the state or province. 97 98The ``database`` field indicates which GeoIP database to search for a match. In 99most cases this is unnecessary, because most search fields can only be found in 100a single database. However, searches for ``continent`` or ``country`` can be 101answered from either the ``city`` or ``country`` databases, so for these search 102types, specifying a ``database`` forces the query to be answered from that 103database and no other. If a ``database`` is not specified, these queries 104are first answered from the ``city`` database if it is installed, and then from the ``country`` 105database if it is installed. Valid database names are ``country``, 106``city``, ``asnum``, ``isp``, and ``domain``. 107 108Some example GeoIP ACLs: 109 110:: 111 112 geoip country US; 113 geoip country JP; 114 geoip db country country Canada; 115 geoip region WA; 116 geoip city "San Francisco"; 117 geoip region Oklahoma; 118 geoip postal 95062; 119 geoip tz "America/Los_Angeles"; 120 geoip org "Internet Systems Consortium"; 121 122ACLs use a "first-match" logic rather than "best-match"; if an address 123prefix matches an ACL element, then that ACL is considered to have 124matched even if a later element would have matched more specifically. 125For example, the ACL ``{ 10/8; !10.0.0.1; }`` would actually match a 126query from 10.0.0.1, because the first element indicates that the query 127should be accepted, and the second element is ignored. 128 129When using "nested" ACLs (that is, ACLs included or referenced within 130other ACLs), a negative match of a nested ACL tells the containing ACL to 131continue looking for matches. This enables complex ACLs to be 132constructed, in which multiple client characteristics can be checked at 133the same time. For example, to construct an ACL which allows a query 134only when it originates from a particular network *and* only when it is 135signed with a particular key, use: 136 137:: 138 139 allow-query { !{ !10/8; any; }; key example; }; 140 141Within the nested ACL, any address that is *not* in the 10/8 network 142prefix is rejected, which terminates the processing of the ACL. 143Any address that *is* in the 10/8 network prefix is accepted, but 144this causes a negative match of the nested ACL, so the containing ACL 145continues processing. The query is accepted if it is signed by 146the key ``example``, and rejected otherwise. The ACL, then, only 147matches when *both* conditions are true. 148 149.. _chroot_and_setuid: 150 151``Chroot`` and ``Setuid`` 152------------------------- 153 154On Unix servers, it is possible to run BIND in a *chrooted* environment 155(using the ``chroot()`` function) by specifying the ``-t`` option for 156``named``. This can help improve system security by placing BIND in a 157"sandbox," which limits the damage done if a server is compromised. 158 159Another useful feature in the Unix version of BIND is the ability to run 160the daemon as an unprivileged user (``-u`` user). We suggest running 161as an unprivileged user when using the ``chroot`` feature. 162 163Here is an example command line to load BIND in a ``chroot`` sandbox, 164``/var/named``, and to run ``named`` ``setuid`` to user 202: 165 166``/usr/local/sbin/named -u 202 -t /var/named`` 167 168.. _chroot: 169 170The ``chroot`` Environment 171~~~~~~~~~~~~~~~~~~~~~~~~~~ 172 173For a ``chroot`` environment to work properly in a particular 174directory (for example, ``/var/named``), the 175environment must include everything BIND needs to run. From BIND's 176point of view, ``/var/named`` is the root of the filesystem; 177the values of options like ``directory`` and ``pid-file`` 178must be adjusted to account for this. 179 180Unlike with earlier versions of BIND, 181``named`` does *not* typically need to be compiled statically, nor do shared libraries need to be installed under the new 182root. However, depending on the operating system, it may be necessary to set 183up locations such as ``/dev/zero``, ``/dev/random``, ``/dev/log``, and 184``/etc/localtime``. 185 186.. _setuid: 187 188Using the ``setuid`` Function 189~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 190 191Prior to running the ``named`` daemon, use the ``touch`` utility (to 192change file access and modification times) or the ``chown`` utility (to 193set the user id and/or group id) on files where BIND should 194write. 195 196.. note:: 197 198 If the ``named`` daemon is running as an unprivileged user, it 199 cannot bind to new restricted ports if the server is 200 reloaded. 201 202.. _dynamic_update_security: 203 204Dynamic Update Security 205----------------------- 206 207Access to the dynamic update facility should be strictly limited. In 208earlier versions of BIND, the only way to do this was based on the IP 209address of the host requesting the update, by listing an IP address or 210network prefix in the ``allow-update`` zone option. This method is 211insecure, since the source address of the update UDP packet is easily 212forged. Also note that if the IP addresses allowed by the 213``allow-update`` option include the address of a secondary server which 214performs forwarding of dynamic updates, the primary can be trivially 215attacked by sending the update to the secondary, which forwards it to 216the primary with its own source IP address - causing the primary to approve 217it without question. 218 219For these reasons, we strongly recommend that updates be 220cryptographically authenticated by means of transaction signatures 221(TSIG). That is, the ``allow-update`` option should list only TSIG key 222names, not IP addresses or network prefixes. Alternatively, the 223``update-policy`` option can be used. 224 225Some sites choose to keep all dynamically updated DNS data in a 226subdomain and delegate that subdomain to a separate zone. This way, the 227top-level zone containing critical data, such as the IP addresses of 228public web and mail servers, need not allow dynamic updates at all. 229