Check if DNS seeder are working correctly and fix if required

[conradoplg]

Motivation

I think there's an issue with our DNS seeder, but I couldn't manage to confirm it 100% (could be a DNS or network issue on my side).

To reproduce it:

• Start Zebra with only mainnet.seeder.zfnd.org:8233 in initial_mainnet_peers
• All connection attempts will fail, or maybe a single one will work

That would indicate that the DNS seeder is reporting offline peers for some reason.

Specifications

Designs

• Try to reproduce the issue
• If it's reproducible, investigate it and try to fix it
• Create a new ticket if the issue is too complex

Related Work

[str4d]

Has the seeder's advertised protocol version been updated to 170100?

[conradoplg]

Has the seeder's advertised protocol version been updated to 170100?

Yep, but I also tested this before NU5 activation, and the peers that are being returned by our seeder do not seem to respond to the TCP connection attempt by Zebra at all, so it doesn't seem to be a protocol version issue

[teor2345]

I also reproduced this yesterday, but with a few nodes on the correct protocol version.

I think we should deploy a new seeder instance, swap over the fixed IP, and see if it has better peers.

[teor2345]

I think it's likely to be this known seeder issue:
Enforce the minimum protocol version

[conradoplg]

I think it's likely to be this known seeder issue: Enforce the minimum protocol version

I wonder about this, though. I see that Zebra attempts to connect to the IPs returned by the seeder but the TCP connection fails to open. If it were just outdated peers, it would fail after the Zcash handshake, right?

In any case I'll try to investigate this more thoroughly.

[conradoplg]

I think I found the issue.

Our seeder adds any connectable peer to the address book, even if it uses a non-default port.

However, when Zebra connects to an IP from the DNS seeder, it always use the default port since there's no way to know the port of the peer through DNS. And there seems to be a lot of nodes using non-default ports (mostly 16125)

I'll push a PR soon to fix this, but I'd like to check if my reasoning is correct.