Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

Dan York <york@isoc.org> Thu, 08 November 2018 04:47 UTC

Return-Path: <york@isoc.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 77F091276D0 for <dnsop@ietfa.amsl.com>; Wed, 7 Nov 2018 20:47:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=isoc.org
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 7J5wUhhiuMiZ for <dnsop@ietfa.amsl.com>; Wed, 7 Nov 2018 20:47:54 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740041.outbound.protection.outlook.com [40.107.74.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD439130DFF for <dnsop@ietf.org>; Wed, 7 Nov 2018 20:47:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ji9NT4LpsyYrdQMZRUywf3wePLw99rQD0C+Zv0lTsGY=; b=QX4YVKXb7JilTL0pEMBkDePjWTLWbkdEpE+lWdUe007WLHohpCDs73ZYZWRqspITGo2b7wow4UdYAvTU2XQhWlweEsX9+EIOYeWdVfAcEPLlSbzsElz7CYusIjfyWBo0BSfjXg8TetPg2Klyo/Gdn5BUsyKuCSPKDv/WDBNUXSI=
Received: from BN3PR0601MB1314.namprd06.prod.outlook.com (10.161.210.139) by BN3PR0601MB1526.namprd06.prod.outlook.com (10.163.40.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.21; Thu, 8 Nov 2018 04:47:51 +0000
Received: from BN3PR0601MB1314.namprd06.prod.outlook.com ([fe80::6ddc:e11:56b8:b6ba]) by BN3PR0601MB1314.namprd06.prod.outlook.com ([fe80::6ddc:e11:56b8:b6ba%9]) with mapi id 15.20.1294.034; Thu, 8 Nov 2018 04:47:49 +0000
From: Dan York <york@isoc.org>
To: Brian Dickson <brian.peter.dickson@gmail.com>
CC: "dnsop@ietf.org WG" <dnsop@ietf.org>
Thread-Topic: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
Thread-Index: AQHUdwsdWdJBJc5rk0KlCNC9d9wpAaVFMgeAgAAG0ACAABVpAA==
Date: Thu, 8 Nov 2018 04:47:49 +0000
Message-ID: <D378E8F5-A667-4649-90ED-7C3612F0A013@isoc.org>
References: <CAH1iCirLfSEUcTf=p5bHuFJSFie_BoPh4X=89w2mpxgNpR9HkA@mail.gmail.com> <2BDA0411-202D-4199-A43B-3FDC50DC47F5@isoc.org> <CAH1iCirdkU-jYLRGeOm3DcdsReShyOez3oU5hw5sJYEtQyyqGw@mail.gmail.com>
In-Reply-To: <CAH1iCirdkU-jYLRGeOm3DcdsReShyOez3oU5hw5sJYEtQyyqGw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org;
x-originating-ip: [2001:67c:370:128:2935:ac23:ae80:eddf]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1526; 6:K9KuZiC31M1AMmikxO6LqR7acR9Gba52qXvx9aujTl0oVGnzWkDWZ2LJWmpJlbN0CdM1eZ4uWsHD/G+bG2Yn5e+84VsD7nB3250rdY+enNzXBiMDIsNxG43ydGAjVxWE4Ijp/0EiISMRCtuj0ZU5BzlQT0PjR2wPMLG01iXebX4Dw1p+JQqxMm50IINusZdkQrqHVsk3Hw5sodTLjlpf5WQ8xWnkKwIX8YMcNWHGqLh293rYQt0zb5y45PqfuPHGj+ccFQUIAUokoe7v2EgFG3/el/QKwRWkcfHUCuTC/AdGsp9F1d9pWvQXW57RBLi8kf//N47CHxZjYntDXSkXeTbMM742UChOYwguIEw4EYWG7oNKIaHHE77rMLuB9VXdby9EgdrUAGTPpOSwe64S6k9OILqUwZsHYTQVsr4s85EiN9NL6Q20gs4qLm3xwpcMxyyPXfP8vMTfNuOhLJjWug==; 5:iMckws39r0hvOeavt/Ey38chAzxaRkG2468M8MwQjmuhBa1+3PpsJNteVUsX8L1daWBzD2HspftEr38RdIJt0/st9KVjScj4d7lmPRmE6XkVTn913q9vunDPomaG+Ze1X3E70+fJa2CuRqTllmr3ky2+Ga8KiZzwU50uyWps2Bg=; 7:pFFPq2yZqoZ7N6agwHb4ugg0t55enpg9eBKGaCxWZK91i/imPhyscZOr9USaeTeXS3XGw8rK9LJNYCbuYSiwXIY7FgfrvkL0pso51KPZut0XUKwIj1A/OtFUm0A57w2jJ3YX68pCnjQL1ad3OkknUg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9c23b652-7102-4d6a-fdf0-08d645355603
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN3PR0601MB1526;
x-ms-traffictypediagnostic: BN3PR0601MB1526:
x-microsoft-antispam-prvs: <BN3PR0601MB1526358652B30BA9D0EDD2FFB7C50@BN3PR0601MB1526.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(31418570063057)(85827821059158);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231382)(944501410)(4983020)(4982022)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BN3PR0601MB1526; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1526;
x-forefront-prvs: 0850800A29
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(39850400004)(366004)(376002)(396003)(189003)(199004)(106356001)(33656002)(6306002)(6512007)(105586002)(5660300001)(1720100001)(99936001)(68736007)(8936002)(97736004)(39060400002)(53376002)(446003)(4326008)(14454004)(46003)(25786009)(11346002)(2906002)(53936002)(486006)(6246003)(966005)(476003)(2616005)(2900100001)(6486002)(6506007)(71190400001)(76176011)(53546011)(71200400001)(8676002)(36756003)(229853002)(102836004)(7736002)(316002)(186003)(256004)(14444005)(82746002)(478600001)(6116002)(6436002)(81156014)(99286004)(83716004)(81166006)(86362001)(6916009)(305945005)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1526; H:BN3PR0601MB1314.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts)
x-microsoft-antispam-message-info: ZRktlPlaUtsEQhIjge63yXuLkc3D2WY0CSVQk6HkaUKcxSwYiByNICoC9qcFyS5SeEYoiJCXZjOIMP01aSTgwwstFNldHQcbzLmCfLlDAtLHVPju7D7QUKlr2N2grteW/300QirXH/ua/BIJpNSHZYSPAMMwrkdiUH8p7NQJZDGsa7Wk5oZ992sKjVo5V+IOy9xppLwJIwE8K59tiRqS5VIX92hNjBV/SjLqw7Ss3trgL8K4tf1buIbeD72U7/v0fEY+GsFGV62vvhw7siymNIWO1NxZ4qOlcsjtKUwVTCPR+dERDXynylbidMob5hZmDn29hapLzRlHrn9Nx0h7bnTNd3P+/UeSnA6I9iM0NrA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_C4196E12-F81B-4226-B02D-30F242D50E0D"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c23b652-7102-4d6a-fdf0-08d645355603
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2018 04:47:49.7138 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1526
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/SMdSRpl-RPFfUz2uyG2qVyGB-lo>
Subject: Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
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: Thu, 08 Nov 2018 04:47:56 -0000

Brian,

> On Nov 8, 2018, at 10:30 AM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
> 
> For new RRtypes, registries, registrars, and their provisioning services do NOT need to support them; the new types are in the zones only.

DY> (Experiencing a "DUH!" moment.)  Yes, of course. It's zone data so only those entities handling zone data need to care.  In my still-annoyingly-jet-lagged mind, I made the classic mistake of equating "registrars" with "DNS hosting operators" because so many registrars are *also* DNS hosting providers.

> New RRtypes which do not require any "additional" processing, do NOT strictly speaking require resolver support, since resolvers handle unknown RRtypes. (Mark A can quote you the RFC, and I think has recently.)

DY> Ah, interesting. Where the proposed HTTP RRtype has behavior similar to the CNAME record, my assumption would be that resolver software would need to know what to do once it receives the record.  For that reason, wouldn't all the resolvers (or at least an extremely high %) need to be upgraded to support the new record?

> On the plus side, I can confirm at least one hosting/authority service will do this as soon as a stable spec is available (i.e. HTTP and a code point early allocation).

DY> :-)   Good to know!

Dan
--
Dan York
Director, Content & Web Strategy, Internet Society
york@isoc.org   +1-802-735-1624 
Jabber: york@jabber.isoc.org  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/