Re: [DNSOP] Minimum viable ANAME

Dan York <york@isoc.org> Tue, 26 March 2019 22:49 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 01BDC1200A0 for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 15:49:23 -0700 (PDT)
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 DaVZnUWvPHpo for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 15:49:20 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740079.outbound.protection.outlook.com [40.107.74.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F0E1200F8 for <dnsop@ietf.org>; Tue, 26 Mar 2019 15:49:20 -0700 (PDT)
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=iKzh41TvpqzLzHCwoQKccfDNUG8e2TBQCXmXu//TGSs=; b=tbiZmuW6yQqGtVBCeA6u8F6gWZ6jU/MU5x5ZPWdT1LpvtNBLcqIo5ql+b/uQ5QJ98Uxim3HtObB6kkqZ0RzKB/LLL859ohiftKJkhJBafDdT6yyTkMMLGz4yDpH1qW0JZ5x+STkPZLpujtlecx21nqZn3DBOVsfG2reokNyxGOQ=
Received: from BN8PR06MB5570.namprd06.prod.outlook.com (20.178.210.219) by BN8PR06MB6210.namprd06.prod.outlook.com (20.178.216.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Tue, 26 Mar 2019 22:49:17 +0000
Received: from BN8PR06MB5570.namprd06.prod.outlook.com ([fe80::c56c:bd9b:2aba:e8b4]) by BN8PR06MB5570.namprd06.prod.outlook.com ([fe80::c56c:bd9b:2aba:e8b4%3]) with mapi id 15.20.1730.019; Tue, 26 Mar 2019 22:49:17 +0000
From: Dan York <york@isoc.org>
To: Brian Dickson <brian.peter.dickson@gmail.com>
CC: Olli Vanhoja <olli@zeit.co>, Tony Finch <dot@dotat.at>, dnsop <dnsop@ietf.org>, =?utf-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat@nic.cz>
Thread-Topic: [DNSOP] Minimum viable ANAME
Thread-Index: AQHUUCCNhr8K/vb1KUWcR5OtIkNAF6T4ClqAgAAPS4CAAJhDgIACB0WAgEPVPQCA4JOsAIAAEAQAgAABFQCAAAlNgIAABw+AgAAHUQCAABbMAIAASl4A
Date: Tue, 26 Mar 2019 22:49:17 +0000
Message-ID: <00A48138-CF24-46BC-A529-CC5C57F2CF65@isoc.org>
References: <20180919201401.8E0C220051382A@ary.qy> <08C8A740-D09B-4577-AF2A-79225EDB526B@dotat.at> <20180920061343.GA754@jurassic> <E944887D-51ED-41A0-AC5A-3076743620D8@isoc.org> <acef1f69-8e4f-52cc-dca5-3ada9446e0ee@bellis.me.uk> <CABrJZ5HmCoSsGe2L-JkAsPywhcxyyVkvMmXCvQyJMjWHnMeT_w@mail.gmail.com> <alpine.DEB.2.20.1903261521290.13313@grey.csi.cam.ac.uk> <104ec4ea-296f-1657-5633-f6c1f2684274@pletterpet.nl> <alpine.DEB.2.20.1903261540330.13313@grey.csi.cam.ac.uk> <ec8e6848-c962-56b4-50d5-a7bd4b6d48e6@nic.cz> <CABrJZ5H=Ltora2m6_Gyk=O6+UqT-F704hvoKt5=U-TY7fx8JqA@mail.gmail.com> <CAH1iCioQh_dN=cY42p=Y+kPijEiHHt-oGrwpS=8GAyjy+=xUcg@mail.gmail.com>
In-Reply-To: <CAH1iCioQh_dN=cY42p=Y+kPijEiHHt-oGrwpS=8GAyjy+=xUcg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org;
x-originating-ip: [2001:67c:1232:144:a44c:1730:6db:a3bd]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1b68a65c-aeee-4a1d-0c09-08d6b23d471b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN8PR06MB6210;
x-ms-traffictypediagnostic: BN8PR06MB6210:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BN8PR06MB6210BC3EA0BF43F407E7C1C6B75F0@BN8PR06MB6210.namprd06.prod.outlook.com>
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(396003)(39850400004)(136003)(199004)(189003)(60444003)(305945005)(229853002)(8936002)(6486002)(6436002)(105586002)(68736007)(76176011)(2906002)(7736002)(6506007)(102836004)(106356001)(53546011)(186003)(966005)(11346002)(316002)(81166006)(478600001)(33656002)(6116002)(81156014)(36756003)(6512007)(66574012)(6306002)(25786009)(97736004)(14454004)(4326008)(6916009)(53936002)(82746002)(93886005)(446003)(14444005)(86362001)(99286004)(476003)(256004)(46003)(54906003)(71190400001)(71200400001)(8676002)(2616005)(83716004)(486006)(5660300002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR06MB6210; H:BN8PR06MB5570.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: rvHaOByDJhFhkEIxH57+XEaBl2ooFCCBtUzIYK+U3b8sAn3O4ofdPb/qr1ZvBCA0vbhI4bih/zPixKohwuIsxuJ3BmmLlWlj+Ep5vS8v1PtM907WREfeYojQVZoh31A57w1L7oUxDUr3kEeJZTeP5M6e92hZc/yA2QeQwUwxr2t78FltcYqwif9Iw7vNTV51QzEzTu5lEcyMoN03ZRcP8wRizG3ldQ5XY/fapuLtPW0H+bou5qTS7Pth7HW2glz4jGjgsTkdVAApKXttPcPhc/zH2gk5l7db3m+vBYkxtdzhIHbBXWSE3lyU7H/T4/mb1ApY8zu9Vmp4uGpSIi8WBysJ3n46iEpxGNdoHOb2vfgpXwEmuhpxN9UuUtskvf756QJ4oV5x3vO+VzWxAMyi+DrKX25RNFumwMKtjKmBDVg=
Content-Type: text/plain; charset="utf-8"
Content-ID: <AF4EC9746818B34297BA387BBF497D54@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b68a65c-aeee-4a1d-0c09-08d6b23d471b
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 22:49:17.3786 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR06MB6210
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/K4g-St3H1QUs3DpkQa060sMlUc0>
Subject: Re: [DNSOP] Minimum viable ANAME
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, 26 Mar 2019 22:49:23 -0000

> On Mar 26, 2019, at 7:23 PM, Brian Dickson <brian.peter.dickson@gmail.com>; wrote:
> 
> We need to start with the base requirements, which is, "I want an apex RR that allows HTTP browser indirection just as if there was a CNAME there”.

Yes, THIS. 

In response to the discussion last November, I put together this draft outlining the views of one publisher of a set of websites (me):

https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-01

For reasons outlined in that draft, I want to use a CDN in front of my sites, but I also want to retain control of operating my own DNS. (I.e. I don’t want to have the CDN also do the DNS hosting for me, too.).

To use a CDN while retaining DNS control, most CDNs require you to set up a CNAME pointing to some URL they give you.  When a person then visits that URL, the CDN does its own magic inside its own DNS services to provide the visitor with the A or AAAA record of the edge server closest to the visitor.

This all works perfectly fine if you use a subdomain such as “www.”. You just use a CNAME record and all is fine.

But if you want to drop the “www.” and just use the domain name (example.com), then we don’t have any standardized way to do a CNAME-like function at the apex of the zone. 

Because this is a common business requirement, most DNS hosting providers / operators provide some proprietary method of doing this kind of redirection. Either that or a company has to create their own redirection server (something we did). Either way, you are locked into a proprietary system with issues I outlined in that draft.

As Tim Wicinski mentioned in his review of documents today in DNSOP, this is not a simple problem to solve and there are some fundamental (and passionate) disagreements about the way forward. 

Tim’s suggestion of an interim (presumably virtual?) to focus specifically on this issue seems to make sense to me.

As I stated in the draft, I don’t personally have an opinion (yet, anyway) about solutions. I just want something that works and can be rapidly deployed and used…. so that I can be using a standard RR type instead of proprietary solutions.

That’s it,
Dan  (who just last month deployed a new website and immediately had people asking him when it would work without the “www.” in front of it… so we had to rapidly go and get that set up)