Shumon Huque schreef op 2025-01-21 04:55:
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.
Correct.
The problem can occur when everybody is able to generate every zone at a
DNS provider. The shared DNS providers will have no clue which of the
zones is authoritive or it does have conflicts during creation, and
therefore isn't able to create that zone, so people have to contact
support to remove the existing one. There are multiple situations that
domain hijacking becomes possible.
What I want to achieve, is having a simple method to verify ownership of
a domain at a shared DNS provider. It should be easy to implement, but
also easy to do for the customer. I also want not using nameservers for
it, because I may want to verify ownership before changing the
delegation of the domain. At the moment, as far as I know, Cloudflare
doesn't do any of this:
- They don't seem to verify domain ownership. Zones seem to be
authoritive at creation (for the specific nameservers defined).
- They use nameservers to point to the correct zone. This also makes
their implementation more complex, I guess.
- The Cloudflare method may be more difficult, because it is not
universal, but unique per user or per domain. You cannot make automated
scripts that just convert to "ns1.cloudflaredns.com". You have to
specificly get the pairs via an API or the portal.
- Cloudflares implementation may not be safe. Someone told me that he
created multiple Cloudflare accounts in the past in order to NOT have
the same nameserver pairs, because that could track the domains to the
same Cloudflare user.
There may be more problems with how Cloudflare does it. Also, there may
be other DNS providers that have similar implementations, or have worse
options.
The way I implemented it on my DNS provider system is like this: All
created zones are NON-verified by default. Because some registries can
do weird stuff, like the Portugal registry, I serve a "default zone"
when there is no authoritive zone for that specific domain. This also
gives the possibility to have a fallback page on the website with "You
have to verify your zone in the DNS portal.". (And yes, unverified zones
are not able to do zone cut on existing superzones.) If the zone is
created, the nameservers should be changed to something in the form of
"ns1.exampledns.com" and "<code>.ns2.exampledns.com". If those
nameservers are set, the zone creator has to click "Verify" to make the
zone verified. This verification script also disables all zones with the
name name and all subzones of that name.
My method works. There is no possiblity to hijack domains using my DNS
provider system, at least... if you do the verification before
delegating the domain. However, technically, you do delegation and
verification at the same time, using nameservers. Also, using a code in
the nameserver, which you may remove from the nameserver after
verification makes the process somewhat complex too.
My plan is to introduce a new DNS record. I prefer not to have a TXT
record, because registries have to implement this stuff anyway if they
want to start supporting this. It may also confuse people. Assume we
introduce a ZDT record: Zone Delegation Token. This is how the steps are
done:
1) User goes to DNS provider and creates zone.
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.
The things I think are important to find out:
- What would be the name of the record? ZDT (Zone Delegation Token), ZDV
(Zone Delegation Verification), ZDVT (Zone Delegation Verification
Token), or something else?
- What integer should be assigned to this record?
- What will be the format of this record? Like TXT or a little bit
different?
- Is this record class-dependent or class-independent?
- What do DNS providers actually verify? Do they verify the zone name
for ALL classes, or just for the IN class if the record is only used on
in the IN class?
- What will be the EPP namespace of this new extension?
(Maybe some other questions...)
I'm willing to write a basic draft already this weekend if I have some
time. Would that be useful?
Ben
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 [1]" and
"<validationCode>.ns2.exampledns.com [2]" 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.
Links:
------
[1] http://ns1.exampledns.com
[2] http://ns2.exampledns.com
_______________________________________________
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
