1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
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.
|
