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.. _intro_dns_security: 13 14DNS Security Overview 15--------------------- 16 17DNS is a communications protocol. All communications protocols are potentially 18vulnerable to both subversion and eavesdropping. It is important for 19users to audit their exposure to the various threats within their operational environment and implement the 20appropriate solutions. BIND 9, a specific implementation of the DNS protocol, 21provides an extensive set of security features. The purpose of this section 22is to help users to select from the range of available security features those 23required for their specific user environment. 24 25A generic DNS network is shown below, followed by text descriptions. In general, 26the further one goes from the left-hand side of the diagram, the more complex 27the implementation. 28 29.. Note:: Historically, DNS data was regarded as public and security was 30 concerned, primarily, with ensuring the integrity of DNS data. DNS data privacy 31 is increasingly regarded as an important dimension of overall security, specifically :ref:`DNS over TLS<dns_over_tls>`. 32 33.. figure:: dns-security-overview.png 34 :align: center 35 36 BIND 9 Security Overview 37 38The following notes refer to the numbered elements in the above diagram. 39 401. A variety of system administration techniques and methods may be used to secure 41BIND 9's local environment, including :ref:`file permissions <file_permissions>`, running 42BIND 9 in a :ref:`jail <chroot_and_setuid>`, and the use of :ref:`Access_Control_Lists`. 43 442. The remote name daemon control (:ref:`rndc<ops_rndc>`) program allows the system 45administrator to control the operation of a name server. The majority of BIND 9 packages 46or ports come preconfigured with local (loopback address) security preconfigured. 47If ``rndc`` is being invoked from a remote host, further configuration is required. 48The ``nsupdate`` tool uses **Dynamic DNS (DDNS)** features and allows users to dynamically 49change the contents of the zone file(s). ``nsupdate`` access and security may be controlled 50using ``named.conf`` :ref:`statements or using TSIG or SIG(0) cryptographic methods <dynamic_update_security>`. 51Clearly, if the remote hosts used for either ``rndc`` or DDNS lie within a network entirely 52under the user's control, the security threat may be regarded as non-existent. Any implementation requirements, 53therefore, depend on the site's security policy. 54 553. Zone transfer from a **primary** to one or more **secondary** authoritative name servers across a 56public network carries risk. The zone transfer may be secured using 57``named.conf`` :ref:`statements, TSIG cryptographic methods or TLS<sec_file_transfer>`. 58Clearly, if the secondary authoritative name server(s) all lie within a network entirely 59under the user's control, the security threat may be regarded as non-existent. Any implementation requirements 60again depend on the site's security policy. 61 624. If the operator of an authoritative name server (primary or secondary) wishes to ensure that 63DNS responses to user-initiated queries about the zone(s) for which they are responsible can only 64have come from their server, that the data received by the user is the same as that sent, and that 65non-existent names are genuine, then :ref:`DNSSEC` is the only solution. DNSSEC requires configuration 66and operational changes both to the authoritative name servers and to any resolver which accesses 67those servers. 68 695. The typical Internet-connected end-user device (PCs, laptops, and even mobile phones) either has 70a stub resolver or operates via a DNS proxy. A stub resolver requires the services of an area 71or full-service resolver to completely answer user queries. Stub resolvers on the majority of PCs and laptops 72typically have a caching capability to increase performance. At this time there are no standard stub resolvers or proxy 73DNS tools that implement DNSSEC. BIND 9 may be configured to provide such capability on supported Linux or Unix platforms. 74:ref:`DNS over TLS <dns_over_tls>` may be configured to verify the integrity of the data between the stub resolver and 75area (or full-service) resolver. However, unless the resolver and the Authoritative Name Server implements DNSSEC, end-to-end integrity (from 76authoritative name server to stub resolver) cannot be guaranteed. 77
