[DNSOP] Minimum viable ANAME

Tony Finch <dot@dotat.at> Wed, 19 September 2018 13:55 UTC

Return-Path: <dot@dotat.at>
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 1675413107E for <dnsop@ietfa.amsl.com>; Wed, 19 Sep 2018 06:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 v82vCv4fXOuf for <dnsop@ietfa.amsl.com>; Wed, 19 Sep 2018 06:55:47 -0700 (PDT)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 0B97513107D for <dnsop@ietf.org>; Wed, 19 Sep 2018 06:55:47 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:55544) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1g2cxF-000YvE-eA (Exim 4.91) for dnsop@ietf.org (return-path <dot@dotat.at>); Wed, 19 Sep 2018 14:55:45 +0100
Date: Wed, 19 Sep 2018 14:55:45 +0100
From: Tony Finch <dot@dotat.at>
To: dnsop@ietf.org
Message-ID: <alpine.DEB.2.20.1809191455190.3596@grey.csi.cam.ac.uk>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LrQ0LRVXkLYhs_phM6O7b2VY8pQ>
Subject: [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 13:55:57 -0000

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.