From 992b87ccc198644a71a857f77d063913af21e388 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20=C5=A0pa=C4=8Dek?= Date: Tue, 10 Oct 2023 09:32:03 +0200 Subject: [PATCH 1/2] Add qplookups test to .gitignore --- tests/bench/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/bench/.gitignore b/tests/bench/.gitignore index 9f93506f12..4b953e0128 100644 --- a/tests/bench/.gitignore +++ b/tests/bench/.gitignore @@ -4,5 +4,6 @@ /dns_name_fromwire /load-names /qp-dump +/qplookups /qpmulti /siphash From fc907baa7f82ab45bb0159c798649cf575e59aa4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20=C5=A0pa=C4=8Dek?= Date: Tue, 10 Oct 2023 11:27:16 +0200 Subject: [PATCH 2/2] Describe BIND threat model Basically all local data is considered trusted, and proper ACLs and limits need to be explicitly configured. We are also free to let protocol non-compliant servers burn in flames. --- doc/arm/security.inc.rst | 50 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/doc/arm/security.inc.rst b/doc/arm/security.inc.rst index 2936432f3e..878fa379fe 100644 --- a/doc/arm/security.inc.rst +++ b/doc/arm/security.inc.rst @@ -14,6 +14,56 @@ Security Configurations ======================= +Security Assumptions +-------------------- +BIND 9's design assumes that access to the objects listed below is limited only to +trusted parties. An incorrect deployment, which does not follow rules set by this +section, cannot be the basis for CVE assignment or special security-sensitive +handling of issues. + +Unauthorized access can potentially disclose sensitive data, slow down server +operation, etc. Unauthorized, unexpected, or incorrect writes to listed objects +can potentically cause crashes, incorrect data handling, or corruption. + +- All files stored on disk - including zone files, configuration files, key + files, temporary files, etc. +- Clients communicating via :any:`controls` socket using configured keys +- Access to :any:`statistics-channels` from untrusted clients +- Sockets used for :any:`update-policy` type `external` + +Certain aspects of the DNS protocol are left unspecified, such as the handling of +responses from DNS servers which do not fully conform to the DNS protocol. For +such a situation, BIND implements its own safety checks and limits which are +subject to change as the protocol and deployment evolve. + +Authoritative Servers +~~~~~~~~~~~~~~~~~~~~~ +By default, zones use intentionally lenient limits (unlimited size, long +transfer timeouts, etc.). These defaults can be misused by the source of data +(zone transfers or UPDATEs) to exhaust resources on the receiving side. + +The impact of malicious zone changes can be limited, to an extent, using +configuration options listed in sections :ref:`server_resource_limits` and +:ref:`zone_transfers`. Limits should also be applied to zones where malicious clients may potentially be authorized to use :ref:`dynamic_update`. + +DNS Resolvers +~~~~~~~~~~~~~ +By definition, DNS resolvers act as traffic amplifiers; +during normal operation, a DNS resolver can legitimately generate more outgoing +traffic (counted in packets or bytes) than the incoming client traffic that +triggered it. The DNS protocol specification does not currently specify limits +for this amplification, but BIND implements its own limits to balance +interoperability and safety. As a general rule, if a traffic amplification factor +for any given scenario is lower than 100 packets, ISC does not handle the given +scenario as a security issue. These limits are subject to change as DNS +deployment evolves. + +All DNS answers received by the DNS resolver are treated as untrusted input and are +subject to safety and correctness checks. However, protocol non-conformity +might cause unexpected behavior. If such unexpected behavior is limited to DNS +domains hosted on non-conformant servers, it is not deemed a security issue *in +BIND*. + .. _file_permissions: .. _access_Control_Lists: