A new node needs its first peers. XDC nodes find them through boot nodes and the discv4 table. Since 2026-11-15 an xOneRS node on main can also read a signed list of nodes from DNS: --discovery.dns enrtree://<key>@<domain>, the EIP-1459 scheme that Ethereum clients use. The client side is complete and checks every record against a pinned key. But no XDC network publishes a tree yet, so there is no URL to give it. We filed that as issue #1159.
For the other ways a node finds and keeps peers, see peer qualification and the p2p live checklist.
What is an EIP-1459 tree?
A list of node records published as DNS TXT records. The root record names the tree's top hash, a sequence number and a signature. Each entry is stored under a name derived from its own hash, so a resolver can check every entry it fetches. The enrtree:// URL carries the public key of the signer and the domain. geth's documentation describes such lists as "a fallback option when connectivity to the discovery DHT" is poor, and shows how to crawl, sign and publish them (geth DNS discovery setup).
What does xOne check before it dials a node from DNS?
- The root signature. The key recovered from the signature must equal the key in the URL.
- No rollback. A root with a lower sequence number than the last accepted one is refused.
- Entry hashes. Each entry must hash to the name it was fetched under.
- Bounds. At most 512 bytes per entry, 13 children per branch and 2,000 entries in all; a repeated name ends the walk, so a loop cannot run forever. DNS time is bounded too.
- Normal peer rules. A verified record only becomes a candidate. It still passes
--netrestrict, the trust and capacity limits and the chain handshake before the node keeps it.
The XDC ping in discv4 (packet type 5) is unchanged; DNS discovery does not touch discv4 packets.
How do I use it?
xone --network apothem --discovery.dns enrtree://<public key>@<domain>
The flag takes a comma-separated list. It is off unless set. Today the only URL in the repository is the example in the flag help, enrtree://[email protected], so there is nothing real to set it to on net2040, Apothem or mainnet.
A private network can publish its own tree with a standard EIP-1459 tool and point its nodes at it. We have not tested that with xOne.
What would it take to use it on XDC?
Issue #1159 lists the steps: a signing key kept with the release keys, a crawler that keeps only nodes that pass the handshake for the chain, a signed tree per network under a project domain, a fixed schedule that raises the sequence number, and the URL and key recorded for operators. The domain and key custody are owner decisions.
Frequently asked questions
Does xOne support DNS discovery?
Yes, on main since 2026-11-15, with --discovery.dns. It is off by default.
Is there an enrtree URL for XDC mainnet or Apothem?
No published one that we could find. Issue #1159 asks for one per network.
Can a DNS tree make my node dial a bad peer?
A DNS record only adds a candidate. The node still applies --netrestrict, its trust and capacity limits and the chain handshake, and it refuses a tree whose signature or entries do not check out.
Does DNS discovery replace boot nodes?
No. It is a second source. Boot nodes and discv4 work as before.
Sources
- bin/xone/src/flags.rs (
discovery.dns), crates/xone-net/src/enrtree.rs - PRs #979 and #1107; issues #842 and #1159
- geth DNS discovery setup
This article describes the source and evidence at its review date. Check the linked repository for current implementation and qualification status.
Explore the engineering evidenceEdit this page on GitHub opens the Markdown source (content/blog/xone-dns-discovery/index.md). GitHub may ask you to sign in. Report a correction opens a prefilled GitHub issue for this page.