Correct DNSSEC proof validity time gap applied to header time
What the developer wrote
Authored by Matt Corallo
Correct DNSSEC proof validity time gap applied to header time
We intended to apply DNSSEC proof validity tests to constrain them
to within two hours of the latest block header time, but the code
landed with a two minute gap instead.
Given DNSSEC proof validity is usually many hours and grace periods
are used to ensure records close to expiry aren't used, this is
somewhat unlikely to have bitten anyone.
What changed, and why it matters
This commit fixes a typo-like bug in how DNSSEC proofs are checked against the latest known block time. The code was meant to allow a two-hour time window but accidentally used a two-minute window. This could cause valid DNSSEC proofs to be rejected too aggressively, especially on systems without the standard library or during fuzz testing. The commit message says this is unlikely to have affected real users because DNSSEC proofs are normally valid for many hours and safety margins are already applied.
Apply the patch to correct the time gap. Users on production std builds are not affected. Developers using no-std or fuzzing builds should update to avoid spurious rejection of valid DNSSEC proofs in onion-message DNS resolution.
Security signals we found
Time-window validation bug in DNSSEC proof verification
Intended two-hour tolerance implemented as two-minute tolerance
Affects only non-std or fuzzing build configurations
Could cause denial of valid onion-message DNS resolution paths
No cryptographic weakness or proof forgery introduced
Evidence from the diff
In lightning/src/onion_message/dns_resolution.rs, the max_time_offset used when validating DNSSEC proof validity windows was 60 * 2 (120 seconds) instead of the intended 60 * 60 * 2 (7200 seconds). The offset is zero when the std feature is enabled and not fuzzing, so production std builds are unaffected. Non-std or fuzzing builds could reject otherwise-valid proofs whose valid_from timestamp was more than two minutes but less than two hours ahead of the latest block header time. This is a logic bug in time-window validation, not a cryptographic bypass.
Changed components
lightning/src/onion_message/dns_resolution.rsOMNameResolver DNSSEC proof validity checkNon-std and fuzzing builds of LDKInspect captured patch +1 / −1
diff --git a/lightning/src/onion_message/dns_resolution.rs b/lightning/src/onion_message/dns_resolution.rs
index 8850147..385ffe3 100644
--- a/lightning/src/onion_message/dns_resolution.rs
+++ b/lightning/src/onion_message/dns_resolution.rs
@@ -640,7 +640,7 @@ impl OMNameResolver {
// complicated).
// Thus, we have to let the proof times be rather fuzzy.
let max_time_offset =
- if cfg!(all(feature = "std", not(fuzzing))) { 0 } else { 60 * 2 };
+ if cfg!(all(feature = "std", not(fuzzing))) { 0 } else { 60 * 60 * 2 };
if validated_rrs.valid_from > time + max_time_offset {
return None;
}
Why this scored 38/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.