Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

Mark Andrews <marka@isc.org> Fri, 22 June 2018 22:20 UTC

Return-Path: <marka@isc.org>
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 F1829130F0D for <dnsop@ietfa.amsl.com>; Fri, 22 Jun 2018 15:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 dGK-jxPBcSXw for <dnsop@ietfa.amsl.com>; Fri, 22 Jun 2018 15:20:17 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 D43F4130F0B for <dnsop@ietf.org>; Fri, 22 Jun 2018 15:20:17 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id DA3C53AB003; Fri, 22 Jun 2018 22:20:16 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id BA39116006B; Fri, 22 Jun 2018 22:20:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 776EC16006C; Fri, 22 Jun 2018 22:20:16 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6Jo7_t5JQN7X; Fri, 22 Jun 2018 22:20:16 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id E672E16006B; Fri, 22 Jun 2018 22:20:15 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Mark Andrews <marka@isc.org>
X-Mailer: iPhone Mail (15F79)
In-Reply-To: <43D87A94-E356-4B82-BB0B-C40701E981FB@dotat.at>
Date: Sat, 23 Jun 2018 08:20:12 +1000
Cc: Warren Kumari <warren@kumari.net>, dnsop <dnsop@ietf.org>, Ray Bellis <ray@bellis.me.uk>, jabley@automagic.org, muks@mukund.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2BC75AC-3E1D-43E0-AE1E-89D78E11CEB1@isc.org>
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <alpine.DEB.2.11.1806191428250.916@grey.csi.cam.ac.uk> <691FC45D-E5B6-4131-95BF-878520351F3A@gmail.com> <bf0ba568-1a18-f8cf-c1a0-3f547d642a78@bellis.me.uk> <0438207E-A4C2-434D-9507-9D9F54765CFB@puck.nether.net> <alpine.DEB.2.11.1806191649350.916@grey.csi.cam.ac.uk> <9a0d1bae-dc58-99b5-40d1-caa7737dbfb1@bellis.me.uk> <1B7B2BB4-F0AE-4188-B89B-DF032BE7A237@automagic.org> <CAHw9_iKWhRjK6yzSSWVsCBqjdVfTnzVkUh8PMYC5nwQUb_=yvw@mail.gmail.com> <20180622191334.GA15349@jurassic> <CAHw9_iLN0w=k0hZLsOCJXnA58afACuzxgXdYPPEn_HShm6Q4aw@mail.gmail.com> <43D87A94-E356-4B82-BB0B-C40701E981FB@dotat.at>
To: Tony Finch <dot@dotat.at>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DiXB8Zcq7Pnn6sF63jQ0jTjn0Nc>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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, 22 Jun 2018 22:20:21 -0000

We do what we should have done from the very beginning and have a rdata type that combines A and AAAA records.  Master servers automatically generate the type and sign it from the A and AAAA resets.  Address family is determined from the rdata length. 

We have a EDNS option that tells the recursive server to construct this type if not present in the zone or return the A or AAAA records in its place if construction would be detected by DNSSEC.  If this option is set you return the new type in the additional section in preference to A and AAAA records.  This way one is not waiting for all the master servers to be updated. 

We also have a option that says recurse to populate the additional section before returning and set tr if the additional section is too small.  The recursive server would use this option to signal if the additional section is complete or not.

-- 
Mark Andrews

> On 23 Jun 2018, at 06:08, Tony Finch <dot@dotat.at>; wrote:
> 
> The problem with SRV (and MX) is that you can’t tell what an empty additional section means. (By “you” I mean anything in the resolver chain: app, stub, recursor, etc.)
> 
> If the AAAA records are missing, does that mean there aren’t any? Does it mean they were not cached? Does it mean the server chose not to provide them for some other reason?
> 
> If you want to find out, you have to make a follow-up query to get a clear answer, so you have spent two round trips instead of one. And hopefully your recursive server omitted the AAAA because it has an ncache entry so you get a quick answer, but that’s unlikely if the auth server didn’t provide AAAA and the resolver didn’t eagerly go chasing (which they don’t) and you are an early adopter of SRV so no one else filled the ncache for you.
> 
> This can (in theory) be fixed with DNSSEC, but the additional section processing rules have to be changed so that they require the nonexistence proof when records are missing, and of course stubs and apps have to be changed to understand the NSEC(3) records.
> 
> Mail servers generally regard additional sections as too unreliable to be useful, and take the simpler slower approach of making all the queries explicitly. It works for them because they are not especially worried about latency.
> 
> Because of all this I can sympathize with browser authors to some extent; on the other hand, if they had adopted SRV before it was too late, we might have done more to fix these problems in the last 22 years. (eg an EDNS option to disambiguate missing additional records, maybe.)
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop