Bug 1973951

Summary:	KSK used to sign zone data instead of ZSK
Product:	Red Hat Enterprise Linux 8	Reporter:	Tomasz Kepczynski <tomek>
Component:	ipa	Assignee:	Thomas Woerner <twoerner>
Status:	CLOSED NEXTRELEASE	QA Contact:	ipa-qe <ipa-qe>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	8.4	CC:	rcritten, tapazogl, tscherf
Target Milestone:	beta	Keywords:	Reopened
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-08-03 12:55:25 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tomasz Kepczynski 2021-06-19 11:14:55 UTC

Description of problem:
After recent update (to get a fix for bug 1912556) I noticed that zones are still incorrectly signed.
To cut the story short, KSK is used to sign all records in a zone. ZSK is NOT used at all.

Version-Release number of selected component (if applicable):
ipa-healthcheck-core-0.7-3.module_el8.4.0+2334+a614829d.noarch
ipa-client-4.9.2-3.module_el8.4.0+2334+a614829d.alma.x86_64
ipa-client-common-4.9.2-3.module_el8.4.0+2334+a614829d.alma.noarch
ipa-common-4.9.2-3.module_el8.4.0+2334+a614829d.alma.noarch
ipa-server-dns-4.9.2-3.module_el8.4.0+2334+a614829d.alma.noarch
ipa-server-common-4.9.2-3.module_el8.4.0+2334+a614829d.alma.noarch
ipa-server-trust-ad-4.9.2-3.module_el8.4.0+2334+a614829d.alma.x86_64
ipa-selinux-4.9.2-3.module_el8.4.0+2334+a614829d.alma.noarch
ipa-server-4.9.2-3.module_el8.4.0+2334+a614829d.alma.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Create zone as usual.
2. Enable DNSSEC: ipa dnszone-mod <zonename> --dnssec=true
3. Check RRSIG records on any data in a zone. They refer to KSK while they should refer to ZSK (except for the DNSKEY records themselves which should be signed by KSK)

Actual results:
KSK is used to sign all zone data.

Expected results:
KSK is used to sign DNSKEYs only. ZSK is used to sign other zone data.

Additional info:
Found on Almalinux 8.4 but I am pretty sure this is also reproducible on RHEL.

See https://dnsviz.net/d/jot23.org/dnssec/ for visualization of the problem. jot23.org zone uses KSK to sign all data and ZSK is unused. For the comparison org and root zones use KSK to sign only keys (themselves and ZSK) and ZSK is used to sign other data.

Comment 1 Rob Crittenden 2021-06-20 05:17:17 UTC

Closing as a duplicate.

*** This bug has been marked as a duplicate of bug 1912556 ***

Comment 2 Tomasz Kepczynski 2021-06-20 18:18:49 UTC

Please justify why you consider this as duplicate.

I've reported both issues and this one is reported against a version which supposedly FIXES the other bug. The actual behavior is also different - bug 1912556 is about storing both ZSK and KSK as KSK keys. This one is about the fact that both are stored correctly in the zone but the zone is signed by incorrect key.

Please reopen.

Comment 4 Tomasz Kepczynski 2021-06-20 19:21:41 UTC

I've looked at the key files under /var/named/dyndb-ldap/ipa/master/jot23.org/keys (to continue with the zone mentioned in bug report).

This is KSK key file (Kjot23.org.+008+02396.key):

; This is a key-signing key, keyid 2396, for jot23.org.
; Created: 20210618041154 (Fri Jun 18 06:11:54 2021)
; Publish: 20210617204253 (Thu Jun 17 22:42:53 2021)
; Activate: 20210617204253 (Thu Jun 17 22:42:53 2021)
jot23.org. IN DNSKEY 257 3 8 AwEAAafNQRXeEmN2GTvPnyYbUE4LdkyAMUqbD3GSJsiifyj1pLrqOl7m T3lcPCD3l7gb+U7L9Ce7SiNfH/8Q5z2mG6R7Ha2wGwY6CCFpXwVcsIRi GiN0dnMOpslBOwGEpRCn2uJ9CRA9B9P7zY10sr6ZngwOxFs0DsvKlDLP RkE108liMHs8CnsMEW8bvEQPQ132wczesm0elcww0QfMjmIzT6kNP3FE 3UNbRP701SkNO9hGAdVT+flcOb4+t1fXt3A2xScoCSCMGqg0vKojYMzs zAKDG0vAPlnoTP8FDebCq4m/LJ2TPF7Par9SLgRjnu/TjNlH7m8jEE2a Ee1h3+O6VTDClYPHrIrAeV15pXmhvZJ1z/AjOM69n8o94bckj1Ishnmi KHaIphbXWoyvxWJiFQUiRP8ZsLCQnzr4ahTc29asWoP9Twj6PBKF9JkF gSXcPZfYzgbZW1R3TpZRvB2VxRsTNdmSQnn3BaPidzw7hIhMH53LXdql OyQw0D6Nul1dyw==

Please note the three dates noted above: Created, Publish and Activate.

This is ZSK key file (Kjot23.org.+008+32365.key):

; This is a zone-signing key, keyid 32365, for jot23.org.
; Created: 20210618041154 (Fri Jun 18 06:11:54 2021)
; Publish: 20210617204053 (Thu Jun 17 22:40:53 2021)
jot23.org. IN DNSKEY 256 3 8 AwEAAcmTtMxedeQ19yNB8y6XXD8GqhVyXCVBoRnoUZJsEtSeN/C3aKHZ CAt2m7HgWaApWkSiVcvEKrJs2iJKAjVqP25jmgCxnFhAHnEeUaAwuGVZ kEmRuyov2PuU+0idK+9HJaBb/i8t6Xap+ft770UtcmEZ2Ebv8vM4h8RI df/lcianHOylJaiHIYT4fKS6J59ouZJrCk4szCYrv7Zq7AInSFsTngij 98XlKrJfx/jhGJcHk37pL7MEKdGj9Ax5OcZU/V4ir1mECofyHfGUKpS2 a8QO1pVh1q4CwgQdwm1dt6NYp/NwrtzZYamEZ5ECuQfJLdIZ0nTihtPr nSLFPX4TbIU=

Please note absence of the Activate date. As far as I remember this means that bind will publish the key but it WILL NOT use it for signing. This is very likely the root cause (on the administrator level) here.

Comment 5 Rob Crittenden 2021-06-21 12:19:38 UTC

It was closed because the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1912556 hasn't shipped yet.

Comment 6 Tomasz Kepczynski 2021-06-21 19:53:43 UTC

So how did it happen that I have KSK and ZSK and not two KSKs for the above mentioned zone? The fact it was verified on newer version doesn't mean it hasn't shipped...

So maybe we can hold it in NEEDINFO and I can retest when the newer IPA version hits the download locations? I can take this responsibility and circle back once I update.

Comment 7 Theodoros Apazoglou 2021-08-03 12:55:25 UTC

We are closing the ticket because it is fixed in 8.5 (not yet released) but the test data provided in this ticket is from 8.4. If you find the same bug on 8.5 you can open a new bug ticket.