Re: [DNSOP] Minimum viable ANAME

Anthony Eden <anthony.eden@dnsimple.com> Wed, 19 September 2018 14:02 UTC

Return-Path: <anthony.eden@dnsimple.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 3FA86131001 for <dnsop@ietfa.amsl.com>; Wed, 19 Sep 2018 07:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=dnsimple.com
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 nm5h482QzIxX for <dnsop@ietfa.amsl.com>; Wed, 19 Sep 2018 07:02:22 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 BCCCD131008 for <dnsop@ietf.org>; Wed, 19 Sep 2018 07:02:20 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id v90-v6so5959834wrc.0 for <dnsop@ietf.org>; Wed, 19 Sep 2018 07:02:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnsimple.com; s=mail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QK6h/rYRkk2CRUh6rdRmKYm5FtiFThCACA6YrxnMj6s=; b=c6br96GqxouGHpQfj1023Rje++T0QXjIVM1HmyDvRnad0VjA3sARl2fqNe8E7xcDT/ e1NpxSBJ8pCRT3XTkDGYemCbxbvYEzk7+iQGWI104aomjFE0yev+9UEuOKHZPbExM3tl bfWecob1QH3bdGdicuJJJt91o8uE4+L/rc2aU=
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=QK6h/rYRkk2CRUh6rdRmKYm5FtiFThCACA6YrxnMj6s=; b=EjLHENu+bjDjsyvSc+UQddkIdpl89mWNOHSSGExHrFChW1S5v1dPSW+d9m7f6yN501 stgiVxg7Gdd/uc87BjsX0c2HNgjmvcObtzAtU1WMGqVbzrx7ODALr56UWNlaD1ogxhrM t0hZvCkvDNy+iit75IcRdWpXszxEDh6Rhf26b1mSVOn4cytikRfz+dve+dZNJ4xHhHOS RzwHrPjs7PDV+fI9G5btR6j1RF11kLhaYIdcX+gpg79Q9cXvAcJ4XFZz89F5A7Nf8b+A N0gPt9gN4fp0oHzZNI2csQVmpfXgL4Gdp71nTRVjQLWbxsO7A0pozJTP+u9xzhWMfcHG GPig==
X-Gm-Message-State: APzg51DuAP74JEFyAhj2N+tBKxCln42PI2H/7VKnZ+KMpEY8BlCzDks1 45V1mgWR1RD87eZQd92ZQ7eNaeo7nGkGxnUW+AVu+bqDdEk=
X-Google-Smtp-Source: ANB0VdYR6Co5MZpxbc98CH8kHxHqZkXe+cK+w2uWQC7KMpOubF8fmhwutc3qh7q1iLEuOEwECbuNQXHdc9CmbyO1PZ0=
X-Received: by 2002:a5d:4a44:: with SMTP id v4-v6mr28703171wrs.278.1537365739065; Wed, 19 Sep 2018 07:02:19 -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: Anthony Eden <anthony.eden@dnsimple.com>
Date: Wed, 19 Sep 2018 10:02:07 -0400
Message-ID: <CAOZSDgCGx73HhtkuQL8WQAhAxGv57h53c+R9xG=Es2sCejYDhw@mail.gmail.com>
To: dot@dotat.at
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c46be2057639daf5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Rp_SBih9Vj70O0MwEd3Hy6JRvVc>
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: Wed, 19 Sep 2018 14:02:24 -0000

FWIW, there's still always
https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/  (also
available at https://github.com/aeden/alias-rr-type) which can be revived
if there is interest.

Sincerely,
Anthony Eden

On Wed, Sep 19, 2018 at 9:56 AM 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.
>
>
> Authoritative servers / zone transfers
> --------------------------------------
>
> No special new behaviour.
>
>
> Additional section processing
> -----------------------------
>
> This applies to auth and rec servers. In response to an A / AAAA /
> ANAME query, include any sibling A / AAAA / ANAME records, and any
> ANAME target A / AAAA records. When DO=1, include DNSSEC proofs of
> nonexistence for missing RRsets.
>
> As usual for additional section processing, you don't have to include
> records that aren't available, so (for instance) auth servers don't
> have to include out-of-zone data in the response.
>
>
> Recursive servers
> -----------------
>
> When responding to a query with DO=0 or when the ANAME owner's zone is
> unsigned, a recursive server can substitute the target addresses in
> place of the owner's addresses.
>
>
> Rationale
> ---------
>
> The primary server behaviour is an "as if" description: that's what
> it looks like for the purpose of interop with secondary servers and
> zone files.
>
> There doesn't seem to be any point in making secondary servers do
> anything: their view of the target address records will be just as
> wrong or right as the primary server's. Zone publishers that want
> clever auth servers will use some kind of multi-headed CDN distributed
> stunt DNS server, and we aren't going to standardize that.
>
> Putting cleverness in resolvers compensates for the lack of cleverness
> in secondary servers.
>
>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at/
> Hebrides: Cyclonic 5 to 7 becoming west or southwest 7 to severe gale 9.
> Rough
> or very rough becoming very rough or high. Showers. Good, occasionally
> poor.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
DNSimple.com
http://dnsimple.com/
Twitter: @dnsimple