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?
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.
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.
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
