AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 36 Bitcoin

Expose DNS query failure on invalid proofs or bad BIP 353 records

Public commit record

What the developer wrote

Authored by Matt Corallo

85/100 · Strong
Expose DNS query failure on invalid proofs or bad BIP 353 records

In the previous commit we started handling the new `DNSSECError`
onion messages and using them to expose when a BIP 353 resolution
over onion messages should be considered failed due to all of our
queries having filed. However, queries can also fail if all of our
queries either errored or returned bogus proofs, or if we received
a valid proof which proved there is no BIP 353 record or `Offer`.

Here we consider such failures and expose them as well.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit changes how a Lightning node handles DNS proof responses for human-readable names (like BIP 353 addresses). Previously, if a DNS proof was invalid, expired, or didn't contain a usable Bitcoin offer, the code silently returned nothing, leaving pending payment requests stuck. Now the code explicitly marks those pending requests as failed and returns the failure to the caller. This is a reliability and minor security improvement: it prevents resolution attempts from hanging indefinitely and lets callers react to bad DNS data rather than waiting forever.

Recommended action

Review callers of handle_dnssec_proof_for_offer and handle_dnssec_proof_for_uri to ensure they handle the new Err variant appropriately (e.g., by failing the associated PaymentId and surfacing the error to the user). Confirm that removing a query context on invalid proof does not allow an attacker to exhaust retries by sending a single bogus response.

Security signals we found

01

Change from silent None to explicit Err failure reporting for invalid/expired DNSSEC proofs

02

Pending resolution state is now cleaned up and failed requests are surfaced when all query contexts are exhausted

03

Valid proof with no usable BIP 353 record or BOLT 12 Offer now returns failure instead of hanging

04

Refactoring of DNSSEC verification and URI mapping into separate helpers with clearer failure semantics

Risk score

Why this scored 36/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 6/15
Affected reach 7/15
Confidence 7/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.