Subject: [Add] I-D Action: draft-reddy-add-enterprise-split-dns-08.txt

From: [email-masked]
Date: Thu, 20 Jan 2022 20:34:39 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Adaptive DNS Discovery WG of the IETF.

        Title           : Split-Horizon DNS Configuration
        Authors         : Tirumaleswar Reddy
                          Dan Wing
                          Kevin Smith
                          Benjamin Schwartz
	Filename        : draft-reddy-add-enterprise-split-dns-08.txt
	Pages           : 12
	Date            : 2022-01-20

Abstract:
   When split-horizon DNS is deployed by a network, certain domains can
   be resolved authoritatively by the network-provided DNS resolver.
   DNS clients that don't always use this resolver might wish to do so
   for these domains.  This specification enables networks to inform DNS
   clients about domains that are inside the split-horizon DNS, and
   describes how clients can confirm the local resolver's authority over
   these domains.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-reddy-add-enterprise-split-dns-08

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: tirumal reddy <[email-masked]>
Date: Fri, 21 Jan 2022 10:56:04 +0530

We published -08 version of Split-Horizon DNS Configuration draft
https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-08

based on WG feedback from IETF 112.

Key changes are:

   *  Restricted the scope of the document to split-horizon DNS names that
are properly rooted in the global DNS.
   *  Added new terminology of hybrid resolver/client, authorised split
horizon and domain camping
   *  Added DNSSEC to confirm authority over the split-horizon domains

Comments and suggestions are welcome.

-Tiru, Dan, Kevin and Ben.

On Fri, 21 Jan 2022 at 10:04, <[email-masked]> wrote:

> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 21 Jan 2022 16:22:51 -0500 (EST)

On Fri, 21 Jan 2022, tirumal reddy wrote:

>    *  Restricted the scope of the document to split-horizon DNS names that are properly rooted in the global DNS.
>    *  Added new terminology of hybrid resolver/client, authorised split horizon and domain camping

I am not sure if reducing the scope of split-dns is the way forward. A
lot of split DNS is specifically for internal only domains, so I feel
this document is now going to be very confusing for offering a split-dns
solution without actually offering a split-dns solution.

I had never heard of "domain camping" before, and I wonder what is wrong
with "domain hijacking " and "NXDOMAIN hijacking" as terms ?

If DNSSEC is required for split-dns, then it is also very conceivable
that DNSSEC is used for the internal domains. For IKEv2 split-dns we
offered the option to signal DS/DNSKEY's for the internal view. I don't
think any of the add related drafts offers this option? If I missed it,
please let me know how a client that decides to pick "example.com"
resolving via the internal view of the split, can obtain the required
DS/DNSKEY's of those internal zones ?

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 21 Jan 2022 19:15:25 -0500

On Fri, Jan 21, 2022 at 4:23 PM Paul Wouters <[email-masked]> wrote:

> >    *  Restricted the scope of the document to split-horizon DNS names
> that are properly rooted in the global DNS.

I'm not sure what you mean by "internal-only domains".  To be clear, a
domain like "asdf.corp.example.com" is "properly rooted in the global DNS"
if it is done with the permission of "example.com", even if "
asdf.corp.example.com" is NXDOMAIN on the public internet.

What's newly excluded in this draft are domains like "example.faketld",
i.e. names whose parent (in this case the root) did not give permission for
this use.

...

> DS/DNSKEY's of those internal zones ?

I don't understand the question.  These names are properly rooted in the
DNS, so DNSSEC validation of signed zones proceeds as usual, without any
need for additional trust anchors.

---

From: Ralf Weber <[email-masked]>
Date: Sun, 23 Jan 2022 10:09:05 +0100

Moin!

> need for additional trust anchors.
That only is true if you are using the same DNSKEYs internally and external.
Something that might not be true if you e.g have your external zone hosted
by a third party.

Also keep in mind that if
	corp.example.com
is NXDomain externally you need a special/different
	example.com
internally to delegate corp.example.com.

I’ve always envisioned DNSSEC split horizon needing an internal trust anchor
because of this ideally in the recursive resolver and stub resolver.

So long
-Ralf
——-
Ralf Weber

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Jan 2022 13:09:29 -0500

...

    > this document is now going to be very confusing for offering a
    > split-dns solution without actually offering a split-dns solution.

I agree with you strongly.
Since ADD has determined that explaining split-dns in a normative fashion is
out of scope, would it be reasonable to ask DNSOP to do that?

I don't see how we can proceed without a clear consensus on what the various
split-dns methods are.  We at least, need some names.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Paul Wouters <[email-masked]>
Date: Sun, 23 Jan 2022 15:07:59 -0500 (EST)

On Fri, 21 Jan 2022, Ben Schwartz wrote:

> I'm not sure what you mean by "internal-only domains".  To be clear, a domain like "asdf.corp.example.com" is "properly rooted
> in the global DNS" if it is done with the permission of "example.com", even if "asdf.corp.example.com" is NXDOMAIN on the
> public internet.

That is not clear from the text at all. In that case, yes you cover all
the cases of split-dns but then I wonder how the external server will
somehow "confirm authorization" of "corp.example.com" on the internal
server if the externl server returns NXDOMAIN or REFUSED because the
domain is internal only ? Especially because the connecting client is
supposedly sending this query over its own trusted (encrypted) resolver
to the public nameserver, reachin the public nameserver's external
"view".

> What's newly excluded in this draft are domains like "example.faketld", i.e. names whose parent (in this case the root) did not
> give permission for this use.

Please do clarify that in the draft.

> I don't understand the question.  These names are properly rooted in the DNS, so DNSSEC validation of signed zones proceeds as
> usual, without any need for additional trust anchors. 

If you ask the public view for internal.example.com you get no NS
records and no DS records. As far as it is concerned, the domain
you queried for does not exist, and you are given DNSSEC proof
that it does not exist.

Once the document is fixed to somehow contain the proofs of the internal
view that "internal.example.com" should be queried for at 10.10.10.10,
then if you want internal.example.com to be signed and have a valid
trust anchor that you normally get from the parent zone via DS record,
you now need an alternative method to get that trust anchor. My comment
was that this document provides no method or normative reference to
a method to obtain this. In IKEv2 split-DNS, we added both a domain list
and their DS/DNSKEY records as provisioning information the IKE layer
conveys. This document only provides the names of domains, not their
trust anchors.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 24 Jan 2022 10:16:45 -0500

On Sun, Jan 23, 2022 at 3:08 PM Paul Wouters <paul.wouters=
[email-masked]> wrote:

> split-dns
> domain like "asdf.corp.example.com" is "properly rooted
> > in the global DNS" if it is done with the permission of "example.com",
> even if "asdf.corp.example.com" is NXDOMAIN on the
> > public internet.
>

In this case, "corp.example.com" would be publicly visible, presumably as
an "empty" zone (containing only its own NS records, NS IPs if
in-bailiwick, DNSSEC records, etc.).  The client would fetch the NS records
for this zone, and check the NS names against the DNR ADNs.  A query for "
asdf.corp.example.com" would then flow to the local DNR resolver, which
serves a non-NXDOMAIN response.

Alternatively, the local resolver can claim the "example.com" zone, and
corp.example.com can be NXDOMAIN publicly.

> i.e. names whose parent (in this case the root) did not

Sorry, I meant "newly excluded in this draft revision", compared to -07.  I
believe this is quite explicit from the "NXDOMAIN camping" text in -08.

> DNS, so DNSSEC validation of signed zones proceeds as
> records and no DS records.

This draft effectively requires that any "claimed zone" has publicly
visible NS records.  If the zone is (publicly) signed, then it must also
have publicly visible DNSSEC records.

> As far as it is concerned, the domain

No, because each "claimed zone" is presumed to be a publicly visible zone
enclosing the internal-only names.  This may be the zone itself, or a
parent.

> you now need an alternative method to get that trust anchor.

I think this shows that the internal and external DNSSEC views may be
incompatible, so they cannot share a cache.  However, I see no reason that
we need a separate trust anchor.  The internal resolver can provide a valid
chain for internal names that goes all the way to the root, while external
resolution receives an NSEC instead.

> My comment

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 24 Jan 2022 10:20:01 -0500

> Something that might not be true if you e.g have your external zone hosted

I think this is fine.  You just publish DS records for both the internal
and external DNSKEYs.  Validation will then succeed for records signed by
either key.

> internally to delegate corp.example.com.

Agreed.  The claimed zone (which could be "example.com" or "corp.example.com")
must resolve differently internally and externally, or you haven't actually
"split" anything.

> because of this ideally in the recursive resolver and stub resolver.

I don't think there's any need for a separate trust anchor.

---

From: Ralf Weber <[email-masked]>
Date: Mon, 24 Jan 2022 16:45:03 +0100

Moin!

> and external DNSKEYs.  Validation will then succeed for records signed by
But then I give away that corp.example.com exists and that it has a DNSKEY.

> must resolve differently internally and externally, or you haven't actually
I have. example.com is different externally then internally. Externally it is
missing the corp.example.com delegation.

> I don't think there's any need for a separate trust anchor.
In the above example there is, as corp.example.com does not exist in public space
or are you saying that the case I described is not split DNS?

So long
-Ralf
——-
Ralf Weber

---

From: Ted Hardie <[email-masked]>
Date: Mon, 24 Jan 2022 15:53:56 +0000

> But then I give away that corp.example.com exists and that it has a
If this concerns you, you can mint  a wide variety of domains and assign
them DNSKEYs, using only a fraction.  Is the well-used domain
fleen.example.com?  bumblebridge.example.com?  or even
daffy-down-dilly.example.com?

Of course, if you use a string like corp, there is no point in pretending
that it is a secret, as it is so common as to be the first or second
guess.  There's not much worry about giving that away, at least in my
personal opinion.

regards,

Ted

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 24 Jan 2022 10:58:05 -0500

> But then I give away that corp.example.com exists and that it has a

If you don't want "corp.example.com" to be mentioned publicly, then your
internal resolver has to "claim" example.com.  Assuming all zones are
signed, you can do this either by signing a pair of conflicting records (an
external NSEC denying corp, and an internal DS delegating corp) with the
same key, or you can publish two DS records in the "com" zone (for the
internal and external keys).

(As Ted said, in my examples I've been assuming that the "corp" label is
public, and any "hidden" names are under "corp", but the logic is the same
if we go up one label.)

> missing the corp.example.com delegation.

Yes.

> or are you saying that the case I described is not split DNS?

 This is split DNS, but there's no need for a separate trust anchor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 24 Jan 2022 11:21:43 -0500 (EST)

On Mon, 24 Jan 2022, Ben Schwartz wrote:

> In this case, "corp.example.com" would be publicly visible

You have now redefined split-dns again to be only the cases where the
zone exists in both internal and external views. The problem we were
addressing was internal zones that do not exist in any kind of form
externally.

> , presumably as an "empty" zone (containing only its own
> NS records, NS IPs if in-bailiwick, DNSSEC records, etc.).  The client would fetch the NS records for this zone,
> and check the NS names against the DNR ADNs.  A query for "asdf.corp.example.com" would then flow to the local DNR
> resolver, which serves a non-NXDOMAIN response.

Now you have created an additional binding between the administrators
of the internal and external versions of the internal-only
"corp.example.com". Now internal DNSSEC adminstrators need to sync
up with the external ones. These might be different departments and
different providers.

> Alternatively, the local resolver can claim the "example.com" zone, and corp.example.com can be NXDOMAIN publicly.

Yes, it could claim example.com, but again then there needs to be two
different example.com zones that are in need of a sync for DS records,
and two different views - one for the internal and one for the external
one, since they differ in corp.example.com. So the internal one claiming
"example.com" cannot just forward to the public one. But for data
outside of corp.example.com it should not really be authoritative, so
again a human/third-party sync is needed between internal and external
DNS. So these workarounds are prone to failure due to their administrative
overhead that requires continuous cooperation between two different
systems/groups.

An ideal situation would make the internal DNS fully independent of the
external DNS. Again, if you look at RFC 8598 IKEv2 Split DNS, it conveys
all the information through provisioning which has its own trust anchor.
It leaves the operation of internal and external DNS independent of each
other.

Additionally, if I want to steal gmail.com, couldn't I just claim ".com" ?
I replay some externally valid DNSSEC records and then when they are
trying to visit gmail.com, I route the IPs of ns*.google.com to my
own servers (eg via NAT or by squatting the public IP space). I might
not be able to run HTTPS for gmail.com, but at least I've prevented
the user on the network from accessing the real gmail.com.

> Sorry, I meant "newly excluded in this draft revision", compared to -07.  I believe this is quite explicit from
> the "NXDOMAIN camping" text in -08.

Re-reading it, I agree. I think the confusion could be reduced by using
common terms like domain hijacking and nxdomain hijacking instead of the
word camping.

> This draft effectively requires that any "claimed zone" has publicly visible NS records.

Yes, and I have commented from the start that this is not a realistic
operational requirement. People want to hide their internal zones. If
they didn't they would have put a public placeholder domain there
already. They don't want to reveal their internal domains in a public
downloadable list via DNS records.

> No, because each "claimed zone" is presumed to be a publicly visible zone enclosing the internal-only names.  This
> may be the zone itself, or a parent.

I commented on this already earlier in this response.

> I think this shows that the internal and external DNSSEC views may be incompatible, so they cannot share a cache.

RFC 8598 has text on how to deal with multiple caches:

    When an IKE Security Association (SA) is terminated, the DNS
    forwarding MUST be unconfigured.  This includes deleting the DNS
    forwarding rules; flushing all cached data for DNS domains provided
    by the INTERNAL_DNS_DOMAIN attribute, including negative cache
    entries; removing any obtained DNSSEC trust anchors from the list of
    trust anchors; and clearing the outstanding DNS request queue.

At least on the system / OS level, there are existing hooks to deal with
this already for the main operating systems. I am not very familiar with
how browsers deal with their DNS cache when a "network disconnect/connect"
event happens. I assume they must do something similar.

> However, I see no reason that we need a separate trust anchor.  The internal resolver can provide a valid chain
> for internal names that goes all the way to the root, while external resolution receives an NSEC instead.

You need a seperate trust anchor because the internal and external DNS
is run by different humans in different departments using different
third parties with different software.

>       conveys. This document only provides the names of domains, not their

And now I understand that additionally, one must publish their internal
only domains in public DNS. I do not think that is a practical solution
from an operational point of view. Instead, operators will just want to
take all DNS queries from connecting clients, and will inform the users
to disable their third party DNS solutions.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 24 Jan 2022 12:13:34 -0500

[Some history removed for density]

> addressing was internal zones that do not exist in any kind of form

Your original message said "internal-only domains", and I described how to
offer internal-only domains within a publicly visible zone.  However,
internal-only zones are also supported.  Those zones must chain up to a
publicly visible zone at some point.

> > NS records, NS IPs if in-bailiwick, DNSSEC records, etc.).  The client
> would fetch the NS records for this zone,
> > and check the NS names against the DNR ADNs.  A query for "
> asdf.corp.example.com" would then flow to the local DNR

Yes: corp.example.com needs a signature from the example.com keys in order
for DNSSEC to be valid.  This is intrinsic to DNSSEC.

Other than that, there is no special binding.  "corp.example.com" is an
ordinary child to "example.com", and both the internal (populated) and
external (empty/trivial) versions of "corp.example.com" can be operated by
a single administrative entity.  (You can even use a single version of the
zone, with the public secondary configured to REFUSE all queries except for
the apex NS.)

> overhead that requires continuous cooperation between two different

There are many possible deployment architectures here.  Which one to use
may indeed depend on how your organization is structured.

> It leaves the operation of internal and external DNS independent of each

I think the ideal situation is to make the internal DNS fully verified from
the public DNS, so that there is only a single trust anchor, and no
opportunity for an attacker to hijack zones they don't own.

Not unless you have a valid certificate for "a.gtld-servers.net".  (The
client validates the DNR server's name and matches it against the NS record
for each claimed zone.)

...

> visible NS records.

I hope it's clear that this is entirely possible within the framework
described in the draft.

> However, I see no reason that we need a separate trust anchor.  The
> internal resolver can provide a valid chain

Child and parent domains are often run by different people and software
with limited coordination.  The cooperation required here is not any
higher.  You can even hang the internal names from a separate registrable
domain (example-internal.com) if your two divisions can't talk to each
other for some reason.

I can certainly imagine that there are organizations that would be unable
to deploy a compatible architecture due to internal bureaucracy, but it's
not actually hard to set one up.

...

> I do not think that is a practical solution

This does not seem substantially worse than adding a new DNSSEC trust
anchor.  It might even be better: at least that operator can't forge DANE
certificates for hijacked domains.

---

From: Joe Abley <[email-masked]>
Date: Mon, 24 Jan 2022 18:29:25 +0100

On Jan 24, 2022, at 16:58, Ben Schwartz <bemasc=[email-masked]> wrote:

> If you don't want "corp.example.com" to be mentioned publicly, then your internal resolver has to "claim" example.com. 

If you're using corp.example.com internally on a real network with real users, with or without split DNS, with or without DNSSEC, then it's definitely already public.

This is not a mathematical guarantee but a bet to the contrary would be given very poor odds by any competent bookmaker.

Joe

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Jan 2022 12:36:05 -0500

>> That is not clear from the text at all. In that case, yes you cover
    >> all the cases of split-dns but then I wonder how the external server
    >> will somehow "confirm authorization" of "corp.example.com" on the
    >> internal server if the externl server returns NXDOMAIN or REFUSED
    >> because the domain is internal only ? Especially because the
    >> connecting client is supposedly sending this query over its own
    >> trusted (encrypted) resolver to the public nameserver, reachin the
    >> public nameserver's external "view".
    >>

    > You have now redefined split-dns again to be only the cases where the

No, because split-dns was never properly defined :-)

That's the IETF's fault.
We should fix this through some set of adjectives in a BCP.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Jan 2022 12:37:32 -0500

Ted Hardie <[email-masked]> wrote:
    > Of course, if you use a string like corp, there is no point in
    > pretending that it is a secret, as it is so common as to be the first
    > or second guess.  There's not much worry about giving that away, at
    > least in my personal opinion.

Agreed.
I'll even bet there is a public MX record.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 24 Jan 2022 12:55:37 -0500 (EST)

On Mon, 24 Jan 2022, Ben Schwartz wrote:

> Yes: corp.example.com needs a signature from the example.com keys in order for DNSSEC to be valid.  This is
> intrinsic to DNSSEC.

No it is not. Please read RFC 8598 on how this is not the case for IKEv2
split-DNS. You can provision a DNSSEC trust anchor for corp.example.com
out of band. This never appears in any public DNS server that serves
example.com.

> Other than that, there is no special binding.  "corp.example.com" is an ordinary child to "example.com", and
> both the internal (populated) and external (empty/trivial) versions of "corp.example.com" can be operated by
> a single administrative entity.

While it can be, it almost never is.

> (You can even use a single version of the zone, with the public secondary
> configured to REFUSE all queries except for the apex NS.)

Where can I find this option at the gui or api for cloudflare, godaddy, route53, NS1, Microsoft DNS?

> There are many possible deployment architectures here.  Which one to use may indeed depend on how your
> organization is structured.

But you have still not offered one of a very common split-dns deployment
where the internal domain is only ever visible internally.

> I think the ideal situation is to make the internal DNS fully verified from the public DNS, so that there is
> only a single trust anchor, and no opportunity for an attacker to hijack zones they don't own.

I agree, but what you are describing is "NOT split-dns". This draft is
exactly about everything that is not what you propose in your sentence
here.

> Not unless you have a valid certificate for "a.gtld-servers.net".  (The client validates the DNR server's
> name and matches it against the NS record for each claimed zone.)

I did not realise this additional constraint.

So if I have 250 internal domains, do I need my DNR server to have a
certificate with 250 SAN's ? What if these domains are hosted at very
different parties publicly? I guess my only option is to get all of
those domains to use ACME with DNS, since I cannot use ACME with HTTP?

> I hope it's clear that this is entirely possible within the framework described in the draft.

No it is not. It appears you have only redefined what "public" means,
and you call an "empty zone with the internal only name in the public
zone" effectively a "private only domain". And I disagree with that.

> Child and parent domains are often run by different people and software with limited coordination.  The
> cooperation required here is not any higher.

As long as we disagree on the definition of a "internal only domain
name", then further discussion on what is workable or not seems moot.

> This does not seem substantially worse than adding a new DNSSEC trust anchor.  It might even be better: at
> least that operator can't forge DANE certificates for hijacked domains. 

I see two possible outcomes with the current document:

1) It will lead the browsers ignoring ADD/DNR for security reasons.
2) Operators of internal-only zones will just require users to bring
    up a VPN to properly provision split-DNS.

Neither solution would require this document.

I would however, like to solve the issue of browsers and organizations
handling split-DNS domains so both browsers/endusers and organizations
can have optional DNS functionality, security and privacy.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 24 Jan 2022 13:57:06 -0500

> route53, NS1, Microsoft DNS?

I'm not familiar with those, but you might be able to do it using Google
Cloud DNS's Response Policy system [1].  Regardless, I don't think we
should constrain ourselves to the functionality presently available from
service providers.

[1]
https://cloud.google.com/blog/products/networking/introducing-cloud-dns-response-policies

> where the internal domain is only ever visible internally.

This draft requires that the internal resolver be authoritative for a
public zone that encloses the internal names.  It does not require that the
internal names, or even the zone that contains them, be public.

I think there are a large number of cases (including "asdf.corp.example.com")
where this arrangement is sensible and sufficiently convenient to deploy.

> exactly about everything that is not what you propose in your sentence

The draft provides a definition of split DNS.  Feel free to propose a
different one if you think we haven't captured the concept correctly.

> client validates the DNR server's
> certificate with 250 SAN's ?

No.  If you have 250 internal domains, spread across 5 zones, all of which
include "ns1.corp.example.com" in their NS RRSet, then you need one SAN.
Otherwise, you may need more SANs, enough to match one entry in each zone's
NS RRSet.

These SANs do not have to be in the same certificate, thanks to SNI.  They
don't even have to be served from the same IP address, thanks to DNR.

> What if these domains are hosted at very
> different parties publicly?

There are many ways to solve this.  For example, you might decide to use
vanity names (within a zone you control) to identify the third-party
nameservers, so that you can acquire certificates for those names.

> I guess my only option is to get all of

You could use either ACME mode to acquire certificates for the nameserver
names.

...

> anchor.  It might even be better: at

The document's purpose is to provide guidance for how a client with a
particular threat model can increase its use of DNR.  That seems like the
opposite of this.

> Paul--

---

From: Eric Orth <[email-masked]>
Date: Mon, 24 Jan 2022 15:12:39 -0500

> with "domain hijacking " and "NXDOMAIN hijacking" as terms ?

I normally hear and think of "domain camping" as a
not-intentionally-malicious subcategory of domain hijacking where the
domain being hijacked is assumed (whether or not correctly) to not exist.
Thus whoever is setting up split-dns for a network may believe it to be a
safe and conflict-free domain to use for internal usage, but it may cause
conflicts or other issues in the future when somebody adds actual
authoritative use of the domain.  Very common (but also very non-ideal) in
split-dns scenarios.

That said, the definition in the draft seems much more generic than my
understanding of the term and possibly equivalent to my understanding of
the wider "hijacking" terminology.  The draft even gives the example of
hijacking a popular domain to monitor traffic to that domain.  Very much a
scenario where "hijacking" is a clearer description.  So maybe, per this
terminology usage, to avoid unnecessarily confusing terminology, "domain
hijacking" would be a better term for the draft to define and use?