Re: [DNSOP] Terminology question: split DNS

Matthew Pounsett <matt@conundrum.com> Wed, 21 March 2018 01:44 UTC

Return-Path: <matt@conundrum.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE2412D875 for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 18:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.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 lNY9Jq892w8H for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 18:44:39 -0700 (PDT)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 069111241F8 for <dnsop@ietf.org>; Tue, 20 Mar 2018 18:44:38 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id c1-v6so3894531itj.1 for <dnsop@ietf.org>; Tue, 20 Mar 2018 18:44:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sOUvioH7E/Pd/TFOpH/3VyFNVfZ76gjpYKOdqZ3AxNc=; b=jYyFmxcGASK06smPdD2Oh5+q00JxT0A6+IFiGjlUqmajH7PaIHVe+SNkViBVswA0zm PoHd+QVzaCDTI0H/x3KCt6CP4ZKJryQ4pmlmZl2BOYZCTF+7Av+AKAACbYV3gZZmcoKD mgDbPyucOjk7Btlq2alTzvrZ0Qze7ASIDSOXLpwAexUN9V04HrAlwsyF49uCIX5aoxPz 1lXAb+AKrH2GGSqrhmgHvAy3VDUX9KtwbichFdbTLym8QgPSOPGpLBp8xvV17z4l0RAu lfm5bJ6Gnu+8uZ9CaXpnEBRvEjednL3Nj++CsGLuzxQOw/SuzCmYveokBpSxH/9y/zFK 3oJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sOUvioH7E/Pd/TFOpH/3VyFNVfZ76gjpYKOdqZ3AxNc=; b=Rwu1aeUBUn/FGRzzkFB6zDwTk5usAC7Z1EiOe+tQ+Pw4qHGqeaC9FduYZolDLigjWm OdTz6WwKRQbl9ANpgiSWBXvS9azFV7DUdLCkiQMjURkqD5AtcGMtjHU3LXD2Dhaj5770 ZslqiZVal3d0YJyMlfZop+c5kN+VcPzm3KXqhff+/AwYKcfrRhmgPm/G1T2auj2gwTX8 3G7QBG3/sXCBTZ48fZuE2U3EZ3XWB8OmwuqBhcRRSq0mXIvJhtavH/coKVquuhCQnhpF oSno7rf+qULC/VOPAni4yk1slop5d/XkyTk16k/DqP9MNP45t8XkeKA9anj0tcl8GoJa 28uQ==
X-Gm-Message-State: AElRT7Hd0vCnElPKCjS4VOibGcYEyhWrmTQH/Co+wAnr8cobPRQtwjIM OZbUKFxuf9H/vQAumv5xwtASEakuf1Kjbdd5Dq+KUg==
X-Google-Smtp-Source: AG47ELts30ZZZFAFFRWtlgW2CLnwx3a8ITybkHSEHTrfqdo1aLah+0AJ2YSV/Up4swSK2ybUkeEVq5LVy4KsFCnTN3c=
X-Received: by 2002:a24:7813:: with SMTP id p19-v6mr2122216itc.115.1521596678061; Tue, 20 Mar 2018 18:44:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.2.112.197 with HTTP; Tue, 20 Mar 2018 18:44:37 -0700 (PDT)
In-Reply-To: <c4ce2d41-8af3-9ad2-4c1a-3b1433786592@brokendns.net>
References: <3D490CA8-0733-47AD-A088-113B1116B207@vpnc.org> <CALZ3u+a9o1g0ZTkGjqWwfyV9phovEgu6Linp137yvM=JHSnj-A@mail.gmail.com> <CA+nkc8DrHTVkbPJDEGksnoN3e-DQtKV1=owOA5pLAUWG+depzw@mail.gmail.com> <CALZ3u+bs+uDm16UiHp6fAF+EyrA9FBcbvYhRap76Wb6MCz_vOg@mail.gmail.com> <374BF611-71C4-4E37-A725-B214527328A0@rfc1035.com> <c4ce2d41-8af3-9ad2-4c1a-3b1433786592@brokendns.net>
From: Matthew Pounsett <matt@conundrum.com>
Date: Tue, 20 Mar 2018 21:44:37 -0400
Message-ID: <CAAiTEH_ndkJUmkVPV7-Uv25ET5ZnenLU2SHO-wOXynuX0ttJ6A@mail.gmail.com>
To: Michael Sinatra <michael@brokendns.net>
Cc: Jim Reid <jim@rfc1035.com>, Artyom Gavrichenkov <ximaera@gmail.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007d19b60567e2552f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uLuFFJV6Kje6Vqfl6WxYMRSD9cg>
Subject: Re: [DNSOP] Terminology question: split DNS
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2018 01:44:41 -0000

On 19 March 2018 at 17:24, Michael Sinatra <michael@brokendns.net>; wrote:

>
> Rather than try for some physical demarcation like "firewall" or
> "network," why don't we simply say "organizationally-defined perimeter" or
> "perimeter defined by the organization," which leaves it vague enough to
> support the "many potential variants"?
>
> E.g. in Paul H.'s original text
>
> Instead of: "Where a corporate network serves up partly or completely
> different DNS inside and outside its firewall."
>
> Use: "Where a corporate [enterprise?] network serves partly or completely
> different DNS based on a client's location inside or outside of a perimeter
> defined by that organization."
>
> This also gives the enterprise organization both the authority (and onus)
> to define its perimeter in a reasonable logical way.


And I would leave off "corporate", "enterprise" and any other qualification
of who's using the technology.  If there's no reason to specify the type of
network it might get used on, then we shouldn't.