DNS resolution of bootnode hostnames not working #31208
Comments
|
@powerslider could you post a test of another docker container resolving that name? I just want to rule out the basic. |
|
meet same issue, I can ensure it's caused by this pr #29801 @powerslider @fjl it must a bug which comes from this pr, in the code, it just parse the ip from the encoded string, do nothing. and in check logic, if it does not have ip, then exit. |
|
In #30822, we changed the DNS logic so that resolution has to happen explicitly. It is only implemented for static nodes ( |
So you do you mean for now we can not add bootnodes with dns in cli command line? Do you have some plan to support it in future? |
|
The problem is that this is a regression. It worked in v1.14.X where DNS resolution happened when config was parsed. We have been running DNS based bootnodes at Omni Network for a long time. We cannnot upgrade to v1.15 due to this regression. The root cause of the issue is in Note that The solution is to either fix ValidateComplete to not error if hostname is set but not IP. Or to call some other method in |
|
I looked into it and it's not so easy to fix. As @corverroos mentions, we used to resolve the hostname at parsing time but this is not done anymore. The resolve was moved to dial time for TCP connections because it will keep retrying the resolve that way. For bootstrap nodes, I also think it'd be good to retry the resolve occasionally. |
|
@fjl What about a simple workaround to manually resolve bootstrap enode DNS to IP on startup? So calling similar logic to Re-resolving bootstrap DNS definitely sounds better, but that isn't a blocker for us at the moment. |
|
When we updated our op-geth dependency on go-ethereum and lost the DNS resolution, we added it back for our consensus client op-node with ethereum-optimism/optimism@f571e33 - however this only works for old |
|
In order to get around this at Unichain we've had to add some logic in our startup scripts which manually resolves domain names using @fjl you mention the change was introduced to help in containerized environments, which makes sense. Our nodes run in a containerized environment but we are now needing to add this extra logic to implement DNS-resolution for all of our static peers. I don't know if it's related or not, but we found that |
|
For |
- removed in ethereum/go-ethereum#30822 in favor of on-demand runtime dialling - reported to have removed bootnodes DNS resolution at ethereum/go-ethereum#31208 - possibly broke DNS resolution for other methods of adding peers
- removed in ethereum/go-ethereum#30822 in favor of on-demand runtime dialling - reported to have removed bootnodes DNS resolution at ethereum/go-ethereum#31208 - possibly broke DNS resolution for other methods of adding peers
- removed in ethereum/go-ethereum#30822 in favor of on-demand runtime dialling - reported to have removed bootnodes DNS resolution at ethereum/go-ethereum#31208 - possibly broke DNS resolution for other methods of adding peers
Bump geth to v1.15.5. Note that geth `config.toml` now supports the previously flags-only `--nat` and `--metrics`: ``` [Node.P2P] NAT = any|extip:1.2.3.4 [Metrics] Enabled = true ``` This geth version is required to query pectra chains (holesky/sepolia). Note the [regression](ethereum/go-ethereum#31208) and workaround of using IPs for geth bootnodes. issue: none --------- Co-authored-by: Christian Müller <christian@omni.network>
System information
Geth version:
v1.15.2OS & Version: macOS Sequoia 15.2
Expected behaviour
When I start a geth node with configured bootnode addresses in the format of
enode:<public_key>@<hostname>where thehostnameis a valid DNS resolvable address I expect the node to join the network and operate normally. NOTE: We are not specifying IPs because we want to rely on the dynamic DNS resolve functionality introduced in v1.15.0.Actual behaviour
After I run the geth node with the above mentioned configured bootnodes using
docker:I am unable to start the node because of getting:
Steps to reproduce the behaviour
Given the following
[Node.P2P]section ofconfig.tomlfile:and running the node via
docker:I get:
Backtrace
The text was updated successfully, but these errors were encountered: