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

Ben Schwartz <> Mon, 24 January 2022 17:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 974D93A0B82 for <>; Mon, 24 Jan 2022 09:13:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M85Qw2PlLIJY for <>; Mon, 24 Jan 2022 09:13:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED9763A0B7F for <>; Mon, 24 Jan 2022 09:13:47 -0800 (PST)
Received: by with SMTP id p1so32159107uap.9 for <>; Mon, 24 Jan 2022 09:13:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zNKXgZkg6yUYRBWpd2raWoRQPEVs5uqXx6sm4Vg6Cqc=; b=JdejfN2++1Z6Qwxuoq6310kEiurHiPjMLSo8RTvxwywwjo3wk5lHD4Ecpkf6Nr8M3L GDFTnOreqw0mYGjoNfeNnyvG9c0NgOAvB0/QHtzrt2bp7D55TLy1z34F6ogG7P9edpsV JJl1xVze7vV5MwXiivA/AsTt9hhZNVH3HSIylm4Ye+zQYEwhcrvR2miDUHnatT5vsrT1 PgSR1OAAwrY8H3luUF2e39iSUU1P0ZiiiojyxowH7sU8CwGg++GUcU+RJEkYNQYFA3Pz ULyuVU3qMulqC4TRPlVeahvWYUvU+208QuUvU1GkrXV9vsq53VVWps4HqM10RimtQ08c KPCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zNKXgZkg6yUYRBWpd2raWoRQPEVs5uqXx6sm4Vg6Cqc=; b=ymheRodtII+NXkAZ9dzHLaU6wS6/kbXrYHrrwP67i3OI6maWBnWAwNJjBruvJNpC1Z 7G1Z0R83Eck6O8fah+yeZjqyTh9tapEIxnAv2Ln2hsWfZDvrOcFo30oLe8CPtPFlnq72 k11VFzK0+lE/sGVCE8Q5eVrpCyfOR25SAiOl57iC1z1cS1O3P8R/tEguAZte5yk/bOhe auA4G5J7PQ71jE3nwoCrM9qkU11hwWUoyK9vFkfBp2cEx+I5sgLAndfbXZJtGKHrFE+4 oLK5UBnu7XENgcbapteAJ+/fNmM1Ql4Pxn88Rx/ThQQydRWUAV/sKMSyEGHEnC4OwCmQ IU3g==
X-Gm-Message-State: AOAM531cnuVoYeoE+7cEC1k7NW9pgccT0UiqTC8f0LLz3Rjg+BD1IIHl +AytBBd/7Ns7OZzgPIqbholkCZTZBJiaAqPmA89u1F48CLzz8Q==
X-Google-Smtp-Source: ABdhPJz7kpWQ6NumAHJ493ZhPyPI8lzzJy10APGnrJ/h3pS6m+KIrgjwkGeYWpgC4tltJkaXvMVyD5ghR13OB6EZbgM=
X-Received: by 2002:ab0:48d1:: with SMTP id y17mr6088374uac.12.1643044426020; Mon, 24 Jan 2022 09:13:46 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Mon, 24 Jan 2022 12:13:34 -0500
Message-ID: <>
To: Paul Wouters <>
Cc: Paul Wouters <>, ADD Mailing list <>, tirumal reddy <>
Content-Type: multipart/alternative; boundary="0000000000005d54fd05d65717ee"
Archived-At: <>
Subject: Re: [Add] I-D Action: draft-reddy-add-enterprise-split-dns-08.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Jan 2022 17:13:54 -0000

[Some history removed for density]

On Mon, Jan 24, 2022 at 11:21 AM Paul Wouters <paul.wouters=> wrote:

> On Mon, 24 Jan 2022, Ben Schwartz wrote:
> >       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 "" 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".
> >
> > In this case, "" 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.

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.

> , 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 "
>" 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
> "". Now internal DNSSEC adminstrators need to sync
> up with the external ones. These might be different departments and
> different providers.

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

Other than that, there is no special binding.  "" is an
ordinary child to "", and both the internal (populated) and
external (empty/trivial) versions of "" 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.)

> Alternatively, the local resolver can claim the "" zone, and
> can be NXDOMAIN publicly.
> Yes, it could claim, but again then there needs to be two
> different 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 So the internal one claiming
> "" cannot just forward to the public one. But for data
> outside of 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.

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

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.

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.

Additionally, if I want to steal, couldn't I just claim ".com" ?

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


> >       If you ask the public view for you get no NS
> >       records and no DS records.
> >
> > 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.

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

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

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.