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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 732553A0E08 for <>; Mon, 24 Jan 2022 07:17:03 -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 FZWNIodFB2dn for <>; Mon, 24 Jan 2022 07:16:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A1FA3A0E07 for <>; Mon, 24 Jan 2022 07:16:58 -0800 (PST)
Received: by with SMTP id l196so7469158vki.5 for <>; Mon, 24 Jan 2022 07:16:58 -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=OYit4cotWWxXF9Rm/2fbFSaXAc79DQikvJ3Y8hHj+Dw=; b=a+UpFbM6tBU9fOXaE4G6g8hjAP8M6EiPcmZ9r5nG6RQJo0a+jHYcy1K4d+EGzTVYfC AXRRT6BR8H7FrTJGxkylly5+Z6bihEIxFN9vg5FeCCqKYVyuQ/yGBIRNfs6tOQVn8Tco CkEamBFjRUpYRgMk+lAr+F7wSB8FRbwL2ehEK/Bj/9PvNZeQKzhax4w2bsh8KNdVwpep zYIVISPsVSKpZJ5iKLn00CEVfchGZI1XzTADOsKLNDifgH+L9zAksuu7OYwCBOBJuNOh lUW61IcPdDgN9wwUra+6FE79SWadhzgpf+RjX+rpKGs8Qd5cEsPe3CnudaEwNZWCd1gJ wC/A==
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=OYit4cotWWxXF9Rm/2fbFSaXAc79DQikvJ3Y8hHj+Dw=; b=Hgqa7sjLjl0l40jG+QQkJSHISDqO0atoxrXonr2o1rN9VVCnwslQdtO4ORysA57nOL N+iVK8viky6KYGKIu8t6uc0LLrZz1myCaOzyUGSVHbGKKVHUtJLJPT4AQRv5Q98E7g3W Nz7Etn81maBWssF64ZTsuihXAQwjHXykiJ9XOeU9j8FrhW09aFFKNIJ0BSCnPnuqaNhq 3ruLnR4sYoc3tKq+KFcpPBbj20EvYBrBz1Gxsi+UN/n50VxmKuPxOjrBcbf/VDw5O5hH 9k12FJp5rV8QfS0rvb7v1pd2Q7vQDYXlMAYXtTxuCk0a457gw95nUy1l8kWL8awHAySS vZBQ==
X-Gm-Message-State: AOAM5319x9+0bnRKfeYhgmljk+sUsRMlpIyZ7WK9jLfXwQ8DfdADz4qR qdoa4pVlduIsA/N5YCYh0Qa5RbOenfL1c6AYYZ7xhmPE9ls=
X-Google-Smtp-Source: ABdhPJwp5topuW/cWe0ee77ot2kU2DizqK0/KhlYyFwP1q1VMbAJFEHZk6fkzSYJ2tPgReotUAX18HIBWoqLkGEcmPg=
X-Received: by 2002:a1f:2089:: with SMTP id g131mr6017090vkg.14.1643037416933; Mon, 24 Jan 2022 07:16:56 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Mon, 24 Jan 2022 10:16:45 -0500
Message-ID: <>
To: Paul Wouters <>
Cc: ADD Mailing list <>, tirumal reddy <>
Content-Type: multipart/alternative; boundary="000000000000972faf05d6557535"
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 15:17:04 -0000

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

> On Fri, 21 Jan 2022, Ben Schwartz wrote:
> >       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'm not sure what you mean by "internal-only domains".  To be clear, a
> domain like "" is "properly rooted
> > in the global DNS" if it is done with the permission of "",
> even if "" 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 "" 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, 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.

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

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

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.

> > ...
> >       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 ""
> >       resolving via the internal view of the split, can obtain the
> required
> >       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.
> 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.  If the zone is (publicly) signed, then it must also
have publicly visible DNSSEC 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.

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

Once the document is fixed to somehow contain the proofs of the internal
> view that "" should be queried for at,
> then if you want 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.

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