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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 03 December 2021 22:56 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 0DF7E3A0AC1 for <add@ietfa.amsl.com>; Fri, 3 Dec 2021 14:56:44 -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 (2048-bit key) header.d=sandelman.ca
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 nPoTzkPuk2DH for <add@ietfa.amsl.com>; Fri, 3 Dec 2021 14:56:39 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EB33A0A84 for <add@ietf.org>; Fri, 3 Dec 2021 14:56:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1467B38ADF; Fri, 3 Dec 2021 18:00:05 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id equDztwWYmFK; Fri, 3 Dec 2021 18:00:03 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D258738AB3; Fri, 3 Dec 2021 18:00:03 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1638572403; bh=qqaTBXoWmlRfEYPHQLp93XWRtdefV3o6a8+g4/NJyOA=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=+BrjdcvmfajV4IqJZpYbZWRubS1nCyDl4uqeq6m2rEnOk9q6Z6QC3KLFIRMkCjtu1 m3qdM+RcR2aIQaotdZYbZKlwwJllnqjz5It7lc1IzSnG15efWLHoQjCfF1l4GKep+4 HQfTpG4VD7Nf8n0lBkXxTpQvUoXWFiHTwVkZcLt7aQihmse1TWxxwdAky55+4jBu1F 4zKyWx5q4npES/khz0DbZiSO9qoY2+lOtAK3oZjfW/2KBkQQbfxM+kE3fKBUgBVACP bqNq5pQL+z7N3IktxLIn3yqNUUhXt72lzUVrpKZNeKt2eEToFMLri9gZXWHL56dUm1 yYMUNeSCkKsxA==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EC9677EA; Fri, 3 Dec 2021 17:56:36 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Dan Wing <danwing@gmail.com>
cc: add@ietf.org
In-Reply-To: <60F1A5E0-056F-4B43-B4B9-EDA893ECDAE3@gmail.com>
References: <152347.1638473207@dooku> <60F1A5E0-056F-4B43-B4B9-EDA893ECDAE3@gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 03 Dec 2021 17:56:36 -0500
Message-ID: <17914.1638572196@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/VauSeqe-4KF1NMp9S6P81H7UEKc>
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 22:56:44 -0000

Dan Wing <danwing@gmail.com> wrote:
    > 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

Sure, I'd love to give it a clear name to distinguish it.
The document in question attempts to address both situations, however, and
that's the document that we are discussing adopting.

If the document wants to restrict itself to what you think of "real" split-DNS
then that might be easier to decide.

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

Yeah. It totally sucks.  I think we should tell people to stop doing it.
I think that securing DNS lookups (whether by doing DNSSEC locally, or
speaking to a recursive DNSSEC validator securely), and providing privacy is
a sufficient hammer to get people to change.

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

Awesome.
Can you also give us a name/handle to talk about the corp.example.com
"private" delegation.   I wrote a document about this a few years ago.
I called them secret gardens, rather than walled gardens.
(I always wanted to read _Secret Gardens_ as a kid. I could never steal the
book from my sister though)



--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide