Storing DNSSEC zones on the chain


#1

I’ve been looking at the numbers around storing an entire zone on the blockchain.

To frame the discussion: the cost to store 1KB of data is 640,000 gas (20000 * 1024 / 32). Taking a gas price of 32GWei (currently safe low on EthGasStation) and an ETHUSD price of $1,100 that comes out to $22 per KB.

A small zone (4 hosts) with DNSSEC comes in at about 4K wire format, which can be brought down to just over 3K with compression. But we’re still looking at $75 in today’s price to store a zone file. Updating zone files comes in at somewhere under $20.

Given this, is it realistic to expect users to store an entire DNSSEC zone on-chain? And if not, what can be done instead? Store the zone on IPFS, perhaps?

(Note that for non-DNSSEC zones this isn’t an issue because the amount of data stored is much less, and updates can be made on a per-record basis rather than having to deal with a zone as a single entity.)


#2

Hi,
Please correct me if i’m wrong,
But why would we still require DNSSEC records considering the fact that we already know for sure in order to insert said data we require a signed transaction from a wallet?
Said wallet address already has ownership of the ENS record by default, or at least has been given the rights to do so.

Later edit:
I do see the value of using DNSSEC for protecting the queried data while it’s travelling over insecure channels like when querying a public node from a mobile device, instead of your own fully synced node.

Yet storing the data in IPFS would be problematic due to the lack of encryption on the nodes. Swarm maybe ?


#3

why would we still require DNSSEC records considering the fact that we already know for sure in order to insert said data we require a signed transaction from a wallet?

DNSSEC has two purposes: to prove that the data returned is authentic, and to prove that the data returned is accurate. These are usually mixed up in DNSSEC due to the fact that an authoritative server has both jobs, but this is no longer the case with DNS over ENS.

To give an example: someone queries for foo.bar.com. A traditional DNS server could lie in two different ways:

  • Not return any data even though a record is present (or vice versa)
  • Return incorrect/misleading data

these are the situations that are avoided by using DNSSEC. Although it is possible for any user to confirm the results of a DNS query from the on-chain data to do so they need to be their own ENS resolver, not to mention the fact that they need to be aware that the data comes from the chain. So DNSSEC continues to have a place even if the DNS data itself is stored (or reference) on-chain.

I do see the value of using DNSSEC for protecting the queried data while it’s travelling over insecure channels

On-the-wire security isn’t relevant for DNSSEC; the information is public anyway. The only benefit of encrypting in flight is to hide the query.

Yet storing the data in IPFS would be problematic due to the lack of encryption on the nodes.

If the data was encrypted then the DNS servers would need to be able to decrypt it; given that we would want anyone to be able to read the data this would be counter-productive. This does, however, mean that an intelligent user could obtain the data for an entire zone if they know what they are doing. This comes down to “the blockchain is public” and I think that we will need to accept this as a consequence of people putting their data on the chain.

(Note that a record-based system would avoid the issue of exposing data as mappings in Solidity aren’t reversible, but although this is fine for traditional DNS it doesn’t work for DNSSEC due to the NSEC/NSEC3 records).