Proposal: An attestation-based DNSSEC implementation

[nick.eth]

While I’m delighted we finally have DNSSEC support launched for all top-level domains that support it, everyone will be aware that with gas prices as they are, the cost of claiming a DNS domain on ENS can be prohibitive for many. I’d like to outline an idea for an alternate way of handling this that can massively reduce the gas costs of claiming a DNS domain, at the cost of a change in the security model.

The basic idea is to use a “bonded attester” model. Anyone wishing to can put down a deposit - for the sake of argument, say it’s 100 ETH. Once they are bonded, they can sign DNSSEC proofs with their key, attesting that the signed message validates correctly. The DNS registrar will accept such messages, and only needs to validate the attester’s signature, and that they still have a valid deposit, before acting on the message. The entire message (containing all the DNSSEC proofs) and the signature are then emitted as an event. This would reduce the cost of claiming a DNS-based name to somewhere in the region of 100k gas.

Anyone can call a slashing method on the registrar, passing in a signed message; the registrar then runs the existing DNSSEC validation code, and if it does not validate, slashes the attester’s deposit, burning most but giving a portion to the submitter. A backup option, validating an entry the ‘old fashioned’ way and updating it without requiring a signature, will also be provided.

Both signer and watchtower processes will be very simple to implement. A signer simply receives a message that the user claims is a valid DNSSEC proof, and calls the validation method on the registrar, signing it only if the registrar claims it to be accurate. The signer doesn’t have to understand any of the signing process - only how to call the registrar. Likewise, a watchtower process can simply watch for events, and perform a local call to the registrar for each one, looking for any that don’t validate.

The tradeoff here is that the security model changes: if someone is willing to sacrifice the deposit, they can write an invalid entry to the ENS registry, including replacing existing names. Although they would be quickly discovered and slashed, it’s possible an attacker might consider that worthwhile in order to temporarily take over some names.

Financially, there is little reason to run an attester unless there’s a reward for signing. This could be provided, but even without one the ENS team would be happy to run an attester as a public service.

There are a few subtleties to an implementation:

• It will still have to track the inception time of the signature over the TXT record used to prove ownership of the name, to prevent replay attacks reverting names to previous values.
• The DNSSEC oracle code will require some modifications to remove any reliance on stored record hashes and instead always validate the entire chain; this is to ensure that an attester can’t be slashed for a valid signature chain that relies on a key that is later replaced with an updated one.
• Likewise, the attestation will need to include the address of the DNSSEC oracle and the hash of the root keys at the time, in order to prevent changes from either of these resulting in an invalid attestation.
• If the risk of allowing anyone to bond is deemed too high, the ability to become an attester could be access-controlled by the multisig or any other ENS governance organisation.

I’d be really interested to hear peoples’ thoughts on this - is this a worthwhile tradeoff for the very substantial gas cost savings it would offer?

[matoken.eth]

@nick.eth

The tradeoff here is that the security model changes: if someone is willing to sacrifice the deposit, they can write an invalid entry to the ENS registry, including replacing existing names. Although they would be quickly discovered and slashed, it’s possible an attacker might consider that worthwhile in order to temporarily take over some names.

This is partly similar to the reason we are against using Harberger Tax. The value of the name and assets under the ETH address set to the specific names are different so it will be hard to figure out how much will be good to be attestation collateral (or no matter how big the collateral people still try to take over the names).

If a malicious person A take over the address for 5 ~ 10 min by changing the address of google.com from 0x01 to 0x02, the malicious person can also make a transaction to 0x02 and claim that he/she was intending to send to 0x01 and we have no way to counter dispute the argument.

Can we add some sort of time lock/delay?

If user A makes a malicious attempt to claim google.com at block 1, the name gets resolved after x block during that time attestation mechanism have time to slash the deposit and invalidate the change. The downside is that it will take a while for the actual name change to happen but possibly safer.

[nick.eth]

Yes, this is definitely the primary issue with it. We can at least characterise the security to users, though - “it would cost at least $1M for someone to compromise your domain”, for example. We could also allow users to mark their DNS text record as not allowed to use this system - meaning that they’d have to spend more gas on the trustless solution.

A delay is possible, and would make attacks much less likely for a given bond size - but it would at least double the gas cost, require two transactions, and introduce a delay to claiming.

[matoken.eth]

Can this be done using any of zkrollups? Our L2 strategy is to use existing security mechanism as much as possible so would love to minimise building our own attestation network.

[nick.eth]

We looked at doing it with Optimism, but sending an event to L1 instructing the registrar to add the name cost almost as much gas as just executing the whole thing on L1. The advantage of this system is that costs would be minimal unless there’s a dispute.