IETF Logo Mail Archive

Re: [DNSOP] Minimum viable ANAME

Mark Andrews <marka@isc.org> Tue, 06 November 2018 13:45 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 E8049130ECA for <dnsop@ietfa.amsl.com>; Tue, 6 Nov 2018 05:45:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 bBaeQI5_zwp7 for <dnsop@ietfa.amsl.com>; Tue, 6 Nov 2018 05:45:12 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 174F1130EF1 for <dnsop@ietf.org>; Tue, 6 Nov 2018 05:45:12 -0800 (PST)
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 CB79D3ABED3; Tue, 6 Nov 2018 13:45:11 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 85A22160099; Tue, 6 Nov 2018 13:45:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 77484160098; Tue, 6 Nov 2018 13:45:08 +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 gs6uqXHE6Ugb; Tue, 6 Nov 2018 13:45:08 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id BCA28160050; Tue, 6 Nov 2018 13:45:07 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <cd7bb7d7-dfd4-d8f2-7f0c-ccb2a64a7a84@pletterpet.nl>
Date: Wed, 07 Nov 2018 00:45:05 +1100
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FAF02429-62DD-4177-8BE8-705BA904AA5B@isc.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> <683ea769-094a-4f06-5a43-d5cb557f285a@pletterpet.nl> <75d28a7a-826c-6ae4-8df0-7813035d04a0@bellis.me.uk> <85b54d67-5f58-2cdc-9080-e7bcf86c2995@pletterpet.nl> <a3869874-e16e-12cb-a385-f8b11bee4f69@bellis.me.uk> <cd7bb7d7-dfd4-d8f2-7f0c-ccb2a64a7a84@pletterpet.nl>
To: Matthijs Mekking <matthijs@pletterpet.nl>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NOTUHJ0M5MfGkitWIr66DjBU7Zk>
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, 06 Nov 2018 13:45:17 -0000


> On 6 Nov 2018, at 11:38 pm, Matthijs Mekking <matthijs@pletterpet.nl> wrote:
> 
> 
> 
> On 06-11-18 12:39, Ray Bellis wrote:
>> On 06/11/2018 17:58, Matthijs Mekking wrote:
>>> That's the crux: A solution that depends on upgrading the resolvers is considered not a (fast enough) deployable solution.
>> The HTTP record does not depend on resolvers being upgraded.   If the browser vendors implement the client side, it's not required.
> 
> But DNS providers like to solve the CNAME-at-the-apex problem within the DNS protocol.
> 
>> Once they do fully implement it by serving the A and AAAA records from cache, then it'll be fast, too.
>>> That's why I like ANAME: It allows you to do CNAME-at-the-APEX processing without requiring resolvers to be updated, however resolvers can implement ANAME to optimize the behavior.
>>> 
>>> Also the ANAME in its current form does not require (but also does not prevent) the resolution to take place inside the name server, it can be a simple script that is part of your zone provisioning.
>> I think Tony Finch was suggesting that you could also do that with "HTTP".
> 
> Okay, I missed that. If HTTP can do that too, than the approach is very similar to ANAME except for the name. Why have both then? Also the name HTTP suggests the record is only applicable to the web.

Because being able to have different services on different hosts / providers is a good thing.
Your SIP service is handled on one machine.  You mail on a different machine.  HTTP on a third and ftp on a forth.  I don’t know what new services are going to be dreamed up.  I do know that some of them are not going to wanted to be on the same machine that is serving HTTP, or SMTP, or SUBMISSION or …

HTTP is actually the odd man out here.  Lots of other protocols have taken up SRV or used other mechanisms to be able to direct traffic to particular servers.

> Matthijs
> 
> 
>> Ray
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
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