DNS Integration

[nick.eth]

Description

A discussion of approaches and considerations for integrating the DNS and ENS namespaces.

Category

DNS

[Steve]

Hi,
For me they are several (technical) objectives :

1. Proof : How to prove that an user is the owner of a DNS name, when he registers a ENS name : using a DNSSEC proof.
2. Check : How to check that the owner of a ENS name is still the owner with the associated DNS name : check DNSSEC trust chain
3. Cycle life : How to manage the cycle life of a DNS name and the impacts on ENS name : expiration, abandon, bug

[alexm]

Hi Steve, all,

you might also want to look into other forms of domain based verification. There’s a whole bunch of options in the ACME protocol, which, for example, is used to validate requests to LetsEncrypt when issueing a new certificate. It’s specified in https://tools.ietf.org/html/rfc8555 - Section 8 talks about validation options.

best,
Alex

[nick.eth]

Our constraints are a little different - for a verification method to be viable for ENS, it needs to be possible to produce a noninteractive cryptographic proof of the ownership of a name. DNSSEC works well for this, but, eg, HTTP-based ACME verification wouldn’t.

[thibmeu]

Even with DNSSEC verification, there are still a few nits, as mentioned by @Steve in 3.

The domain peering should be valid up until the expiration field of the signature. It therefore requires to provide a new signature at every expiration, which can be fairly often (cf DNSSEC expiration for ens.domains records).

There is also this issue with name transfers. A name could be transferred on DNS without it being modified on ENS. Tackling this would require the new DNS domain owner to enable DNSSEC (which is not guaranteed) and upload a proof of change of ownership to re-attribute the domain. Otherwise, the ENS domain is valid until expiration.

Both could be considered as non-issues because the end-user would be displayed the name before performing an action, and should probably be aware of such domain change.

[nick.eth]

@thibmeu

Even with DNSSEC verification, there are still a few nits, as mentioned by @Steve in 3.

We already have these resolved with our current system, I believe.

@thibmeu

The domain peering should be valid up until the expiration field of the signature. It therefore requires to provide a new signature at every expiration, which can be fairly often (cf DNSSEC expiration for ens.domains records).

We accept updates as long as the record and the signature have not expired, and will not take any action based on an expired record. If a user wants to make a change based on something that happened in DNS, they can push the latest record and request an update based on that, while it remains valid.

@thibmeu

There is also this issue with name transfers. A name could be transferred on DNS without it being modified on ENS. Tackling this would require the new DNS domain owner to enable DNSSEC (which is not guaranteed) and upload a proof of change of ownership to re-attribute the domain. Otherwise, the ENS domain is valid until expiration.

If the new user has DNSSEC enabled, it will be possible for anyone to generate an NSEC or NSEC3 record proving the _ens subdomain no longer exists. If they do not have DNSSEC enabled, I need to double-check, but I believe it’s possible to generate an NSEC/NSEC3 proof for the domain itself from the registrar, which will also allow removing the record.

In any case, this thread isn’t really the place to discuss this - the topic exists to discuss whether we should talk about DNS integration at the upcoming workshop.