DNSSEC

[Sjors]

Brought up by @TheBlueMatt recently. Not sure what's involved for adding support.

[peterzen]

Implementing DNSSEC would indeed go a long way in plugging several vulnerabilities that are inherent in the DNS protocol, which can currently be exploited in bitcoin-seeder.

On the seeder side, the implementation would require

• support for EDNS and DO flag
• support for additional resource record types (RRs): DNSKEY and RRSIG
• A and AAAA RRs to be signed using the zone signing key (ZSK) in the form of RRSIG records
• a separate tool for generating the ZSK and the key signing key (KSK), and additional CLI options for specifying these keys

There would be additional configuration required In terms of the DNS hierarchy (chain of trust); DS records be configured for (some) of the seeder domains (bitcoin.sipa.be, bluematt.me etc). This involves additional maintenance such as key rollovers, as well.

On the bitcoind side, the resolver would require the ability to perform DNSSEC validation in lieu of the OS level stub resolvers (most of which are not yet capable of doing that). I'm not super familiar with the details of the resolver setup in bitcoind -- it may already use a DNSSEC-aware stub resolver library internally, in which case implementing additional error handling would suffice in order to gracefully handle DNSSEC related error conditions, and possibly a way to configure lax/strict DNSSEC validation.

I've proposed DNSSEC for the Decred seeder and did an initial implementation. This ended up not being rolled out as the DNS based seeding protocol is being phased out in favor of an HTTP based approach, but the research/code/documentation done may be of interest here:

• DNSSEC proposal
• Implementation in dcrseeder

In the context of the bitcoind -bitcoin-seeder interactions -- where the client performs lookups only to a small number of well-known host names, which are, in turn, controlled by trusted entities -- the implementation may be simplified in order to sidestep the complexities of full-blown chain-of-trust validation by pinning the public keys of the seeder domains into bitcoind resolver.