76 lines
4.6 KiB
ReStructuredText
76 lines
4.6 KiB
ReStructuredText
.. 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.
|