<domain> is very limited in LUD-16, add additional DNS record types to allow flexibility

[AndySchroder]

In LUD-16, you have <domain>. It is my assumption (although it's not clearly defined) that this is referring to the DNS A record for the domain? This is very inflexible. It is every likely that one may not want to run a service on the host defined by the DNS A record to serve lightning invoices. It is very likely that their main website will be hosted there. E-mail has MX records for this very purpose. I propose that you create a new optional DNS record type that defines the host that should be contacted to request the invoice from. If that record is defined, then don't use the A record. If the record isn't defined, use the A record (just like e-mail).

Additionally, you may want to give the user the flexibility on what TCP port is used to connect to instead of port 80 or 443. You might want to also define a DNS SRV record that allows this to be changed. This can be very useful to people who have only one IP address but still want to run the invoice serving service on a different machine than their website.

[fiatjaf]

I agree with you. It would have been better to make the server listen on a subdomains like _lud16 and everybody just ping that subdomain instead of the main domain. But it's too late to change this now.

Luckily there are reverse proxies out there that can route requests from a central domain to other domains and that's what you can do if you want to run separate servers.

[markjr]

Is it too late to add a provision to the spec so that you can make a DNS lookup on the subdomain (i.e. TXT record on _lud16.<domain> ) and get the lightning URL from there?

[markjr]

Luckily there are reverse proxies out there that can route requests from a central domain to other domains and that's what you can do if you want to run separate servers.

This still won't help the situation, wouldn't that force everybody to use the domain name of the reverse proxy?

Ideally this would work so that people can simply use their email addresses as lightning addresses.

[AndySchroder]

I am also confused about that. The word "central" in your comment is a red flag to me.

I also don't think a specific subdomain like _lud16 makes sense. The operator should be able to choose whatever domain name to use, and as I said in my original comment, I think there should be a separate record that defines what that domain (potentially a subdomain) might be. I think a TXT record is probably too general of a record type. In reality, an SRV record should be able to hold both domain name and port of the server that is used for lnurl. My original comment suggested two records may be necessary, but I now realized that a SRV record could actually store it all.

[markjr]

I think a TXT record is probably too general of a record type. In reality, an SRV record should be able to hold both domain name and port of the server that is used for lnurl. My original comment suggested two records may be necessary, but I now realized that a SRV record could actually store it all.

I've been thinking about this since 2017 and at one point started working on an outline for a "BCRPTR" RRtype spec (Blockchain Resource Pointer) and it roughly mimicked the SRV format.

SRV records have a very specific format and meaning, TXT records have the flexibility to craft a format better suited (think SPF records).

But this may be overthinking it. I think the best approach would be something that could work across all protocols by convention more than anything else:

So, underscore scoping could actually work quite well here:

Given: markjr@myprivacy.ca

Instead of coming up with something complex like a SRV record or TXT specification, you just use:

$ORIGIN myprivacy.ca.

_lud16.markjr IN TXT "https://my.ln-node/.well-known/lnurlp/markjr"

_ens.markjr IN TXT "0xEbE7CcC5A0D656AD3A153AFA3d543160B2E9EdFb"

_btc.markjr IN TXT "bc1qu059yx6ygg9e6tgedktlsndm56jrckyf3waszl"

You wouldn't even need a DNS RRType down the road because I think this could get the job done as is.

[markjr]

I wrote up an article on this for Bitcoin Magazine

https://bitcoinmagazine.com/technical/simplifying-bitcoin-addresses-dns

[louneskmt]

I strongly support the idea of defining an SRV Record on <domain> in order to specify which target to use for LUD16, instead of using the main domain by default.

_lud16._tcp.<domain>. 1800 IN SRV 0 0 <port> <target>.

For example:

_lud16._tcp.louneskmt.com. 1800 IN SRV 0 0 443 lud16.louneskmt.com.

But I guess it is too late to change the specs.

[AndySchroder]

SRV records have a very specific format and meaning, TXT records have the flexibility to craft a format better suited (think SPF records).

But this may be overthinking it. I think the best approach would be something that could work across all protocols by convention more than anything else:

What protocols are you trying to work across?

So, underscore scoping could actually work quite well here:

Given: markjr@myprivacy.ca

Instead of coming up with something complex like a SRV record or TXT specification, you just use:

SRV seems pretty simple. What you have below seems to be a TXT specification.

$ORIGIN myprivacy.ca.

_lud16.markjr IN TXT "https://my.ln-node/.well-known/lnurlp/markjr"

Not sure why you want to use DNS to register every single user on a domain. Seems like the DNS should be used to point to a specific server that is general enough for all users. It doesn't make sense to me to bloat DNS with information about all users.

_ens.markjr IN TXT "0xEbE7CcC5A0D656AD3A153AFA3d543160B2E9EdFb"

No idea what this is referring to.

_btc.markjr IN TXT "bc1qu059yx6ygg9e6tgedktlsndm56jrckyf3waszl"

What's the motivation to add a static on-chain address to DNS, escpecially for something related to lightning? It's discouraged to re-use addresses and I don't know why we'd want to use DNS as a way to continuously publish new addresses that everyone can read.

You wouldn't even need a DNS RRType down the road because I think this could get the job done as is.

Why would a new RRType be needed if SRV works (now, or down the road)?

[AndySchroder]

I strongly support the idea of defining an SRV Record on <domain> in order to specify which target to use for LUD16, instead of using the main domain by default.

_lud16._tcp.<domain>. 1800 IN SRV 0 0 <port> <target>.

For example:

_lud16._tcp.louneskmt.com. 1800 IN SRV 0 0 443 lud16.louneskmt.com.

But I guess it is too late to change the specs.

I like this proposal. It seems simple, yet general enough.

[markjr]

I suggested TXT records instead of SRV records because using SRV is still overthinking it. There are at least two additional fields in SRV which would be largely unused but must be present.

With a TXT record and using the underscore scoping you can just is the RHS to get specify exactly what you're referencing on the LHS:

_lud16 = location of the lightning URL
_btc = straight up BTC address
_ens = ethereum name service address/domain

I mentioned these wider examples to show how we can get from using a format we're all familiar with name@example.com to specify resources across numerous use cases, blockchains, layer 1, smart contracts, etc.

You could use your email address, for example, to specify multiple attributes about that identity endpoint. The protocols around each mechanism (Lightning, ENS resolvers, Bitcoin wallet providers) would just need to know what to lookup, and get the answer for what their destination is.

[AndySchroder]

What is wrong with the priority and weight fields of SRV records? Aren't these valuable scaling features for large domains?

Not sure how the ethereum name service has any relevance here.

I agree that your _btc record would be best as a TXT record, but as mentioned, I think it's out of scope of the LNURL specification, and I don't even think it belongs in DNS at all. If we want to provide a way to point to a service that provides an on-chain bitcoin payment address in addition to a lightning address (in case you want to make a big payment that won't work over lightning), that could make sense (and I think would belong in an SRV record not TXT record), but BOLT 11 provides a fallback on chain address option, so I don't think it's actually necessary to have two services.

[TheBlueMatt]

While you're at it, it would be a relatively large security upgrade to offer a DNSSEC-secured lookup over the current HTTPS (TLS-CA)-secured ones. This could come in many forms, a simple way would be DANE, which most TLS libraries offer support for. The simplest protocol, of course, would just be to have clients request the invoice through the DNS itself - by having a client do a request to a random subdomain and get a TXT record back, of course the server side of that is a bit more complicated.

[fiatjaf]

Most TLS libraries offer support for? When you last mentioned DANE here in some other issue I looked around for how to implement that and barely could find any information. Ended up with a single Golang library mostly abandoned that no one seemed to be using. What did I search wrong? Where can I find some example implementations?

[TheBlueMatt]

No idea about what's available for golang, but openssl (and presumably its derivatives) and gnutls both support DANE. If you can get the authenticated TLSA DNS record its also pretty easy to apply DANE checks against any TLS library that exposes the certificates - its ultimately standard TLS with certificate pinning that opts you out of the standard TLS CA cluster*