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

Ben Schwartz <> Mon, 24 January 2022 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF49F3A0CDA for <>; Mon, 24 Jan 2022 10:57:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Status: No, score=-17.598 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, RCVD_IN_DNSWL_BLOCKED=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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c-O7SB_x2ofN for <>; Mon, 24 Jan 2022 10:57:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF6313A0CCE for <>; Mon, 24 Jan 2022 10:57:19 -0800 (PST)
Received: by with SMTP id l1so30992181uap.8 for <>; Mon, 24 Jan 2022 10:57:19 -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=kM3BWpymu9hPpOHZW6RfZh4PISg7Fk7XkZrcPCdcR0Y=; b=sE8x9GcCSDTGHQB1UY3P0JjMM15/qgO4Ls+lowzT+FRpkFot5rLZ9YDBjXMltTf6fR gaTTrocA+KK+iodKmi8hmWgwKy4CN/VQWvBL8tNHsyNjkq7qRL2BqdKq04Q64W/XU8uE /ojbY28A9ccJSpGNloZacg9OtbYZsP//3202LSPJp14P8y2YqGn0Xh3HYPzf939WuWD7 EHBwByaHkVKK9cbwDbj86hPcEzGzACM/Kd6BF3kS88HdqNPG+k8aDgHmc8UPQtsCTnsH NtnOlh3170QOcj+H6W9osuYMZd7wJgUQsKrg2qsOuhelstOZZRKnDtorqw02ia1gYcY+ KfSw==
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=kM3BWpymu9hPpOHZW6RfZh4PISg7Fk7XkZrcPCdcR0Y=; b=KoK+9zq5ZjRubAUdBtPGJPQfHmlGFSNWHDTAqgWBaNG/V35qwviUavfRKgWCrZ0sxZ hRlmpCn2E7AKjTbs98TETsotiiJdx3q6P8jfCmTIC4sqFG0UodCfbQgus8GQYjNmIG6C NiH+SC1FkUgt2FQLDfVk8VYHYI6wfqxyBv8dIVFLq3EuG72/Zlk4TwYlHwYwui8DNf6i EzyZPTY4Rsva3OYdBo41LPMb4QvrnQ2wNjlLAN8W9uLF5GtRQWYx4g9A9hw6pI/kEQPT lGgSbfx7NZbnduHwDXDKzwej2F/wdzrLXKPDyHwsXTQePLZftt8CnuoQsfdbgeYpQxS0 XImw==
X-Gm-Message-State: AOAM530fQBA5VmKlsmGK5+H84Aw5cLOUD2Q4Faq4F4yh/qm1n8P+fx4l Oi5CkU9TZnp3i1TY9WxrsLgqXojsPIz7WzaZa1RXSQ==
X-Google-Smtp-Source: ABdhPJyMThvbX6en442cNkbjj64aFpUsnOkpJW4GEWqPr6X86VT2qmCMrYBY73S1ULNz5HMqlgZo6sMyva2Ll3uVDHA=
X-Received: by 2002:a67:df8e:: with SMTP id x14mr6456465vsk.80.1643050637575; Mon, 24 Jan 2022 10:57:17 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Mon, 24 Jan 2022 13:57:06 -0500
Message-ID: <>
To: Paul Wouters <>
Cc: Ben Schwartz <>, ADD Mailing list <>, tirumal reddy <>
Content-Type: multipart/alternative; boundary="0000000000009a30a505d6588941"
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 18:57:25 -0000

On Mon, Jan 24, 2022 at 12:55 PM Paul Wouters <paul.wouters=> wrote:

> On Mon, 24 Jan 2022, Ben Schwartz wrote:
> ...

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

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.


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

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 "")
where this arrangement is sensible and sufficiently convenient to deploy.

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

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.

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

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

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
> those domains to use ACME with DNS, since I cannot use ACME with HTTP?

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


> >       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.
> I see two possible outcomes with the current document:
> 1) It will lead the browsers ignoring ADD/DNR for security reasons.

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.

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--
> Add mailing list