One challenge not covered in the current draft is how authoritative DNS server operators can validate new domains that have been recently registered. In the case where a domain has been created in a registrar and delegated to a DNS server operator, there's a window where the delegation is "lame" and not yet configured on the DNS server operator. In this window, an attacker could register this domain on the DNS server operator. This is more common in the case where a domain is registered and delegated but not provisioned (or provisioned and later deleted), allowing attackers to register the domain on the DNS server operator.
While TXT record validation works for existing zones that are on another operator already and want to be transferred or added, this doesn't work for new domains. (Requiring new domains be registered through DNS operators is another option, but not necessarily desirable.)
One option we might specify would be to encode this in an an additional delegation record on a specific name at the registrar. For example, customers of the DNS operator might normally delegate to authorities ns1.example.com through ns4.example.com. For the validation case, there would be an additional authority that is out-of-bailiwick in which we’d encode the token. For example, registrants would be requested to add NS records in the registrar for:
$domain IN NS ns1.example.com.
…
$domain IN NS ns2.example.com.
$domain IN NS ns-<base32token>.authdnsdv.example.net.
This would allow validation of the domain.
For .net domains an operator might instead use ns-.authdnsdv.example.com.
The DNS operator would need entries for the A and AAAA records for *.authdnsdv.example.{com,net} of the DNS authorities. Given the out-of-bailiwick nature this would be less likely to be used. Registrants could remove this if they want once the domain is created.
Part of the need for out-of-bailiwick would be to make sure no glue was present or needed in the parent zone. The child zone would not have/need this authority record.
(This may want to be its own separate draft?)
One challenge not covered in the current draft is how authoritative DNS server operators can validate new domains that have been recently registered. In the case where a domain has been created in a registrar and delegated to a DNS server operator, there's a window where the delegation is "lame" and not yet configured on the DNS server operator. In this window, an attacker could register this domain on the DNS server operator. This is more common in the case where a domain is registered and delegated but not provisioned (or provisioned and later deleted), allowing attackers to register the domain on the DNS server operator.
As called out in this article by Brian Krebs, this is being actively exploited: https://krebsonsecurity.com/2024/07/dont-let-your-domain-name-become-a-sitting-duck/ There are even teams of security researchers that look for domains that have been in this state for awhile and register them at various DNS server operators (eg, http://domainoverwatch.com/).
While TXT record validation works for existing zones that are on another operator already and want to be transferred or added, this doesn't work for new domains. (Requiring new domains be registered through DNS operators is another option, but not necessarily desirable.)
One option we might specify would be to encode this in an an additional delegation record on a specific name at the registrar. For example, customers of the DNS operator might normally delegate to authorities ns1.example.com through ns4.example.com. For the validation case, there would be an additional authority that is out-of-bailiwick in which we’d encode the token. For example, registrants would be requested to add NS records in the registrar for:
This would allow validation of the domain. For .net domains an operator might instead use ns-.authdnsdv.example.com.
The DNS operator would need entries for the A and AAAA records for *.authdnsdv.example.{com,net} of the DNS authorities. Given the out-of-bailiwick nature this would be less likely to be used. Registrants could remove this if they want once the domain is created.
Part of the need for out-of-bailiwick would be to make sure no glue was present or needed in the parent zone. The child zone would not have/need this authority record.