IETF Logo Mail Archive

Re: [DNSOP] why did SRV care to avoid conflicts

Mark Andrews <marka@isc.org> Mon, 26 March 2018 23:37 UTC

Return-Path: <marka@isc.org>
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 D61B41277BB for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 16:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 rOSWnYoZFd18 for <dnsop@ietfa.amsl.com>; Mon, 26 Mar 2018 16:37:14 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80F512778D for <dnsop@ietf.org>; Mon, 26 Mar 2018 16:37:14 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5DCF83AB06A; Mon, 26 Mar 2018 23:37:14 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1258016006B; Mon, 26 Mar 2018 23:37:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D8EFC160070; Mon, 26 Mar 2018 23:37:13 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3j3jbp_H_K25; Mon, 26 Mar 2018 23:37:13 +0000 (UTC)
Received: from [172.30.42.90] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B998716006B; Mon, 26 Mar 2018 23:37:12 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAMm+Lwgxbm47vjLOKYPFK9isaK1jiLcB=jTjzwhvk+epDiP6cQ@mail.gmail.com>
Date: Tue, 27 Mar 2018 10:37:10 +1100
Cc: Paul Vixie <paul@redbarn.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E76BB37-E878-4ABE-959D-6CB65895C90C@isc.org>
References: <5AB96F3C.4090204@redbarn.org> <A400D2A3-3866-4EE3-879B-479991581502@isc.org> <265EBB42-4042-40BE-88C5-F3FEB6540DA6@isc.org> <5AB97728.70202@redbarn.org> <23B89A43-06D8-48B3-B8AD-7DAA3A5FD9A9@isc.org> <CAMm+Lwgxbm47vjLOKYPFK9isaK1jiLcB=jTjzwhvk+epDiP6cQ@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3INJnImZeWON7BLFqOI6_nuNFNY>
Subject: Re: [DNSOP] why did SRV care to avoid conflicts
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: Mon, 26 Mar 2018 23:37:16 -0000

> On 27 Mar 2018, at 10:29 am, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> 
> It is potentially very useful that we have the underscore convention. We could define wildcards that worked correctly (i.e. as expected) if we wanted to. 
> 
> The DNS was designed to publish addresses for hosts, we now use services. As a result we have an overloading issue because we only have one hierarchy for two distinct types.

The DNS was designed to publish data with hierarchical ownership of the keying.  It is only registry policy that stops non LDH names being delegated that the top level.  The DNS was ALWAYS more than just data related to hosts see MAILA, MAILB, MX etc.  Those records are designed for names that are NOT hosts though they can be used in conjunction with names refer to hosts.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email