Last September, we launched support for the .xyz top-level-domain (TLD) on ENS. Support for .xyz uses a trustless integration based on DNSSEC, and our intention was for it to serve as a test in advance of rolling this integration out across all TLDs that have the necessary support.

With DNSSEC integration, the majority of Internet TLDs — nearly 90% — will become available for use in ENS. Anyone who owns a domain on one of these TLDs will be able to claim the same domain inside ENS and use it just like they would a .eth domain. For instance, ethereum.org will become a valid ENS domain, and once configured, a user could send funds to the EF using ethereum.org just as they can today using ethereum.eth.

We’re now at the point where we’re comfortable with the robustness of the DNSSEC integration, and we’re ready to roll it out more widely.

This presents a small problem, however. At present, the ENS root — the node in the ENS hierarchy that owns all the top-level domains — is owned by the ENS multisig, controlled by the 7 root keyholders. With over 1300 TLDs with the required DNSSEC support today, and that number changing all the time, manually approving each TLD would impose an unreasonable burden on the root keyholders.

In order to facilitate widespread deployment of DNS integration, we’re intending to deploy a new contract. This contract will replace the ENS root multisig as owner of the ENS root. This contract, in turn, will be owned by the ENS multisig, and will permit the multisig to make the same operations it can today. In addition to this pass-through functionality, however, the new root will have one new function: it will allow anyone to configure a TLD if they can supply a valid DNSSEC proof.

This permits two configurations for Internet TLDs:

Anyone at all can set up a TLD in ENS using the ‘default registrar’. This registrar will operate in the same fashion as the current .xyz registrar, allowing anyone with a supported second-level domain name (e.g., ethereum.org) and DNSSEC configured to claim this name inside ENS. This is the ‘permissionnless integration’. The owner of a TLD can manually specify an alternate registrar they want to control registration of domains under their top-level domain. This allows TLDs to set up bespoke integrations. .luxe already makes use of this to provide seamless integration between DNS and ENS, and we’re seeing other TLDs show interest in offering this as well. To do this, a TLD owner sets up a TXT record on _ens.nic.tld with the desired address, and submits a proof demonstrating this to the new root contract.

This new root will permit rolling out this DNS integration across most TLDs efficiently and quickly, and after its deployment we expect to enable this support immediately.

The Solidity code for the new root is available here. It’s currently being independently reviewed prior to deployment, and we encourage interested parties to conduct their own audits or reviews of it.

We welcome feedback via the discussion group at discuss.ens.domains, interactively on the ENS gitter, or privately to nick@ens.domains.

Unsupported TLDs

We’ve conducted a survey of TLDs in the current global DNS root that support the necessary DNSSEC integration.

Of 1536 TLDs in the root, 1349 (88%) have DNSSEC enabled and use algorithms and digests supported by our integration. The 187 TLDs without support can be broken down into three categories: Global TLDs (gTLDs), Internationalised TLDs (IDNA TLDs), Country Code TLDs (ccTLDs).

gTLDs

The following 29 gTLDs lack the necessary DNSSEC support and will not be available for ENS integration:

aero, alstom, barcelona, bauhaus, bcn, cat, cologne, erni, eurovision, eus, gal, gmx, ifm, koeln, lacaixa, madrid, man, mango, movistar, nrw, quebec, radio, ruhr, sap, scot, seat, sport, swiss, telefonica

IDNA TLDs

The following 25 IDNA TLDs lack the necessary DNSSEC support and will not be available for ENS integration:

বাংলা, қаз, онлайн, сайт, срб, бел, мкд, ලංකා, укр, الجزائر, عمان, ایران, امارات, بازار, موريتانيا, الاردن, المغرب, سودان, عراق, 澳門, გე, سورية, قطر, இலங்கை, فلسطين’

ccTLDs

By far the largest category is country-code TLDs. The following 133 ccTLDs lack the necessary DNSSEC support and will not be available for DNSSEC integration:

ae, ai, al, ao, aq, as, ba, bb, bd, bf, bh, bi, bj, bn, bo, br, bs, bv, cd, cf, cg, ch, ci, ck, cm, cu, cv, cw, cy, cz, dj, dm, do, dz, ec, eg, er, et, fj, fk, fm, ga, gb, ge, gf, gg, gh, gm, gp, gq, gt, gu, gw, gy, hm, ht, im, iq, ir, it, je, jm, jo, kh, km, kn, kp, kw, kz, li, ls, ly, mc, md, mh, mk, ml, mo, mp, mq, mr, ms, mt, mu, mv, mw, mz, ne, ng, ni, np, nr, nu, om, pa, pf, pg, ph, pk, pn, ps, py, qa, rs, rw, sd, sk, sl, sm, so, sr, ss, st, sv, sy, sz, tc, td, tg, tj, tk, to, tr, tz, ua, uz, va, ve, vg, vi, vu, ye, zw