Bug 1452091 - [RFE] Backport "negative trust anchors" (IETF RFC 7646) from BIND 9.11
Summary: [RFE] Backport "negative trust anchors" (IETF RFC 7646) from BIND 9.11
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: bind
Version: 7.3
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Petr Menšík
QA Contact: Petr Sklenar
Filip Hanzelka
Depends On: 1487823 named_writable_home 1572647 1633158
Blocks: 1420851 1465928 1534569 1549614
TreeView+ depends on / blocked
Reported: 2017-05-18 10:40 UTC by Yogita
Modified: 2021-12-10 15:03 UTC (History)
5 users (show)

Fixed In Version: bind-9.9.4-65.el7
Doc Type: Release Note
Doc Text:
DNSSEC validation can be disabled for selected domains Previously, if DNSSEC validation was enabled and a specific domain was failing, no hosts in that domain could be reached. With this release, you can configure exemptions from DNS Security Extensions (DNSSEC) validation for selected zones if the validation fails because of incorrect configuration, not an attack. The addresses of the hosts in the failing domain are resolved as unsigned and can be reached, while all other names are validated for security risks.
Clone Of:
Last Closed: 2018-10-30 10:18:33 UTC
Target Upstream Version:

Attachments (Terms of Use)
NTA backport to BIND 9.9 patch (264.34 KB, patch)
2017-11-09 15:02 UTC, Petr Menšík
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3235751 0 None None None 2017-11-08 15:32:00 UTC
Red Hat Product Errata RHBA-2018:3136 0 None None None 2018-10-30 10:19:49 UTC

Description Yogita 2017-05-18 10:40:34 UTC
Description of problem:
RFE -  bind package to include features of ISC BIND (BIND 9.11)

Version-Release number of selected component (if applicable):

Business justification on this in Customer's words -
The business justification is mainly security/compliance related. As stated in Case 01183581, our security regulations require us to enable DNSSEC validation in our DNS resolvers.
However, the BIND versions in RedHat can only enable DNSSEC validation on a global level (for all queries - without exceptions). Unfortunately, some of our customer's internal domains will fail dnssec validation, because they use dns names that are not registered officially. Since we need access to these domains, we currently can not enable DNSSEC validation on our resolvers :(

The current bind911 version has more fine grained DNSSEC validation features, called "negative trust anchors" (see IETF RFC 7646). This would enable us to use finally enable DNSSEC for all queries, while we can still disable DNSSEC validation for specific domains known to be failing validation due to administrative error rather than because of a spoofing attack.

The new bind version would help us comply with our (and our customer's) compliance regulations and significantly raise the security level of the whole corporate network.

Additional info:
rpm -q bind --changelog  <--Doesnt show that "RFC 7646" is included in RHEL7 bind package

see IETF RFC 7646  --> https://tools.ietf.org/html/rfc7646

Comment 3 Petr Menšík 2017-05-19 14:58:40 UTC
Note that there is one problem with nta feature, similar to NZF. It cannot change directory used to store files containing nta exception. However default directory is /var/named, which is by default read only and protected by selinux policy to write. Even if I backport NTA from upstream, this is not solved in upstream.

Comment 9 Petr Menšík 2017-11-09 15:02:59 UTC
Created attachment 1349991 [details]
NTA backport to BIND 9.9 patch

This version does not solve missing rights to write file into home directory. May fail to provide full list of NTA domains via rndc nta -dump. Workaround is to use rndc secroots, where all entries would be always listed into dumped file. Upstream relies on dynamic isc_buffer_t, which is not yet implemented in 9.9 and backport of it seems too invasive to me.

Comment 30 errata-xmlrpc 2018-10-30 10:18:33 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.