Re: [Add] add-enterprise-split-dns and split horizon DNS

Dan Wing <danwing@gmail.com> Fri, 03 December 2021 01:46 UTC

Return-Path: <danwing@gmail.com>
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 B0A143A0F5C for <add@ietfa.amsl.com>; Thu, 2 Dec 2021 17:46:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.com
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 7TKd8QZUdmxp for <add@ietfa.amsl.com>; Thu, 2 Dec 2021 17:46:23 -0800 (PST)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 38DF03A0033 for <add@ietf.org>; Thu, 2 Dec 2021 17:46:23 -0800 (PST)
Received: by mail-pl1-x630.google.com with SMTP id b13so1033576plg.2 for <add@ietf.org>; Thu, 02 Dec 2021 17:46:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MXdfXuIS5fZK9hz0bd++b5Eu6mM8iu8y4qifAT68ujw=; b=e4lwAbUh/sULYkR2Wt0bZzJ6dfyznc237cDhEXJFGHGP0mT9JKsq7OV+dEc3Oeaz2f 9TU1QQ9AxxkRij8DZ5kJ5CcETTrPuy3EYZAeiWlMrlWZwPJ4gOQlCCDOoTfEqVyNFgTp FgRw7G5Cb/fGqMio+Ovg8YJHsu41SzW2scPbhvLDAAFYsLHEUaq8SHGbhMSfAa59Ffwc fG+LTXVRizqVt0vqlxj8U0VjpqpGpcK4CLLOF/igQaTmN8icevCMDWJFjIbVkxMorDRN /X3zdokYiKw0wuGpAEhjde0NCxNR7nCCZDiq1xiGwh/qpjDQ4ff6gsMadXwtqLyUWGlS LWRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MXdfXuIS5fZK9hz0bd++b5Eu6mM8iu8y4qifAT68ujw=; b=O1TsMpIv6Oc4cVozTsAiM7myPIrJd+OV+tGItcMA7LKyvk5FZdTt+5bOXX5qpvrwmy i5mR7S/ksELPX5AclpP0wRQHI7eWi1rU/EDfFE87FtAlqH7f42i7L6SYaRpMc+wM2iHi hNUTnRAp2TpXQzmO7Mj1QoAb6tdjxBmgWvC6FIuQF5iXizqtkkBzwY9PQ6KRyWvg+GWo GgwL3h925mIaODUJ71qmnARgFvZdSOfFvNWWeNlybVn60GRKruFq96aZEWecx+gTVUh6 PQSmR0hyeyZlRoHzFl8OA+6rtQUmnzKqXCJozDkMQUvd0RHd7JDjzaLOzOJnOY45iJU/ UTfw==
X-Gm-Message-State: AOAM5334kqzPUVzMSw0AeC/BIHJU/jOhA+z1IV+F4yDZHpzrw2SiwOxB tt5J0uEX9BaTexN8sAlubnVNLO7jxW8=
X-Google-Smtp-Source: ABdhPJwEwf8Dv6kNzfn+2q6lt2hPm0Yf51cbdcyRT5Yk6kGdDN7QV7pINqScBvKNCKgNL+aOmcIa2g==
X-Received: by 2002:a17:902:7007:b0:143:c6e8:4117 with SMTP id y7-20020a170902700700b00143c6e84117mr19663704plk.55.1638495981272; Thu, 02 Dec 2021 17:46:21 -0800 (PST)
Received: from smtpclient.apple ([50.237.2.154]) by smtp.gmail.com with ESMTPSA id s16sm1005365pfu.109.2021.12.02.17.46.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Dec 2021 17:46:20 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Dan Wing <danwing@gmail.com>
In-Reply-To: <152347.1638473207@dooku>
Date: Thu, 02 Dec 2021 17:46:18 -0800
Cc: add@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <60F1A5E0-056F-4B43-B4B9-EDA893ECDAE3@gmail.com>
References: <152347.1638473207@dooku>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/zBz_zDWTH12dh2ryWhuJmjCZmMU>
Subject: Re: [Add] add-enterprise-split-dns and split horizon DNS
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: Fri, 03 Dec 2021 01:46:28 -0000

Split-horizon DNS has the same name on the inside ("private") network as on the outside ("public"), but they resolve to different IP addresses.  So, www.example.com on the inside resolving to, say, 192.168.1.1 (an RFC1918 address to make it clear it is not Internet routed) and www.example.com on the outside resolving to 1.1.1.9 (I would have used 1.1.1.1, but, alas, that's used by a Real Server now-a-days).  If there is an internal delegation where "corp.example.com" is only resolvable from the inside that is not "split DNS" -- at least, not by my definition.  Such an internal-only delegation is a far easier problem because if the wrong DNS server is queried, it won't have any answer (ignoring data leakage issues of querying the wrong DNS, of course).  Split DNS is complicated because querying the wrong DNS returns the wrong answer and the wrong IP address is either not routable from the Internet or gives the public view of the resource when the "employee" view was desired.

I agree the proposal in our document may not be ideal.  During the presentation and Q&A we discussed briefly another approach to test for a squatted domain by using DNSSEC rather than querying a public DNS server.  We intend to add that to the document, but, more importantly, intend to compare/contrast the approaches.  I hope to get to those edits with my co-authors before Christmas and back in front of the working group.

-d


> On Dec 2, 2021, at 11:26 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> I have just watched the ADD-20211108-1600 session from IETF112.
> I had a conflicting session.
> 
> What I took from the conversation is that many people would like to solve DDR
> in a split-horizon situation, and that if we could find a solution that
> solved typo-squatting by local resolvers that would also be very welcome.
> (typo-squatting is of course trivially solved by DNSSEC, which I'm told
> browsers refuse to implement because miliseconds...)
> 
> The document says:
> 
>   A typical use case is an Enterprise network that requires one or more
>   DNS domains to be resolved via network-designated DNS servers.  This
>   can be a special domain, such as "corp.example.com" for an enterprise
>   that is publicly known to use "example.com".  In this case, the
>   endpoint needs to be informed what the private domain names are and
>   what the IP addresses of the network-designated DNS servers are.  An
>   Enterprise can also run a different version of its global domain on
>   its internal network.  In that case, the client is instructed to send
>   DNS queries for the enterprise public domain (e.g., "example.com") to
>   the network-designated DNS servers.  A configuration for this
>   deployment scenario is referred to as a Split DNS configuration.
>   Another use case for split-horizon DNS is Cellular and Fixed-access
>   networks (ISPs) typically offer private domains, including account
>   status/controls, and free education initiatives [INS].
> 
> and I'd like to strongly distinguish the case of "corp.example.com"
> (I've also seen and used "intranet.example.com"...) from one where there are
> different "authoritative" views of example.com.
> 
> In fact, I'd like the document to put these two into different sections.
> I think that we need to write a BCP that strongly encourages corp.example.com
> as the model for hiding names.
> Dan and Wesley mentioned previous efforts that had failed.
> I'd like to understand more about what was proposed and how/when/why they
> failed.
> 
> Maybe the issues are different now and we could get consensys around something.
> Yeah, maybe that does not fit into the ADD charter: but it seems that ADD
> (DDR) might be a forcing function to finally do something here.
> 
> I don't like the solution in this document.
> I am in favour of solving the problem though.
> I don't like PvD at all.
> 
> But, the entire issue seems to fall into the "Doctor! Doctor! It hurts when I push
> this knife into the electrical socket! What can you prescribe to deal with
> the hurt?"
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> -- 
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add