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
- [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Anthony Eden
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Paul Vixie
- Re: [DNSOP] Minimum viable ANAME Paul Wouters
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME John Levine
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Paul Wouters
- Re: [DNSOP] Minimum viable ANAME Mukund Sivaraman
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME 神明達哉
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Dan York
- Re: [DNSOP] Minimum viable ANAME Matthew Pounsett
- Re: [DNSOP] Minimum viable ANAME 神明達哉
- Re: [DNSOP] Minimum viable ANAME JW
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Havard Eidnes
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Havard Eidnes
- Re: [DNSOP] Minimum viable ANAME Tim Wicinski
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Havard Eidnes
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Erik Nygren
- Re: [DNSOP] Minimum viable ANAME Paul Vixie
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Paul Vixie
- Re: [DNSOP] Minimum viable ANAME Mark Andrews
- Re: [DNSOP] Minimum viable ANAME Paul Vixie
- Re: [DNSOP] Minimum viable ANAME Mark Andrews
- Re: [DNSOP] Minimum viable ANAME Brian Dickson
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Tim Wicinski
- Re: [DNSOP] Minimum viable ANAME Paul Vixie
- Re: [DNSOP] Minimum viable ANAME Ben Schwartz
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Tim Wicinski
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Ray Bellis
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Mark Andrews
- Re: [DNSOP] Minimum viable ANAME Mark Andrews
- Re: [DNSOP] Minimum viable ANAME Ben Schwartz
- Re: [DNSOP] Minimum viable ANAME Mark Andrews
- [DNSOP] ALTSRV Masataka Ohta
- Re: [DNSOP] Minimum viable ANAME Ben Schwartz
- Re: [DNSOP] Minimum viable ANAME Mark Andrews
- Re: [DNSOP] Minimum viable ANAME Olli Vanhoja
- Re: [DNSOP] Minimum viable ANAME tjw ietf
- Re: [DNSOP] Minimum viable ANAME Dan York
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Brian Dickson
- Re: [DNSOP] Minimum viable ANAME Matthijs Mekking
- Re: [DNSOP] Minimum viable ANAME Vladimír Čunát
- Re: [DNSOP] Minimum viable ANAME Olli Vanhoja
- Re: [DNSOP] Minimum viable ANAME Vladimír Čunát
- Re: [DNSOP] Minimum viable ANAME Brian Dickson
- Re: [DNSOP] Minimum viable ANAME Olli Vanhoja
- Re: [DNSOP] Minimum viable ANAME Brian Dickson
- Re: [DNSOP] Minimum viable ANAME Olli Vanhoja
- Re: [DNSOP] Minimum viable ANAME Tony Finch
- Re: [DNSOP] Minimum viable ANAME Dan York
- Re: [DNSOP] Minimum viable ANAME Benno Overeinder