diff options
Diffstat (limited to 'doc/arm/intro-security.inc.rst')
| -rw-r--r-- | doc/arm/intro-security.inc.rst | 76 |
1 files changed, 76 insertions, 0 deletions
diff --git a/doc/arm/intro-security.inc.rst b/doc/arm/intro-security.inc.rst new file mode 100644 index 0000000..87db970 --- /dev/null +++ b/doc/arm/intro-security.inc.rst @@ -0,0 +1,76 @@ +.. Copyright (C) Internet Systems Consortium, Inc. ("ISC") +.. +.. SPDX-License-Identifier: MPL-2.0 +.. +.. This Source Code Form is subject to the terms of the Mozilla Public +.. License, v. 2.0. If a copy of the MPL was not distributed with this +.. file, you can obtain one at https://mozilla.org/MPL/2.0/. +.. +.. See the COPYRIGHT file distributed with this work for additional +.. information regarding copyright ownership. + +.. _intro_dns_security: + +DNS Security Overview +--------------------- + +DNS is a communications protocol. All communications protocols are potentially +vulnerable to both subversion and eavesdropping. It is important for +users to audit their exposure to the various threats within their operational environment and implement the +appropriate solutions. BIND 9, a specific implementation of the DNS protocol, +provides an extensive set of security features. The purpose of this section +is to help users to select from the range of available security features those +required for their specific user environment. + +A generic DNS network is shown below, followed by text descriptions. In general, +the further one goes from the left-hand side of the diagram, the more complex +the implementation. + +.. Note:: Historically, DNS data was regarded as public and security was + concerned, primarily, with ensuring the integrity of DNS data. DNS data privacy + is increasingly regarded as an important dimension of overall security, specifically :ref:`DNS over TLS<dns_over_tls>`. + +.. figure:: dns-security-overview.png + :align: center + + BIND 9 Security Overview + +The following notes refer to the numbered elements in the above diagram. + +1. A variety of system administration techniques and methods may be used to secure +BIND 9's local environment, including :ref:`file permissions <file_permissions>`, running +BIND 9 in a :ref:`jail <chroot_and_setuid>`, and the use of :ref:`Access_Control_Lists`. + +2. The remote name daemon control (:ref:`rndc<ops_rndc>`) program allows the system +administrator to control the operation of a name server. The majority of BIND 9 packages +or ports come preconfigured with local (loopback address) security preconfigured. +If ``rndc`` is being invoked from a remote host, further configuration is required. +The ``nsupdate`` tool uses **Dynamic DNS (DDNS)** features and allows users to dynamically +change the contents of the zone file(s). ``nsupdate`` access and security may be controlled +using ``named.conf`` :ref:`statements or using TSIG or SIG(0) cryptographic methods <dynamic_update_security>`. +Clearly, if the remote hosts used for either ``rndc`` or DDNS lie within a network entirely +under the user's control, the security threat may be regarded as non-existent. Any implementation requirements, +therefore, depend on the site's security policy. + +3. Zone transfer from a **primary** to one or more **secondary** authoritative name servers across a +public network carries risk. The zone transfer may be secured using +``named.conf`` :ref:`statements, TSIG cryptographic methods or TLS<sec_file_transfer>`. +Clearly, if the secondary authoritative name server(s) all lie within a network entirely +under the user's control, the security threat may be regarded as non-existent. Any implementation requirements +again depend on the site's security policy. + +4. If the operator of an authoritative name server (primary or secondary) wishes to ensure that +DNS responses to user-initiated queries about the zone(s) for which they are responsible can only +have come from their server, that the data received by the user is the same as that sent, and that +non-existent names are genuine, then :ref:`DNSSEC` is the only solution. DNSSEC requires configuration +and operational changes both to the authoritative name servers and to any resolver which accesses +those servers. + +5. The typical Internet-connected end-user device (PCs, laptops, and even mobile phones) either has +a stub resolver or operates via a DNS proxy. A stub resolver requires the services of an area +or full-service resolver to completely answer user queries. Stub resolvers on the majority of PCs and laptops +typically have a caching capability to increase performance. At this time there are no standard stub resolvers or proxy +DNS tools that implement DNSSEC. BIND 9 may be configured to provide such capability on supported Linux or Unix platforms. +:ref:`DNS over TLS <dns_over_tls>` may be configured to verify the integrity of the data between the stub resolver and +area (or full-service) resolver. However, unless the resolver and the Authoritative Name Server implements DNSSEC, end-to-end integrity (from +authoritative name server to stub resolver) cannot be guaranteed. |