Re: [DNSOP] Minimum viable ANAME

神明達哉 <jinmei@wide.ad.jp> Fri, 21 September 2018 16:53 UTC

Return-Path: <jinmei.tatuya@gmail.com>
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 222C4130EA6 for <dnsop@ietfa.amsl.com>; Fri, 21 Sep 2018 09:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.523
X-Spam-Level:
X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.146, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Pee90Q3pmaeP for <dnsop@ietfa.amsl.com>; Fri, 21 Sep 2018 09:53:06 -0700 (PDT)
Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4212130ED4 for <dnsop@ietf.org>; Fri, 21 Sep 2018 09:53:02 -0700 (PDT)
Received: by mail-lj1-f169.google.com with SMTP id p6-v6so12267685ljc.5 for <dnsop@ietf.org>; Fri, 21 Sep 2018 09:53:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=07Pwa/8mynBIn9yk/5XYuFrGFhxAcZmFvpYRv4w9e6M=; b=PJOVCi+tEUSt9Tq3rdZRPu5vL4m99XfQkQwmLquxjkIsTplaj5+wCn2ptyNNisuI9x OwqEQDEekB5KdYHEHJTc8AUWBTyGVKVlUoCNgphLrLqaVlTPnk8sWWd1biVf0Hmyh4q6 xN13I5FPsxzLQaTqZPkrnz2lXZHC1EWn5u4Ypf4apovC5Nl/o8fle18jIdQF9TDHtVsZ YJUjnZUz3WkhjmdlAn0lt4Nytg2m5PN/0OnfoV4WrKqiQbQ8oDa51iT6bXQMIQZjGJfF aK5geBkWsuB4AKQrjs+bsSgDITfiHKrW2XtFvMUAwGIZDXhuneAxN5bPoJuIJe/moHVB 93pQ==
X-Gm-Message-State: ABuFfogxhJS6zULnm8IDfUSVyy2FuSdiWf9orEsZ2G1+G/B65S572w5u mC2T9ql+EcWK8Pzd50ueyCpjlRLct8vZ5UdPQzsBMiC9
X-Google-Smtp-Source: ACcGV63Sdc7oqjftY+6AYa9lyz6nQkkH1hC4OGYZWLQdsNsS/J2S4qwJFmz8uLnOfI37Y1yIlz3jXeVsVXQzSm0wsfk=
X-Received: by 2002:a2e:c49:: with SMTP id o9-v6mr2470861ljd.16.1537548780755; Fri, 21 Sep 2018 09:53:00 -0700 (PDT)
MIME-Version: 1.0
References: <alpine.DEB.2.20.1809191455190.3596@grey.csi.cam.ac.uk> <CAJE_bqc_ZK1k-G1aZoS_aRtKfYX-=7nt8QHy7Gq-8BJdq_=QFw@mail.gmail.com> <alpine.DEB.2.20.1809211147440.3596@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.20.1809211147440.3596@grey.csi.cam.ac.uk>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Fri, 21 Sep 2018 09:52:48 -0700
Message-ID: <CAJE_bqfNFbwsx3RLzY2rgPdZu926Onzp5SLEg+s1a5UHWBJmUg@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e6ded10576647829"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wLbrnHVwDPHwoZP9_2UdQm93M4k>
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: Fri, 21 Sep 2018 16:53:15 -0000

At Fri, 21 Sep 2018 12:03:13 +0100,
Tony Finch <dot@dotat.at>; wrote:

> > Perhaps primary server implementations may eventually have some level
> > of support that makes this provisioning much less painful (in a way
> > other than performing on-demand resolution).  If and when many popular
> > implementations do it in a convenient way (at least as convenient as
> > the proprietary alternatives), we may hope the new model with ANAME
> > optimization will start to deploy, eventually with wider deployment of
> > the optimization part as more resolvers support it.
>
> It doesn't have to be sequential like that: the additional section
> processing on auth and rec servers, and resolver ANAME optimization won't
> cause any interop problems, so they can be deployed whenever the code is
> ready and they'll have a useful effect when they encounter an ANAME
> record.

It's true that "they (= additional section processing) can be deployed
whenever the code is ready".  But if I were a primary side admin who
wants to use an ALIAS-like feature, that wouldn't mean much
unless/until
A. the provisioning support in the primary server implementation is
   really convenient in terms of my operational costs, or
B. a significantly large number of resolvers support the additional
   section processing for ANAME

In my understanding of the discussion we all agree that it will take a
very long time until we have B.  So, in the end, the deployability
seems to depend on how soon we can have situation A and how convenient
the implementations are.  It may actually come quite soon and may
really become very popular.  I don't deny that possibility; I'm just
not personally so optimistic about it.

--
JINMEI, Tatuya