Skip to content

Fix #276: remove incorrect keytag+1 heuristic in find_key_in_zone#298

Open
sage-s11 wants to merge 1 commit intoNLnetLabs:developfrom
sage-s11:fix/276-find-key-in-zone-keytag-plus-one
Open

Fix #276: remove incorrect keytag+1 heuristic in find_key_in_zone#298
sage-s11 wants to merge 1 commit intoNLnetLabs:developfrom
sage-s11:fix/276-find-key-in-zone-keytag-plus-one

Conversation

@sage-s11
Copy link
Copy Markdown

@sage-s11 sage-s11 commented Mar 8, 2026

When searching for a key's public RR in the zone, find_key_in_zone() also accepted keys with keytag == pubkey_gen_keytag + 1, based on an old assumption that KSK keytags are always ZSK keytag + 1.

This is not guaranteed and causes a bug: if the KSK's keytag happens to equal ZSK keytag + 1, the KSK is incorrectly returned as the ZSK's public key match, and is subsequently excluded from the signed zone as a standalone DNSKEY record, breaking DNSSEC validation.

Fix by matching on exact keytag only. The SEP flag (LDNS_KEY_SEP_KEY) is the correct way to distinguish KSK from ZSK, and the caller already handles KSK lookup separately via ldns_key_flags().

…_zone

When searching for a key's public RR in the zone, find_key_in_zone()
also accepted keys with keytag == pubkey_gen_keytag + 1, based on
an old assumption that KSK keytags are always ZSK keytag + 1.

This is not guaranteed and causes a bug: if the KSK's keytag happens
to equal ZSK keytag + 1, the KSK is incorrectly returned as the ZSK's
public key match, and is subsequently excluded from the signed zone as
a standalone DNSKEY record, breaking DNSSEC validation.

Fix by matching on exact keytag only. The SEP flag (LDNS_KEY_SEP_KEY)
is the correct way to distinguish KSK from ZSK, and the caller already
handles KSK lookup separately via ldns_key_flags().
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant