Add an onion message-based DNSSEC HRN Resolver #6

TheBlueMatt · 2025-06-29T01:57:49Z

Doing HRN resolution natively over the normal internet tends to be
horrendous for privacy. One of the main motivations for BIP 353 was
to limit the impacts of this by allowing for easier proxying of DNS
requests.

Here we add one such proxied request, specifically using lightning
onion messages to do the DNS requests.

tnull

Could you expand on why switching the dependency order is untennable? Wouldn't it still be possible if the OM-resolution code would live on the LDK side?

TheBlueMatt · 2025-06-30T22:02:08Z

This crate depends on the LDK Bolt11Invoice (which is already its own crate that lightning depends on) as well as the LDK Bolt12Offer type (which is in the lightning crate). I looked briefly into moving the Bolt12Offer type into a separate crate, but it would imply breaking a lot of the lightning crate up (serialization included, which means a stable API on lots of internal stuff we don't currently expose) and just didn't seem nearly worth the effort. Instead, its easy enough to just let this crate depend on lightning.

tnull · 2025-07-01T07:36:47Z

This crate depends on the LDK Bolt11Invoice (which is already its own crate that lightning depends on) as well as the LDK Bolt12Offer type (which is in the lightning crate). I looked briefly into moving the Bolt12Offer type into a separate crate, but it would imply breaking a lot of the lightning crate up (serialization included, which means a stable API on lots of internal stuff we don't currently expose) and just didn't seem nearly worth the effort. Instead, its easy enough to just let this crate depend on lightning.

Hmm, that's a bit unfortunate. I had hoped that we might eventually get around to splitting out BOLT12 types into a dedicated crate, in parallel to lightning-invoice. But I guess that ship has sailed by now..

tnull · 2025-07-01T07:56:37Z

@chuksys Mind checking out this PR as part of lightningdevkit/ldk-node#521 as we now decided to handle HRN resolution in LDK Node directly, based on the changes here?

chuksys · 2025-07-01T16:31:06Z

@chuksys Mind checking out this PR as part of lightningdevkit/ldk-node#521 as we now decided to handle HRN resolution in LDK Node directly, based on the changes here?

Sure! On it!

TheBlueMatt · 2025-07-01T19:38:23Z

Hmm, that's a bit unfortunate. I had hoped that we might eventually get around to splitting out BOLT12 types into a dedicated crate, in parallel to lightning-invoice. But I guess that ship has sailed by now..

Yea, I mean in general I'm not a fan of crate-smashing, but in this case it would have been useful...oh well.

Previously I was hoping we could swap the dependency order between LDK and `bitcoin-payment-instructions`, but that turned out to be untennable, so instead we should reuse the LDK `HumanReadableName`.

TheBlueMatt · 2025-07-02T16:30:37Z

Rebased:

diff --git a/src/onion_message_resolver.rs b/src/onion_message_resolver.rs
index 9e7fa33bc..39f42bbfd 100644
--- a/src/onion_message_resolver.rs
+++ b/src/onion_message_resolver.rs
@@ -243,9 +243,16 @@ where
                }
        }

-       fn resolve_lnurl<'a>(&'a self, _: String, _: Amount, _: [u8; 32]) -> LNURLResolutionFuture<'a> {
-               let err = "resolve_lnurl shouldn't be called when we don't resolve LNURL";
-               debug_assert!(false, "{}", err);
+       fn resolve_lnurl<'a>(&'a self, _url: &'a str) -> HrnResolutionFuture<'a> {
+               let err = "DNS resolver does not support LNURL resolution";
+               Box::pin(async move { Err(err) })
+       }
+
+       fn resolve_lnurl_to_invoice<'a>(
+               &'a self, _: String, _: Amount, _: [u8; 32],
+       ) -> LNURLResolutionFuture<'a> {
+               let err = "resolve_lnurl_to_invoice shouldn't be called when we don't resolve LNURL";
+               debug_assert!(false, "{err}");
                Box::pin(async move { Err(err) })
        }
 }

tnull

Code changes look good to me, one question.

src/onion_message_resolver.rs

tnull · 2025-07-03T10:42:16Z

src/onion_message_resolver.rs

