I've changed the subject line to "Domain Hijacking countermeasures" since the topic is somewhat different from the problem this draft is trying to solve.
The problem you cite is how a (typically shared) 'DNS provider' verifies that someone legitimately has a domain registered to them before provisioning the domain on their infrastructure. That area encompasses hijacking newly registered domains, taking over a domain whose registration has lapsed, or where the owner has lost control of the provisioned zone (dangling delegation), and also subzone hijacking. On Tue, Jan 14, 2025 at 5:57 AM <ben=40yocto....@dmarc.ietf.org> wrote: > Hello all, > > This may be off-topic, but saw this mail about "domain validation" > appear in my mailbox. > > It seems that the specification wants to specify a standardized way to > verify domains when needing some authority (e.g. during certificate > requests or activating a mail service for you domain at a mail > provider). I think it is indeed nice to have some standard that can be > followed, instead of everybody making their own mechanism. > > However, in all cases of DNS validation, it is assumed that the zone is > authoritive. Mostly, this is the case, because the NS servers point to > the DNS server where the zone is located, but even then there could be > problems. One problem is Zone Hijacking: > > https://community.cloudflare.com/t/add-extra-dns-check-on-cloudflare-zone-creation-to-prevent-hijacking/686853 > . > > As DNS Operator, I use "ns1.exampledns.com" and > "<validationCode>.ns2.exampledns.com" NS records that a user should put > in the nameserver fields at the registrar; after validation, the > validation code can be removed. Cloudflare uses a different method by > using a somewhat unique pair of nameservers. Other DNS operators may > have other validation methods to verify that the zone creator is also > the domain owner, or don't have any validation at all. > > Honestly, I don't think that doing validation with nameservers is THE > way to do it. As I mentioned in 2023 on Twitter/X > (https://x.com/ben221199/status/1717122678463578307), I'm interested in > writing a RFC that defines a new method for validation of domain owners > for DNS operators (including the EPP extension), because that is > actually the last unsafe part in the validation chain. Because I got > triggered by the subject of the mail below, I decided to write this > mail. I want to know if my RFC idea is in scope with the draft that is > written by your working group. If it isn't, I will start my own draft of > course. Else, I'm happy to contribute to this existing draft. > The authors of this draft did discuss this problem in some detail off list last year when the following article came out: https://krebsonsecurity.com/2024/07/dont-let-your-domain-name-become-a-sitting-duck/ and concluded that there might be some work to do in this area, but it probably belongs in a separate document. Many competent DNS providers already have a variety of checks they perform that can prevent some of these problems. Furthermore, there is some disagreement more generally that this is a problem that needs a technical solution, rather than just exhorting domain owners to be more responsible with how they provision and maintain their domains. Nevertheless, even with responsible domain owners, for a newly registered domain or for a domain changing hands, there might be a small window of vulnerability where a lame delegation might exist and perhaps that is worth closing. Eric Nygren had an idea of encoding a validation token in an NS record. It might be worth writing up a clear problem statement and some possible technical solutions (and I'd be happy to be involved with that, assuming it is in a separate draft). DNSSEC can also play a role in preventing or at least detecting domain hijacking. A DS record deployed at the parent by the legitimate zone owner could for example prevent an adversary from taking over the zone at the listed nameservers (e.g., if the owner had lost control of their account/zone), without detection by validating resolvers. You mention EPP as part of a solution - can you elaborate on how? Third party DNS operators don't generally have access to the EPP registration machinery today, and not all TLDs use EPP anyway. Furthermore, I think the domain hijacking problem would need a more general solution than just at the (e)TLD interface -- it would also need to address zones further down in the hierarchy for completeness. If you have a proposed solution already in mind, please feel free to write it up and share. Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
