zebra: Some DNS seeders and block explorers don't show Zebra nodes

Motivation

In #1844, we deployed a few zcashd instances on testnet, to make Zebra’s testnet tests more reliable. But those nodes aren’t showing up in the ECC’s or the Foundation’s DNS seeders.

As far as we can tell, the nodes are configured correctly, they are synced to tip, their listener ports are open, and they are advertising their external IPv4 addresses. But they don’t show up in the DNS of either seeder implementation.

Also, Zebra nodes don’t show up in some other DNS seeders or blockchain explorers.

Known Zebra Issues

Bugs to fix

Things to investigate

Other Protocol Mismatches:

List of Block Explorers

Some block explorers show up to 250 nodes.

There are about 150-200 nodes on mainnet that Zebra instances will connect to. (Recent Zebra versions are limited to 75 outbound and 50 inbound connections, but this is configurable.)

Zebra might connect to fewer nodes because it has strict latency limits.

Zebra Nodes

This block explorer shows about 65 nodes, but it includes Zebra:

No Zebra Nodes

This block explorer shows about 250 nodes:

These block explorers show connected nodes only:

Currently down:

Completed

Make Zebra have long-term connections to peers:

DNS seeder bugs:

Metrics:

Optional

We could investigate why DNS seeders ignore zebrad nodes:

Infrastructure:

  • try running zcashd on a different network, to see if Google is blocking cryptocurrency traffic
  • try to run a Zebra node with the initial testnet addresses set to some of those zcashd nodes, to make sure they respond to requests correctly

Code Review:

  • check the zcashd version of our nodes, and the versions accepted by the DNS seeders

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 17 (14 by maintainers)

Most upvoted comments

I ran rm ~/.zcash/peers.dat; ./src/zcashd -dnsseed=0 -seednode=127.0.0.1 -port=12345 on a machine with a running zebrad (not fully synced to chaintip, if that matters) and the zcashd was able to get peers from zebrad.

This is blocked by an investigation of how block explorers handle the Zcash network protocol.

We could test by configuring a publicly routable Zebra instance with the correct external IP address. And ideally outside Google cloud, to eliminate that possibility.

This is the list of conditions enforced by zcash-seeder on peers in order for their IPs to be given out:

  • The peer’s port must be 8233 on mainnet or 18233 on testnet (DNS only gives out IPs, so the port needs to be predictable).
  • The NODE_NETWORK service bit must be set.
  • The peer’s IP must be routable.
  • The peer’s client version must be at least REQUIRE_VERSION (currently 170015 in the repo, 170014 on my own seeder).
  • The peer’s block height must be at least 0 (we could bump this to require peers to be closer to the tip, but don’t currently do so).
  • The peer must be reliably reachable (this is implemented by tracking the success or failure of each connection attempt, with an exponential decay of each attempt’s weight).

However, before we get to the above checks, the seeder needs to be able to connect to the peer and perform a very minimal handshake and protocol query:

  • version / verack
  • getaddr / addr