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