RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1769876 - BIND stops DNSKEY lookup in get_dst_key() when a key with unsupported algorithm is found first [RHEL6]
Summary: BIND stops DNSKEY lookup in get_dst_key() when a key with unsupported algorit...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: bind
Version: 6.10
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Tomas Korbar
QA Contact: Petr Sklenar
URL:
Whiteboard:
Depends On:
Blocks: 1884530 1884532
TreeView+ depends on / blocked
 
Reported: 2019-11-07 16:26 UTC by Stepan Broz
Modified: 2024-03-25 15:30 UTC (History)
11 users (show)

Fixed In Version: bind-9.8.2-0.68.rc1.el6_10.9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1884530 1884532 (view as bug list)
Environment:
Last Closed: 2020-12-16 13:25:17 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Proposed patch, verified by the customer (900 bytes, patch)
2019-11-07 16:26 UTC, Stepan Broz
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Gitlab 1689 0 None None None 2020-03-19 14:25:49 UTC
Red Hat Knowledge Base (Solution) 4564671 0 None None None 2019-11-08 12:08:33 UTC
Red Hat Product Errata RHBA-2020:5570 0 None None None 2020-12-16 13:25:24 UTC

Description Stepan Broz 2019-11-07 16:26:16 UTC
Created attachment 1633742 [details]
Proposed patch, verified by the customer

Description of problem:
BIND with DNSSEC validation enabled will not validate a zone that has all resource records signed using a supported algorithm KSK as well as using unsupported algorithm ZSK.

The do-while loop in get_dst_key() in validator.c is broken when unsupported-algo ZSK is found first in dst_key_fromdns(), which returns an error as passed from algorithm_status().

File: validator.c
1652: 		result = dst_key_fromdns(&siginfo->signer, rdata.rdclass, &b,
1653: 					 val->view->mctx, &val->key);
1654: 		if (result != ISC_R_SUCCESS)
1655: 			goto failure;

That is a premature exit from the loop as on next iteration(s) of the do-while loop a valid DNSKEY would be found.

I am proposing a patch that does not break the loop when "DST_R_UNSUPPORTEDALG" is returned from dst_key_fromdns(), but it would be good to revise what error should break the loop (if any) and which certainly not.

This error causes a valid DNSSEC-signed zone not to pass a validation on all RHEL-6 machines running BIND.

Version-Release number of selected component (if applicable):
bind-9.8.2-0.68.rc1.el6_10.3

How reproducible:
Always

Steps to Reproduce:

The reproducer requires two machines, RHEL-7 (authoritative DNS), RHEL-6 (BIND as a forwarder). Make sure RHEL-6 can reach RHEL-7 on port 53/udp.

1. Install BIND on RHEL-7 host.
2. Edit /etc/named/named.conf:

--8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<------
options {
	listen-on port 53 { 127.0.0.1; <IP-of-RHEL7-host>; };
	listen-on-v6 port 53 { ::1; };
	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
	recursing-file  "/var/named/data/named.recursing";
	secroots-file   "/var/named/data/named.secroots";
	allow-query     { localhost; <IP-of-RHEL6-host>; };

	recursion no;

	dnssec-enable yes;
	dnssec-validation yes;

	/* Path to ISC DLV key */
	bindkeys-file "/etc/named.root.key";

	managed-keys-directory "/var/named/dynamic";

	pid-file "/run/named/named.pid";
	session-keyfile "/run/named/session.key";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "bad." IN {
	type master;
	file "bad.zone.signed";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
--8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<------

3. Create /var/named/bad.zone:

--8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<------
$TTL 5M
@	IN SOA	<short-hostname-of-RHEL7>.bad. hostmaster.bad. (
					1	; serial
					5M	; refresh
					1M	; retry
					1H	; expire
					5M )	; minimum
	NS	<hostname-of-RHEL7>
	A	127.0.0.1
	AAAA	::1
<short-hostname-of-RHEL7> A	127.0.0.1
	AAAA	::1
--8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<------

4. Create key pairs (still on RHEL-7):

# cd /var/named

RHEL-6 supported KSK:

# dnssec-keygen -f KSK -a RSASHA512 -b 2048 bad

(remember the KSK name, it will be Kbad.+010+?????)

One or two RHEL-6 unsupported ZSKs:

# dnssec-keygen -a ECDSAP256SHA256 -n ZONE bad
# dnssec-keygen -a ECDSAP256SHA256 -n ZONE bad

5. Include the keys in the bad.zone:

# for key in `ls Kbad.+0*.key`; do echo "\$INCLUDE $key">> /var/named/bad.zone; done

6. Sign the zone using the KSK (replace ???? with the KSK key-id):

# dnssec-signzone -A -k Kbad.+010+????? -z -3 9911c319070e83f8 -N INCREMENT -o bad -t /var/named/bad.zone

7. Start named.

# systemctl start named

8. Install BIND on RHEL-6 host.

# yum install bind bind-utils

9. Copy the content of your KSK .key file to clipboard.

10. Edit /etc/named.conf:

--8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<------
options {
	listen-on port 53 { 127.0.0.1; };
	listen-on-v6 port 53 { ::1; };
	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
	allow-query     { localhost; };
	recursion yes;
	forward only;

        forwarders { <IP-of-RHEL7-host>; };

	dnssec-enable yes;
	dnssec-validation yes;

	/* Path to ISC DLV key */
	bindkeys-file "/etc/named.iscdlv.key";

	managed-keys-directory "/var/named/dynamic";
};


trusted-keys {

<paste the KSK key content here in the following example format>

/*	bad.	257 3 10 "AwEAAcjgApTNTSiRSKs4vKQtjbg0rRZSH2eFze87mbRJgH8CWJrKzDT9 XorxywQuiDGDtB/MLGRumrtRQbXppgZR+5KZrwej3AzD2TFRXQokN8k9 Rrf0vuY2XEMEXgEfEHTuaNH5vzdJlv4PbHh/HDH0b2i5JuWGKbCJmt9A 6WUUkj/PsRzGXxnEqKvRjgGGsxyJsZdmR+NeOKXP7yLQej4JYsqcnd/0 ycuKjHtQn4L7fjafS8yi/75yyrcdegN97aldBZXyMOjfvkLa3Sn3WGQD qVmM/t7WlkjOhyPqBcTUCPch74YZoWph4cjnYrxWGrVQJnRku7DUUllA jzTLZxFGuH8="; */

};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

--8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<------

11. Start named.

# service named start

12. Run the query.

# dig +dnssec @127.0.0.1 bad.


Actual results:
# dig +dnssec @127.0.0.1 bad.

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.3 <<>> +dnssec @127.0.0.1 bad.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12693
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

... lines omitted ...

Expected results:
# dig +dnssec @127.0.0.1 bad.

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.3.case02507102.test.5 <<>> +dnssec @127.0.0.1 bad.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10172
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;bad.				IN	A

;; ANSWER SECTION:
bad.			300	IN	A	127.0.0.1
bad.			300	IN	RRSIG	A 10 1 300 20191207125630 20191107125630 13167 bad. Zp3I16Ot306MltsUqjwe5EpdX1cVTwXp57ruMbNLy1q4ynWvAlRf1SWS /YZHa+iEjaSN64FtNsJRQGFyBt50XqAo6jgQK/vXH8zNdTwRLrAAbcgx Rq7rauRb3lw1WV2JQJqpjxKHDE+Fw6I3mkjj4wo1U6pdUDZxF8cnqcZM bf6u9FJqjXb2MlF7ndOkP/HK41xMOfZIFOIjw6QC1Jgeal4Fqnf4aGVX dgrWDXIO2k+v512XP+C2Da2rXhEd2lXx9yO24xxQJIU7fNzLRG9UDbXZ 3473LMtWSy7zIos/7af75jQ05nPlhPWMN8jn5F0lDF3mFDYtcY5DZR55 pD6cSQ==
bad.			300	IN	RRSIG	A 13 1 300 20191207125630 20191107125630 3120 bad. WSPFR1aH12gmD/94ajKNYQeCPXmTQZHiQeGPgtvKESf364fXQC1nFYQs wRjCYnDDSEYvzcfK4zFqS1c23VnZ8g==
bad.			300	IN	RRSIG	A 13 1 300 20191207125630 20191107125630 36598 bad. UYDUjnfo0rDXc7PznBdUeQQEP8tQZ0ldJ8A2VW0BuMgcxyywaAdV+0Tl OI7SX9QUduB4+MZDz4GNHovqlb57lQ==

... lines omitted ...

Additional info:
The issue is also present upstream, however, it does not manifest itself because ECDSA256 (algo 13) is already supported. The issue can reoccur anytime for a new valid algorithm that would not yet be supported in BIND.

Comment 5 Petr Menšík 2019-11-14 08:12:02 UTC
It should be noted, more recent dnssec-signzone warns in configuration, where ZSK has different algorithm than KSK. I think this is to prevent exactly this case we need to fix here. I had to disable post sign verification tests by -P to prepare this situation, where ZSK is different algorithm than KSK.

Comment 6 Stepan Broz 2019-11-14 09:11:27 UTC
I haven't used -P and received no warnings in the reproducer:

# dnssec-signzone -A -k Kbad.+010+????? -z -3 9911c319070e83f8 -N INCREMENT -o bad -t /var/named/bad.zone

All my RRs in the zone were signed not only using ZSKs, but also the KSK (-z).

Sure, one could probably fix their own zones, but the worry is about other domains, out of control of the local administrator.

Comment 7 Petr Menšík 2019-11-14 11:58:59 UTC
I was pointed to RFC 6840 [1], which makes statement in section 5.11. The whole zone must be signed by algorithms used in DS record, pointing to DNSKEY KSK keys. That means, described configuration is invalid. It would fail not only on BIND, but also on different implementations.

In short, ZSK might include different algorithm than KSK. But MUST be signed ALSO by each algorithm of KSK.

That in practice means, it should contain two algorithms signature for each entry. In that case, it would be successfully validated by both signatures on more recent releases and just older one on RHEL6. Another option is using just new algorithm. If that is used on both KSK and ZSK, including DS record, only single signature would be required. Disadvantage would be older validators, like on RHEL6, would see such network as insecure. But would pass such data along, not emitting SERVFAIL error.

1. https://tools.ietf.org/html/rfc6840#section-5.11

Comment 8 Stepan Broz 2019-11-14 12:16:53 UTC
Thank you, Petře, for the quote and RFC reference. However, more recent implementations of BIND, both available online DNSSEC validation tools (verisign + dnsviz), and e.g. unbound, they all validate the zone without issues.

I believe it is so because the RRset was signed not only using the algorithm different from KSK/DS, but also using the KSK DNSKEY itself. Reading the RFC, that appears to be just fine -- unless I missed something else?

Comment 45 errata-xmlrpc 2020-12-16 13:25:17 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 (bind bug fix and enhancement update), and where to find the updated
files, follow the link below.

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

https://access.redhat.com/errata/RHBA-2020:5570


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