IETF Logo Mail Archive

Re: [DNSOP] Fundamental ANAME problems

"Patrik Fältström " <paf@frobbit.se> Tue, 06 November 2018 13:58 UTC

Return-Path: <paf@frobbit.se>
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 E0BDA130DEC for <dnsop@ietfa.amsl.com>; Tue, 6 Nov 2018 05:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.721
X-Spam-Level:
X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, 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=frobbit.se
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 t7yDVqmCfvvK for <dnsop@ietfa.amsl.com>; Tue, 6 Nov 2018 05:58:51 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF9812D4F1 for <dnsop@ietf.org>; Tue, 6 Nov 2018 05:58:51 -0800 (PST)
Received: from [169.254.123.86] (vpn-client-208.netnod.se [192.71.80.208]) by mail.frobbit.se (Postfix) with ESMTPSA id BC503233DE; Tue, 6 Nov 2018 14:58:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1541512728; bh=3Zlhaz2W/PrtjGDWN0oEEZkM6toa1F7PNqwS81DYxxk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iMwtZ71PHjxN6VtOMDx+Zj87ZuvkEUgim6CQRDpcEX5QF5OHFEzt4MST6cdfp34BJ TsYd7SfYBuGBrPSZTPZpvQPtVQimpughyMajYGr3AS9jSUcf2vAOFffMuUJs31pB+B D4a2RktJd/E5qi3Y+xR1iyDLZpdmsKsqIeF4qM48=
From: Patrik Fältström <paf@frobbit.se>
To: Joe Abley <jabley@hopcount.ca>
Cc: Tony Finch <dot@dotat.at>, dnsop@ietf.org, Ray Bellis <ray@bellis.me.uk>
Date: Tue, 06 Nov 2018 17:58:45 +0400
X-Mailer: MailMate (1.12.1r5552)
Message-ID: <8E469ACD-3E5D-41C7-BE2D-A20A82FA8421@frobbit.se>
In-Reply-To: <CAJhMdTO+tRhyUhArcNUhxqvkCXKCSBfF_-Ts+7WSOV8Qf_ToEg@mail.gmail.com>
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com> <alpine.DEB.2.20.1811021543210.24450@grey.csi.cam.ac.uk> <20181105083526.GA12204@besserwisser.org> <7704C350-256A-42E3-B718-38FD449A2ADE@hopcount.ca> <770d5dc8-b8a3-c1c3-553f-0e9504389750@bellis.me.uk> <CAJhMdTODiJ7DvN5=sFnvEj-FP=M=2yDN_enk17Bo=En9V8bLjw@mail.gmail.com> <alpine.DEB.2.20.1811061338450.24450@grey.csi.cam.ac.uk> <CAJhMdTO+tRhyUhArcNUhxqvkCXKCSBfF_-Ts+7WSOV8Qf_ToEg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_1E1C30C3-DEFC-431A-9112-FC6BFD415820_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rVNgrKqfw2D8ch1pha1KUQpsrqo>
Subject: Re: [DNSOP] Fundamental ANAME problems
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 06 Nov 2018 13:58:54 -0000

On 6 Nov 2018, at 17:51, Joe Abley wrote:

>> On Nov 6, 2018, at 20:44, Tony Finch <dot@dotat.at> wrote:
>>
>> Joe Abley <jabley@hopcount.ca> wrote:
>>>
>>> Specifically, I s the wildcard owner name a real problem in the grand
>>> scheme of things?
>>
>> My understanding is that wildcards don't work for SRV because the
>> _prefixes are used to disambiguate which service you are asking for,
>> effectively to extend the RR TYPE number space. So if you wildcard a SRV
>> record then the target port has to support every possible protocol :-)
>
> Right, but my point was that wildcard owner names aren't seen at the apex, so a solution to the problem of what to do at the apex doesn't need to worry about them.
>
> Ray has wider aspirations than just the apex. This may well be sensible, but I think it's worth calling out the scope creep.

We should also remember that there is a different goal as well, and that is to be able to delegate the zone within which "the records dealing with web" is managed so that the administrative responsibility is separated between the one which run the zone for example.com and the ones that run for _http._tcp.example.com (or _tcp.example.com).

   Patrik

v2.23.0 | Report a Bug | By Email