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

Paul Wouters <paul.wouters@aiven.io> Mon, 24 January 2022 17:55 UTC

Return-Path: <paul.wouters@aiven.io>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E1B3A0E64 for <add@ietfa.amsl.com>; Mon, 24 Jan 2022 09:55:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0Ct26oByDW1 for <add@ietfa.amsl.com>; Mon, 24 Jan 2022 09:55:44 -0800 (PST)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29EB3A0E60 for <add@ietf.org>; Mon, 24 Jan 2022 09:55:43 -0800 (PST)
Received: by mail-ed1-x533.google.com with SMTP id j23so52896574edp.5 for <add@ietf.org>; Mon, 24 Jan 2022 09:55:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=d/HaJzgoRP8ioMipm+S/h8fyJyzyAix6CPyV2ceDMAQ=; b=I35wY6IwJWkw7fdc5YzrDVg8etQl3hOP5xWjyrKTdfVdT9Z+KI4pwhRGotk/LR2MYY 9RheRF6boAcbh2urf373yEu0Vo3m+zdoAWbHO6yGoc13Oo04Zy/4O+XzWNBYl65X6hGe y464K82+b1JWkspk7TbvRJrGs/xwKUyJJkgdY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=d/HaJzgoRP8ioMipm+S/h8fyJyzyAix6CPyV2ceDMAQ=; b=KNWi5g3kC8WfBSj0ILraBVm04O8sAGCPOrn60jPK+U4SU04Q+tcI+ZxP/s2JW28B72 wWS2OEz5ODakRUVniSPRNboqA3HnuCf8fB6i/+VYkPmeLZUN5EVxXSQCuRxzHUuQXxK6 vdZKnRuRr0LoAUQ/w8qt+GphqvBV1oVqIH+TZMmCrYPMKjk9uue2AHgkmxNqCJgGbIOQ w+1ErfinpN9VFKjx+PJO8JnubvC2vFMTu7PjY/GdCkXwWJzspU1VlSM0MHxRMX8t9mug VWB0Dif0EyuhX2mk+/pocTPMjZwVmp2b1YdhK7EM8MIUAzOqju1k/sLTNsQtdCoXYP2Q saeA==
X-Gm-Message-State: AOAM5329qcfvV+UqOzEim2jv2KN/EZLE9X92N1W7djBK5HrvqfA3/kG4 sbRViEwlM4+ofYJVUNvfYJfB4g==
X-Google-Smtp-Source: ABdhPJwVB/PKuPEIbcAGiCDVnL4pM3WK0H3mlcC1CsPFN/B85UAP6X6YcPoLX40pWKFALD1QENagaw==
X-Received: by 2002:a05:6402:5112:: with SMTP id m18mr17109314edd.191.1643046941497; Mon, 24 Jan 2022 09:55:41 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id h20sm6599238eds.9.2022.01.24.09.55.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jan 2022 09:55:41 -0800 (PST)
Date: Mon, 24 Jan 2022 12:55:37 -0500 (EST)
From: Paul Wouters <paul.wouters@aiven.io>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
cc: ADD Mailing list <add@ietf.org>, tirumal reddy <kondtir@gmail.com>
In-Reply-To: <CAHbrMsAi+0kK12SOguaB69icJfZ4VzsavURz_3iBsm3ZwnDk0A@mail.gmail.com>
Message-ID: <898155a3-b2-b345-c15d-125974daec@nohats.ca>
References: <164273967921.28045.13105308218406662743@ietfa.amsl.com> <CAFpG3geerJH+jWEZpZnHJpEFcOr+81WyOFvWoAaHmR6N4jBZyg@mail.gmail.com> <4182fe-1e8-ef1-d3e5-75b17da23b9e@nohats.ca> <CAHbrMsBvy6F05y+rXzS+KtpOCn4+RCcJnjLdduHfdz8ENCOQzw@mail.gmail.com> <54f568df-79ba-cc41-6337-a0f45c44344e@nohats.ca> <CAHbrMsAKAQjCZQrwTKp3_NiFh194ST54n1dOOM7WQ4ydi=yOFA@mail.gmail.com> <532c969a-8793-81a1-17c0-55ae5b21fad3@nohats.ca> <CAHbrMsAi+0kK12SOguaB69icJfZ4VzsavURz_3iBsm3ZwnDk0A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1858192029-1894722060-1643046940=:942020"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/WRHYqw5uQvEZEhhdDfVfm_z4r8M>
Subject: Re: [Add] I-D Action: draft-reddy-add-enterprise-split-dns-08.txt
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2022 17:55:49 -0000

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.

>       Additionally, if I want to steal gmail.com, couldn't I just claim ".com" ?
> 
> 
> 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?


> ...
>       >       If you ask the public view for internal.example.com 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.

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.

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