Re: [DNSOP] Minimum viable ANAME

神明達哉 <jinmei@wide.ad.jp> Thu, 20 September 2018 18:09 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 BAA3D130DD7 for <dnsop@ietfa.amsl.com>; Thu, 20 Sep 2018 11:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.524
X-Spam-Level:
X-Spam-Status: No, score=-0.524 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] 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 DsluQk5aEKuK for <dnsop@ietfa.amsl.com>; Thu, 20 Sep 2018 11:09:04 -0700 (PDT)
Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (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 608A6130E3E for <dnsop@ietf.org>; Thu, 20 Sep 2018 11:09:02 -0700 (PDT)
Received: by mail-lj1-f172.google.com with SMTP id p10-v6so9267699ljg.2 for <dnsop@ietf.org>; Thu, 20 Sep 2018 11:09: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=T8q2Zp/ASW+0jfRjWaUSFa6txuRT4YrGO7x1L/bIWIA=; b=BYxW17E7MEwvFI4HOy5F3XNkwjl0hMaEzlYKkLYq0Q4Rfp67UAqaKkn1B4GwnZakLe btWfhI5vfRllpGl1AlDFtA+m649HhGrs3oW+nKHQ72f9vNwvkZaqQYWuwrexc6SWBLe8 8xkn2rILr3o3bTv5xOEKreNDdH4KLij4/xRLfiuFh2JwsdNqRarTjX19oBnpMDBkw6Q/ JDs400qGTvDhfgt1fYY6DM27EPqkpoyc67MkED+/VA0u8/6QEh0K9FhkmDZMMDI7Dxo7 8b4qeQ8xhAHI3rImokRLAFza1dZIJTNnGYE3yOyTmrajjdI8QDvB8jLQgmfNcDquS4YD nTYg==
X-Gm-Message-State: APzg51CleUbC0HkuqGRiaoZB4MsXwUG3fbMiAqAx1mYgqLS61nlMLFQj du8AYMjemmY61gk6ghuTsXlbwZwKK+AFzyoyd8lrgmwf
X-Google-Smtp-Source: ANB0VdaJFQe4f6ST49L+RVnd/0LIhonL4p4DYRdlG7ccYMaM5tSbJmpbuWTIA8tCbwfQTFrlWipyWkf8XfsPUOsT0IM=
X-Received: by 2002:a2e:650e:: with SMTP id z14-v6mr25555637ljb.62.1537466940267; Thu, 20 Sep 2018 11:09:00 -0700 (PDT)
MIME-Version: 1.0
References: <alpine.DEB.2.20.1809191455190.3596@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.20.1809191455190.3596@grey.csi.cam.ac.uk>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Thu, 20 Sep 2018 11:08:48 -0700
Message-ID: <CAJE_bqc_ZK1k-G1aZoS_aRtKfYX-=7nt8QHy7Gq-8BJdq_=QFw@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d4222b0576516adf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DOVWyAvU6nH58iER_fYCckiOZ-8>
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: Thu, 20 Sep 2018 18:09:06 -0000

At Wed, 19 Sep 2018 14:55:45 +0100,
Tony Finch <dot@dotat.at>; wrote:

> I think there's still a need to standardize ANAME, to provide at least
> some level of zone file portability between the various existing
> proprietary versions of this feature. And to provide something usable
> by zone publisters on a much shorter timescale than a nsa SRV-alike.
>
> So here's a sketch of a reduced ANAME:
>
> Primary servers / zone provisioning
> -----------------------------------
>
> For each ANAME record, poll the target address records periodically
> (according to the relevant TTLs). When the target addresses don't
> match the owner's addresses, UPDATE the zone so they match.

I'm not sure how we can expect this model to deploy in practice.  With
this model, the zone admin will need to develop an additional script
or something integrated into whatever the provisioning framework they
are using.  Is that the assumption?

Then I suspect none of existing users of proprietary and
non-standard-compliant "ALIAS" will switch to it simply because it's
standard compliant.  And that will be also the case for those who now
want to start "aliasing at a zone apex".

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.  Perhaps that's
the intended deployment plan?  If so, I see some possibility there,
but I have to say I'm pessimistic about its reality.

--
JINMEI, Tatuya