Add support for resolving BIP 353 Human-Readable Names #630

chuksys · 2025-09-05T14:41:29Z

This PR makes it possible to configure LDK-Node as a HRN resolver for other nodes.

Changes

Added a bool flag named is_hrn_resolver to Config.
Based on the value of is_hrn_resolver, a new node either has the ability to send payments to HRNs or do DNS resolution for other nodes.
Expanded setup_two_nodes in the integration test suite to allow configuring a node to act as a HRN resolver for other nodes.
Added an end-to-end test-case asserting that sending to HRNs works.

This PR fixes #436

ldk-reviews-bot · 2025-09-05T14:41:32Z

👋 I see @wpaulino was un-assigned.
If you'd like another reviewer assignment, please click here.

chuksys · 2025-09-05T15:04:02Z

This PR builds upon #607. It is currently opened in draft because the end-to-end test I added runs indefinitely without resolving or timing out.

tnull

First look at the additional changes here, had to cut the review round short though.

tnull · 2025-09-10T12:56:18Z

Cargo.toml

 vss-client = "0.3"
 prost = { version = "0.11.6", default-features = false}
 bitcoin-payment-instructions = { version = "0.5" }
+lightning-dns-resolver = "0.2.0"


Please add this above to the group(s) of lightning-* imports (also the commented-out ones) and follow the scheme there.

tnull · 2025-09-10T12:57:54Z

bindings/ldk_node.udl

 	u64 probing_liquidity_limit_multiplier;
 	AnchorChannelsConfig? anchor_channels_config;
 	SendingParameters? sending_parameters;
+	boolean is_hrn_resolver;


Hmm, I think over at the first PR we discussed to introduce a dedicated config for HRN-related things, also to specify default resolvers, for example? Probably this should be part of such a config?

Yes we did - I'll re-introduce the dedicated config for HRN-related things.

tnull · 2025-09-10T13:02:40Z

src/builder.rs

