On Jan 22, 2025, at 13:54, Ben van Hartingsveldt | Yocto <ben.vanhartingsveldt=40yocto....@dmarc.ietf.org> wrote: > > Edward Lewis schreef op 2025-01-22 18:11: >> On Jan 22, 2025, at 10:35 AM, Ben van Hartingsveldt | Yocto >> <ben.vanhartingsveldt=40yocto....@dmarc.ietf.org> wrote: >>> 1) User goes to DNS provider and creates zone. >> I think there’s a problem with step 1. A user (which is >> any-off-the-street-customer) is not the source of authority when it comes to >> control or ownership of a domain. A user “claiming ownership” could itself >> be abusive towards a DNS provider in the sense that the user, >> well-intentioned or not, is making the DNS provider do potentially needless >> work. If there’s ill-intent, then this could be a denial of service via >> resource depletion. > Well, I assume that the registrar and the DNS provider are 2 different > companies. The DNS provider allows every user to create a zone, but doesn't > see the user as authority. Only when that user is able to put that ZDVT > record in the DNS of the registry, it knows that that zone is also > authoritive, because it only looks at the registry for matching tokens. This > is like DNSSEC, right?
The term “authoritative” has a specific meaning in the DNS protocol which is unrelated to this topic. A DNS hoster may elect to have a policy that all domains they operate/serve are administered by the entity (person) who has registered the name in the global public DNS tree. That awkward sentence is a nod to the difference between the DNS protocol and the way in which the DNS protocol is used across the global public Internet. Sticking to the way DNS is run in the business sense… Proposing that the registered administrator of a domain needs to get a resource record published by the parent domain faces a number of hurdles. The DNS protocol does not easily accommodate data related to a zone cut to be published by the parent (lots of history there). Next, in the context of ICANN-contracted TLDs (gTLDs), approval to have any new record would have to be sought, not a simple task. Lest it seem like ICANN is putting up a barrier, new things face difficulty getting deployed in non-ICANN-contracted TLDs. DNSSEC is much different, but perhaps you are thinking about the case where a zone administrator would have to copy-n-paste the contents of a DS record produced by a DNS hoster to a registrar’s provisioning page. Relying on zone administrators to do this has not proven successful. Saying this without checking - can RDAP be of help here? If needed information is not redacted, RDAP is a means to inspect the registration data at a registry. I know that since GDPR a lot of stuff has been shutdown, so I can’t say if RDAP is the right way to go. I’m going to say once again…the way out of this may lay with DELEG... >> Authority for a domain’s existence comes down from the top of the tree. In >> the common scenario of something like “example.com”, then it is a TLD >> registry that is the chief authority. If the TLD works with registrars, >> then registrars are in position to be “sub-“authorities for the names they >> manage. > Technically, a registrar that is also a DNS provider can verify zones without > any ZDVT record. However, when an those are seperate, as DNS provider I find > it more trustworthy to query the DNS server of the registry for some token > check, instead of asking a registrar over an API if that zone should be > activated. I mean, if the registrar is authoritive for some domain, they can > use the EPP protocol to modify the needed information on the registry side. RDAP, over an authenticated channel, would be more appropriate - protocol-wise. >> The flow has to be registry->registrar-if-there->DNS operator before a user >> can “create a zone.” > As told above, a DNS provider doesn't have control over that. I would rather > say that you should call it "activate a zone", because you have to create a > zone beforehand to get its ZDVT record. If the operator only wants to run zones that are legitimately part of the Internet tree, I’d suggest developing something using RDAP. >> The rest of the steps are means of verifying a claim in reverse, which is >> more work than just being able to directly consult the authority. > I think this isn't the way. If I want to activate my Google Search Console, I > also put some TXT record in my DNS, it isn't the registrar that tells Google > that I'm allowed to access that Google Search Console site. >>> 2) DNS provider creates zone and gives ZDT token for that specific zone. >>> 3) User copies the ZDT token that is given by the DNS provider and pastes >>> it to some (new) field at the registrar. >>> 4) Registrar sends the ZDT token to the registry using EPP. (Yes, we have >>> to specify a EPP extension for this token.) >>> 5) Registry uses this ZDT token as DNS record in their superzone. >>> (example.com. IN ZDT "some-token-text") >>> 6) User goes to DNS provider and verifies zone. >>> 7) DNS providers checks record in the DNS zone of the registry and >>> activates zone when correct. >>> 8) User now pastes nameservers at registrar. >>> 9) Registrar sends nameservers using EPP to registry. >>> 10) Registry uses this nameservers in their superzone. The domain is now >>> delegated without any possibility to hijack. >> There’s no stopping a DNS operator from allowing a customer to run a domain >> that is not attached to the global public Internet DNS. Unless there’s a >> name collision with a domain that is attached to the global public Internet >> DNS, this could be done without easy detection. Aside - If there’s a name >> collision, then it’d be detectable but still may not be operationally >> impacting. > Technically no, but I assume that many DNS provider will not support a > non-ICANN tree. >> Questions to DNS providers - mean those hosting zones without bundled name >> registration services - do they want to only serve domains registered in the >> global public Internet DNS tree, or host anything so long as there is no >> conflict, or not care at all? Do they clean up customers that have left? >> I’ve am thinking of a specific situation where a provider's servers answered >> for zones only because the provider did not de-provision a customer they >> lost, per the “lost customer.” > Me as DNS provider am likely not supporting domains outside the ICANN tree in > the near future. For now, without any deep thinking, it causes problems, and > likely the answer is: use your own (self-hosted) DNS server. Possibly there > will be some solution in the future, but not for now. >> I hate to beat an injured camel, but the way forward to me lies in DELEG. >> The registry knows best and it can encode stuff into zone cut information, >> including allowed DNS providers - in plural - in an explicit way. A >> registrant would have to indicate this via the provisioning system (whether >> or not EPP is the underlying protocol) when administering the zone, which >> might make overall provisioning easier by eliminating the need to list DS, >> NS, and glue records, instead pointing to some DNS operator(s) to say “use >> their stuff.” > With this last paragraph, it seems like you mean that a CAA record-ish thing > would be better, so including a list of "allowed DNS providers" in the > registry zone. However, this is not going to solve this, because hijacking > mostly happens at one DNS provider. I also read the world plural; I didn't > write it previously, but I want to allow multiple ZDVT records next to each > other, for people that want the same zone enabled at more DNS providers. > Ben >> _______________________________________________ >> DNSOP mailing list -- dnsop@ietf.org >> To unsubscribe send an email to dnsop-le...@ietf.org > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
