From 3b9b6d0b8e7f798023c9d109c490449d528fde80 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 17:59:48 +0200 Subject: Adding upstream version 1:9.18.19. Signed-off-by: Daniel Baumann --- doc/arm/intro-security.inc.rst | 76 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 doc/arm/intro-security.inc.rst (limited to 'doc/arm/intro-security.inc.rst') 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`. + +.. 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 `, running +BIND 9 in a :ref:`jail `, and the use of :ref:`Access_Control_Lists`. + +2. The remote name daemon control (:ref:`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 `. +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`. +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 ` 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. -- cgit v1.2.3