+		let mut dns_resolvers = Vec::new();
+		for (node_id, node) in self.network_graph.read_only().nodes().unordered_iter() {
+			if let Some(info) = &node.announcement_info {
+				// Sadly, 31 nodes currently squat on the DNS Resolver feature bit


:(

(cc @chuksys, we'll need to do the same when we discover resolvers from the network graph).

tnull

Fixup looks good, feel free to squash. Two minor questions.

src/onion_message_resolver.rs

tnull · 2025-07-14T08:16:26Z

src/onion_message_resolver.rs

+		let counter = self.next_id.fetch_add(1, Ordering::Relaxed) as u64;
+		let mut payment_id = [0; 32];
+		payment_id[..8].copy_from_slice(&counter.to_ne_bytes());
+		let payment_id = PaymentId(payment_id);


Hmm, just to be clear: even though this is reusing the same type, it's completely decoupled from the LDK-internal payment_id now, no? I wonder if it would make sense to create a separate ResolutionId / RequestId type to reflect this.

Yea, its just a counter here. We could move it to a generic [u8; 32] upstream, but it is still kinda a "payment id", we want to make a payment (that's why we're resolving an HRN!) and we are assigning an ID for that payment :)

tnull · 2025-07-23T10:36:48Z

@TheBlueMatt gentle ping here

Doing HRN resolution natively over the normal internet tends to be horrendous for privacy. One of the main motivations for BIP 353 was to limit the impacts of this by allowing for easier proxying of DNS requests. Here we add one such proxied request, specifically using lightning onion messages to do the DNS requests.

TheBlueMatt · 2025-07-23T22:08:52Z

Oops, sorry. Squashed and moved to a debug assertion:

$ git diff-tree -U1 45e53e2 dc2b29a
diff --git a/src/onion_message_resolver.rs b/src/onion_message_resolver.rs
index 136af218f..5bdc7ab5e 100644
--- a/src/onion_message_resolver.rs
+++ b/src/onion_message_resolver.rs
@@ -67,3 +67,3 @@ impl Future for ChannelRecv {
 		if let Some(res) = state.result.take() {
-			state.waker = None;
+			debug_assert!(state.waker.is_none());
 			Poll::Ready(res)

TheBlueMatt force-pushed the 2025-06-onion-resolution branch from 8258114 to 8264cc1 Compare June 29, 2025 15:13

TheBlueMatt mentioned this pull request Jun 29, 2025

Correct docs and marginally expand OMNameResolver lightningdevkit/rust-lightning#3900

Merged

tnull reviewed Jun 30, 2025

View reviewed changes

This was referenced Jul 1, 2025

Switch to use bitcoin-payment-instructions lightningdevkit/ldk-node#521

Open

HRN: Emit new event type when Offer has been received and validated lightningdevkit/rust-lightning#3779

Closed

Switch to LDK's HumanReadableName instead of our own

0fdf0cf

Previously I was hoping we could swap the dependency order between LDK and `bitcoin-payment-instructions`, but that turned out to be untennable, so instead we should reuse the LDK `HumanReadableName`.

TheBlueMatt force-pushed the 2025-06-onion-resolution branch from 8264cc1 to 543c909 Compare July 2, 2025 16:30

tnull reviewed Jul 3, 2025

View reviewed changes

TheBlueMatt requested a review from tnull July 11, 2025 20:07

TheBlueMatt force-pushed the 2025-06-onion-resolution branch from 2e04f2c to 45e53e2 Compare July 11, 2025 20:09

tnull reviewed Jul 14, 2025

View reviewed changes

TheBlueMatt force-pushed the 2025-06-onion-resolution branch from 45e53e2 to dc2b29a Compare July 23, 2025 22:08

tnull approved these changes Jul 24, 2025

View reviewed changes

TheBlueMatt merged commit d071ce2 into rust-bitcoin:main Jul 24, 2025
11 checks passed

Add an onion message-based DNSSEC HRN Resolver #6

Add an onion message-based DNSSEC HRN Resolver #6

Uh oh!

Conversation

TheBlueMatt commented Jun 29, 2025

Uh oh!

tnull left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt commented Jun 30, 2025

Uh oh!

tnull commented Jul 1, 2025

Uh oh!

tnull commented Jul 1, 2025

Uh oh!

chuksys commented Jul 1, 2025

Uh oh!

TheBlueMatt commented Jul 1, 2025

Uh oh!

TheBlueMatt commented Jul 2, 2025

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tnull Jul 3, 2025

Choose a reason for hiding this comment

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tnull Jul 14, 2025

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt Jul 23, 2025

Choose a reason for hiding this comment

Uh oh!

tnull commented Jul 23, 2025

Uh oh!

TheBlueMatt commented Jul 23, 2025

Uh oh!

Uh oh!

Uh oh!

tnull left a comment •

edited

Loading