lightning
lightning copied to clipboard
ElementsProject
announce-addr: address 'dns:port' is not announceable
Trying to update c-lightning from 0.10.2 to 0.12.1
Get this error during start:
lightningd: /root/.lightning/config line 9: announce-addr: address 'btcpay763334.lndyn.com:9735' is not announceable
My config is the following
bitcoin-datadir=/etc/bitcoin
bitcoin-rpcconnect=bitcoind
experimental-offers
proxy=tor:9050
bind-addr=0.0.0.0:9735
network=bitcoin
announce-addr=btcpay763334.lndyn.com:9735
announce-addr=uewlcjmuuwcgs43lpcc7d64k2pf4xs7yyer7ztsq6cblyjxue3bc35qd.onion:9735
rpc-file=/root/.lightning/lightning-rpc
What should I do instead?
In our unit tests, clightning doesn't work either /root/.lightning/config line 4: announce-addr: address 'lightningd_dest' is not announceable
Indeed, they broke it at some point. I used to have DNS names in my announce-addr= config lines, but they stopped working, and I had to start hard-coding IP addresses there, which is brittle.
Supposedly there's been defined a new node announcement type that allows gossiping DNS names in addition to IP addresses. Looking forward to that.
That's nice feature, but for the time being that would be nice to have a work around as we can't update :(
That is correct, we had to disable automatic resolution, to allow non-resolved hostnames to be added and announced. If we were to resolve on our end we'd replace what is supposed to be a dynamic address that changes with DNS into a static IP that'll not work when the address changes (ISP renewing lease).
I'm sure @m-schmoock can explain it in detail, but the tldr is that some implementations didn't like us announcing the new address type (DNS symbolic names) and were dropping our node_announcements so we had to temporarily disable it.
This is a regression, I had not appreciated that we would now treat names as literals to announce.
Until DNS-name address records become widely supported, we should always turn it to IP address unless overridden somehow!
Before DNS name gossip, if I remember, the DNS name were resolved into IP and those were what got gossiped.
I understand the problem with ISP dynamic ip, so I am happy about DNS announcement, it's shame it can't be enabled because of other implementations for now. But rather than disabling it, you should probably fallback to IP announcement for those hosts like before.
If there is a patch to restore previous behavior, I would be happy to just take it and use it on our distrib, so at least we can up to date with latest clightning versions.
I'm sure @m-schmoock can explain it in detail, but the tldr is that some implementations didn't like us announcing the new address type (DNS symbolic names) and were dropping our
node_announcementsso we had to temporarily disable it.
This LND issue has been resolved, and on current master the gossip announcement of type DNS is already non-experimental anymore. ( e0d6f3ceb connectd: DNS Bolt7 #911 no longer EXPERIMENTAL )
Still nothing here? please we have many people who can't update c-lightning because of this. :(
Forget about it, we will just remove announce-addr for all of our users.
Actually, we can't remove announce-addr as our unit tests depends on it too much, and BTCPay Server also depends on it to fetch the node information to show to the customers in the checkout page. We are stuck until you fix it.
Okay @NicolasDorier I looked into it briefly.
Version 0.12.1 still has DNS support experimental, thus the is not announceable. The next release will actually announce a DNS address descriptor type 5 (without resolving it locally). If compiled with experimental features, this error message should be gone already.
What older version of clightning did was to try to resolve a DNS name these IPs would have then been announced once statically (without checking for changes ever, this is another topic).
Maybe we can do the following to 'fix' the breakage: If a DNS name is given, announce it as an DNS name AND ALSO, if it resolves to a local interface, the statically old fashioned way.
In our unit tests, clightning doesn't work either
/root/.lightning/config line 4: announce-addr: address 'lightningd_dest' is not announceable
In your quote above I wonder what the is 'lightningd_dest' (DNS?) is supposed to be, is this some alias from the test framework? In any case that would currently be treated as a possibly valid DNS name.
In your quote above I wonder what the is 'lightningd_dest' (DNS?) is supposed to be
It's the Docker hostname of the Core Lightning container in our test setup.
@cdecker @rustyrussell I did some mainnet testing to see if the network is finally able to propagate DNS names in node_announcements. Turns out, it still doesn't. Thing is, the experimental flags have been removed on master already, this would mean the feature would go live with the next release.
Anyone using DNS names will effectively make their node disapear, as node_announcements that contain regular IP/Tor entries along with DNS names will be dropped by vast parts of the network.
We could re-experimentalize including DNS names in node_announcemt and also add old fashined IP entries for if DNS hostname has been used for announce-addr. Then we can wait a couple of month to see if the network finally gets compatible with this and re-evaluate this decision
Try to kick off some discussion about this in https://github.com/ElementsProject/lightning/issues/5657
Wouldn't it make sense to construct and sign two node announcements: one containing the DNS names and the other containing the addresses to which those names resolve? Send out both announcements. Peers that don't support DNS names will drop the announcement containing them and propagate the other one. Nodes that support the names will replace the announcement containing addresses.
Interesting thought. But one is not supposed to send out gossip too quickly. This applies to channel and node announcements. Otherwise on gets throttled (and again unvisible).
Also the recent update that's parseable/readable invalidates the last one. So then only the DNS name would be seen, which is not nice when you maybe also want to announce a TOR address (for connectivity).
So alternate which one you're sending every day or whatever the period is. And include your Tor address in all of your announcements. The IP-containing announcements that you send should always have serial numbers / expiration times that are less than that of the name-containing announcement you most recently sent, so that nodes that support name-containing announcements will drop your no-name announcements on the spot as stale.
Note that actually we aren't using announce-addr for announcing on the p2p network.
We are using it for showing the host part of the node info to customers of merchant wishing to open a direct channel.
@NicolasDorier
Note that actually we aren't using
announce-addrfor announcing on the p2p network. We are using it for showing the host part of the node info to customers of merchant wishing to open a direct channel.
Can you elaborate on this? Do you mean you want to use it so getinfo returns something different on the address part?
Also, check out recent version 22.11, it will accept DNS names for announce-addr again (without experimental) and announce this as a proper DNS name.
Checking 22.11 now.
Can you elaborate on this? Do you mean you want to use it so getinfo returns something different on the address part?
I mean that the reason I use announce-addr isn't anything to do with P2P. I just use it so getinfo returns a public endpoint that customers can use to create a channel with the merchant.
Doesn't work lightningd: /root/.lightning/config line 4: announce-addr: address 'lightningd_dest' is not announceable
Our address lightningd_dest is an address on the local network.
I would expect that getinfo returns us a presentable .address.address (either the IP resolved from the DNS we passed to announce-addr, or the DNS itself).
There are too many problems now to be able to update:
- The requirement to have jsonrpc v2, (we will workaround and communicate that we need
allow-deprecated-apis, but we can't use v2 support until we are certain v1 isn't used by BTCPay Server users anymore, so I guess it's 1-2 years down the road) - Unable to build on arm32
- The inability to get a presentable node info string with a domain name or even IP caused by this issue.
@NicolasDorier
The 'lightningd_dest' is not announceable issue is because lightningd_dest isn't a valid IPv4/v6/Tor address nor DNS hostname. DNS addresses must not contain underscores, only lowercase a-z, 0-9, - (hyphen), . (dots for separation).
If you use a valid hostname, at least this issue is gone.
Keep in mind that characters like _ underscores work when used in /etc/hosts aliases, but thats not hostname compliant.
See https://man7.org/linux/man-pages/man7/hostname.7.html
@m-schmoock I tried, I confirm you are right. We still have problems to update, but this is unrelated to this issue. I close this one.
- The requirement to have jsonrpc v2, (we will workaround and communicate that we need
allow-deprecated-apis, but we can't use v2 support until we are certain v1 isn't used by BTCPay Server users anymore, so I guess it's 1-2 years down the road)
Ok, is there an issue for this?
Deprecations are a tool to make lives easier, not a rigid stick to beat developers with: if enforcing this causes problems we should have delayed removal until that was fixed!
DNS addresses must not contain underscores
That's not true. Registered domain names must not contain underscores. DNS records can contain underscores, and in fact that's a common pattern in several standardized protocols. For example, DMARC records are named _dmarc, and SRV records are in the _tcp and _udp subdomains. DNS host names can certainly contain underscores, and in fact there are two devices on my home network whose hostnames contain underscores, and I didn't name them myself: Tesla_Model_3 and SimpliSafe_Basestation. So CLN is in the wrong on this point.
DNS addresses must not contain underscores
That's not true. Registered domain names must not contain underscores. DNS records can contain underscores, and in fact that's a common pattern in several standardized protocols.
Well okay, but does it make sense to announce hostnames from your local network?