-	let hrn_resolver = Arc::new(LDKOnionMessageDNSSECHrnResolver::new(Arc::clone(&network_graph)));
+	let resolver = if config.is_hrn_resolver {
+		Resolver::DNS(Arc::new(OMDomainResolver::ignoring_incoming_proofs(
+			"8.8.8.8:53".parse().map_err(|_| BuildError::DNSResolverSetupFailed)?,


We probably want to make the DNS server used configurable via the config?

Yes that makes sense - will do.

tnull · 2025-09-10T13:29:00Z

src/payment/unified.rs

+			Error::HrnResolverNotConfigured
 		})?;

+		println!("Parsing instructions...");


Oh, please remove any printlns.

Yeah - will do, just left this here because I am still debugging the issue with the end-to-end test not resolving HRNs, erroring out or timing out.

tnull · 2025-09-10T13:31:06Z

src/builder.rs

-		peer_manager_clone.process_events();
-	}));
+	let hrn_resolver = match resolver {
+		Resolver::DNS(_) => None,


Huh, so if we're resolving for others, we won't be able to send to HRNs ourselves?

From my understanding, it seems this is the case. The onion messenger can take only one type of dns_resolver at a time - either the one sending out the query or the one handling the query and responding with the proof. If our node is configured to resolve for others, we'd have to pass the appropriate resolver to the onion messenger, preventing us from sending to HRNs ourselves.

tnull

Was able to reproduce the behavior you were running into (see below).

tnull · 2025-09-17T12:12:33Z

tests/integration_tests_rust.rs

+	// Sleep one more sec to make sure the node announcement propagates.
+	std::thread::sleep(std::time::Duration::from_secs(1));
+
+	let hrn = "chuks@peepswire.com";


I was now able to reproduce the infinite loop you were seeing, and it seems that this HRN doesn't have a valid DNSSEC proof attached (i.e., we hit the else clause of this case in the DNS resolver: https://github.com/lightningdevkit/rust-lightning/blob/674861d06fb333222cff9c2caaeb3783728672a1/lightning-dns-resolver/src/lib.rs#L134). If I plug in matt@mattcorallo.com the resolution actually succeeds, however, it of course doesn't have any suitable regtest payment instructions attached. I'm not fully sure if there are any plans for local-testing end-to-end lightning-dns-resolver (cc @TheBlueMatt ?), but we may indeed need to spin up our own DNS server (instead of using 8.8.8.8) and publish a correct DNSSEC proof to make the test fully work end-to-end in regtest.

Also opened an issue here: rust-bitcoin/bitcoin-payment-instructions#11

We do have end-to-end tests in lightning-dns-resolver tho they are a bit awkward. The hook ChanelManager::testing_dnssec_proof_offer_resolution_override but then do a totally normal resolution (which must pass DNSSEC validation) and then swap out the returned offer, see https://github.com/lightningdevkit/rust-lightning/blob/main/lightning-dns-resolver/src/lib.rs#L387

Thanks @tnull and @TheBlueMatt - I'll look into ChannelManager::testing_dnssec_proof_offer_resolution_override and also explore spinning up our own DNS server to publish a correct DNSSEC proof.

For consistency, probably good to just use matt@mattcorallo.com as the test string, let it do DNS resolution, then have a similar override hook in ldk-node.

Okay, thanks.

We do have end-to-end tests in lightning-dns-resolver tho they are a bit awkward. The hook ChanelManager::testing_dnssec_proof_offer_resolution_override but then do a totally normal resolution (which must pass DNSSEC validation) and then swap out the returned offer, see https://github.com/lightningdevkit/rust-lightning/blob/main/lightning-dns-resolver/src/lib.rs#L387

It seems that even with a similar testing hook (as added here: d5c46a3), we're hitting a ParseError::WrongNetwork error because the resolved payment instruction isn't for regtest. This is happening at this line: https://github.com/rust-bitcoin/bitcoin-payment-instructions/blob/74003b498b9bf90497457b1aab03bac48576892c/src/lib.rs#L520C3-L520C40 when testing without a regtest instruction on the DNS server.

This confirms the issue is around network mismatch, as the matt@mattcorallo.com instruction is for mainnet but not regtest.

The two main options seem to be:

Add regtest instructions to the DNS server where instructions for matt@mattcorallo.com currently reside.

Spin up our own DNS server specifically for regtest testing purposes.

Given the need for a stable and predictable environment for end-to-end testing, spinning up a dedicated DNS server seems like the more robust solution, as it gives us full control over the DNSSEC proofs and the regtest payment instructions.

However, if there are existing plans or infrastructure to easily add regtest instructions to the current server, that would be simpler.

What do you think is the preferred path forward? (cc @TheBlueMatt)

I was able to resolve this by swapping the resolved offer with a test offer as previously suggested and also switching the network to bitcoin mainnet when parsing a hrn in a test, in order to match the network of the payment instruction mapped to matt@mattcorallo.com and avoid hitting the WrongNetwork error.

tnull · 2025-09-17T12:13:21Z

src/payment/unified.rs

+		println!("Parsing instructions...");
+
+		let instructions =
+			PaymentInstructions::parse(uri_str, self.config.network, resolver.as_ref(), false)


We def. need to wrap this in a tokio::timeout to abandon the future if it never returns.

This rename reflects that this module is a unified payment interface for both QR code payments and HRN payments passed in as a string without scanning a QR code

…UnifiedPaymentResult These renamings are necessary to reflect the expanded responsibilities for this module.

This commit adds a HRN Resolver to the Node struct which will be useful for resolving HRNs when making BIP 353 payments. It also passes the HRN Resolver into UnifiedPayment.

…353 HRNs

This commit ensures that when using the unified API to send to a HRN, we use pay_for_offer_from_hrn

This commit allows us to enable our node to either be able to send HRN resolution requests or acts as a resolver for 3rd party nodes We also pass HRNResolver as an optional parameter to Node

This commit adds an end-to-end test that asserts that HRNs are properly parsed and resolved, and sending to the corresponding offer works

tnull

Very cool! Lets move all the testing-related changes behind a cfg(hrn_tests) flag.

Now that we have a working end-to-end test I think we'll wait until 0.7 ships (likely ~next week) before moving forward with #666 and then this PR after it lands. This way, all the necessary changes would land for v0.8, including the payment metadata store which we'll probably still want to use to store the HRN post-resolution.

This unfortunately also needs a rebase now, sorry!

tnull · 2025-11-03T13:49:00Z

src/lib.rs

 }
+
+/// Testing utils for DNSSEC proof resolution of offers associated with the given HRN.
+pub mod dnssec_testing_utils {


Let's introduce a new cfg(hrn_tests) gate and move all the testing-related changes behind it, to make sure we don't ever run it in production code.

tnull reviewed Sep 10, 2025

View reviewed changes

tnull self-requested a review September 17, 2025 11:11

tnull reviewed Sep 17, 2025

View reviewed changes

tnull mentioned this pull request Sep 17, 2025

PaymentInstructions::parse never returns if OM-based HRN lookup fails rust-bitcoin/bitcoin-payment-instructions#11

Closed

chuksys force-pushed the add-support-for-resolving-hrns branch from 0517dbc to 0b0430c Compare October 16, 2025 13:39

chuksys added 11 commits November 2, 2025 20:16

Rename unified_qr to unified

dd725bc

This rename reflects that this module is a unified payment interface for both QR code payments and HRN payments passed in as a string without scanning a QR code

rename UnifiedQRPayment to UnifiedPayment, rename QRPaymentResult to …

02ed479

…UnifiedPaymentResult These renamings are necessary to reflect the expanded responsibilities for this module.

add bitcoin-payment-instructions to cargo.toml

7e6e7e7

Add hrn_resolver to Node and pass into UnifiedPayment

6d20a9e

This commit adds a HRN Resolver to the Node struct which will be useful for resolving HRNs when making BIP 353 payments. It also passes the HRN Resolver into UnifiedPayment.

Refactor unified.rs to support sending to BIP 21 URIs as well as BIP …

2c809b1

…353 HRNs

Fix typo in unified_payment send test and improve test name.

8696269

Switch to explicit imports in unified.rs mod tests

9b7584b

Use the pay_for_offer_from_hrn method from LDK upstream

3e30347

This commit ensures that when using the unified API to send to a HRN, we use pay_for_offer_from_hrn

Add config options for HRN-related settings

bd668f6

Pass HRNResolver or DomainResolver into OnionMessenger

ec435ce

This commit allows us to enable our node to either be able to send HRN resolution requests or acts as a resolver for 3rd party nodes We also pass HRNResolver as an optional parameter to Node

Wrap payment instructions parsing in tokio timeout

4c1a03a

chuksys force-pushed the add-support-for-resolving-hrns branch 3 times, most recently from 4b5a6cd to 8c4ca25 Compare November 3, 2025 01:50

chuksys marked this pull request as ready for review November 3, 2025 01:52

ldk-reviews-bot requested a review from wpaulino November 3, 2025 01:52

chuksys force-pushed the add-support-for-resolving-hrns branch from 8c4ca25 to 4f1beac Compare November 3, 2025 02:23

Add end-to-end test for HRN resolution

49f4013

This commit adds an end-to-end test that asserts that HRNs are properly parsed and resolved, and sending to the corresponding offer works

chuksys force-pushed the add-support-for-resolving-hrns branch from 4f1beac to 49f4013 Compare November 3, 2025 03:03

chuksys requested a review from tnull November 3, 2025 07:11

tnull removed the request for review from wpaulino November 3, 2025 13:51

tnull reviewed Nov 3, 2025

View reviewed changes

Add support for resolving BIP 353 Human-Readable Names #630

Are you sure you want to change the base?

Add support for resolving BIP 353 Human-Readable Names #630

Uh oh!

Conversation

chuksys commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Uh oh!

ldk-reviews-bot commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chuksys commented Sep 5, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chuksys Oct 20, 2025 • 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

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!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

chuksys commented Sep 5, 2025 •

edited

Loading

ldk-reviews-bot commented Sep 5, 2025 •

edited

Loading

tnull left a comment •

edited

Loading

chuksys Oct 20, 2025 •

edited

Loading

tnull left a comment •

edited

Loading