Fix #276: remove incorrect keytag+1 heuristic in find_key_in_zone#298
Open
sage-s11 wants to merge 1 commit intoNLnetLabs:developfrom
Open
Fix #276: remove incorrect keytag+1 heuristic in find_key_in_zone#298sage-s11 wants to merge 1 commit intoNLnetLabs:developfrom
sage-s11 wants to merge 1 commit intoNLnetLabs:developfrom
Conversation
…_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().
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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().