Re: [DNSOP] Fundamental ANAME problems

Tony Finch <dot@dotat.at> Fri, 09 November 2018 16:39 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 CF7CF129BBF for <dnsop@ietfa.amsl.com>; Fri, 9 Nov 2018 08:39:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.641
X-Spam-Level:
X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, TVD_PH_BODY_META=1.559] 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 1MJykt1lL_RI for <dnsop@ietfa.amsl.com>; Fri, 9 Nov 2018 08:39:35 -0800 (PST)
Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 C92B31286D9 for <dnsop@ietf.org>; Fri, 9 Nov 2018 08:39:35 -0800 (PST)
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]:55448) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gL9oj-000DhV-Kg (Exim 4.91) (return-path <dot@dotat.at>); Fri, 09 Nov 2018 16:39:33 +0000
Date: Fri, 9 Nov 2018 16:39:33 +0000
From: Tony Finch <dot@dotat.at>
To: Richard Gibson <richard.j.gibson@oracle.com>
cc: IETF DNSOP WG <dnsop@ietf.org>
In-Reply-To: <f78934dc-bb05-a9b8-da81-6e610346c827@oracle.com>
Message-ID: <alpine.DEB.2.20.1811091533160.3596@grey.csi.cam.ac.uk>
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com> <CA+nkc8C6yVT62cW5QP-ec2ZT7FY_n48Ecr=CLeE6FS_1duBO8g@mail.gmail.com> <bccfabab-6fab-867e-7c12-8ced9f0d11b6@oracle.com> <f78934dc-bb05-a9b8-da81-6e610346c827@oracle.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1870870841-1116726980-1541779218=:3596"
Content-ID: <alpine.DEB.2.20.1811091601130.3596@grey.csi.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/r440UJ4f4DdmBN0SXQjwOQYGd34>
Subject: Re: [DNSOP] Fundamental ANAME problems
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: Fri, 09 Nov 2018 16:39:38 -0000

Richard Gibson <richard.j.gibson@oracle.com>; wrote:
>
> First, I am troubled by the requirement that ANAME forces the zone into a
> dynamic zone.

I don't see how it is possible to implement ANAME without some form of
dymamic behaviour, either by UPDATEs on the primary, or on-demand
substitution on the secondaries, or some combination of the two.

> Second, and relatedly, I think the TTLs of replacement records established for
> non-transfer responses are too high. Respecting the TTL of every record in a
> chain that starts with the ANAME requires the TTL of final replacement records
> to be no higher than the minimum TTL encountered over the chain, potentially
> /reduced/ nondeterministically to mitigate query bunching. I would therefore
> add language encouraging resolvers synthesizing those records to engage in
> best-effort determination of original TTLs by (e.g., by directly querying
> authoritative servers and refreshing at 50% remaining), but *requiring* them
> to decrement TTLs of records for which they are not authoritative.

I'm not sure I understand which TTLs you are worried about here. What are
"non-transfer responses"? There's certainly some rewording needed to make
it more clear, but the TTLs returned by resolvers that do sibling address
record substitution are decremented in the usual way, and resolvers make
no attempt to determine the original TTLs.

It isn't possible to require a resolver to query authoritative servers
directly.

> And finally, back on the question of what ANAME sibling address records
> actually represent, I think that NXDOMAIN and NODATA results should be treated
> as errors for the purposes of ANAME sibling replacement. This position can be
> justified on both practical and principled grounds—replacing functional
> records with an empty RRSet is undesirable for DNS users (or at least the
> sample of them that are Oracle+Dyn customers),

Maybe so, but that's what happens with CNAME records.

> and could inappropriately stretch the maximum specified ANAME sibling
> TTL (on the ANAME record itself) to the SOA MINIMUM value (which is
> doubly bad, because it results in extended caching of the /least/
> valuable state).

That's a very good point, thank you.

> Let's please just eliminate all of that by specifying that ANAME
> processing can never replace something with nothing.

So when the target goes away, you would prefer to leave behind zombie
address records, and stretch their TTL indefinitely? If the zone admin is
given only a target hostname (just like a CNAME) they don't have any
alternative addresses to use when the target goes away. So the options are
to copy the target by deleting the addresses, or ignore the target and
leave the addresses to rot.

I'm inclined to say that fallback records should remain a non-standard
feature. The semantics can be that when you see the target go AWOL, delete
the ANAME and its siblings, and replace them with the fallback records
that were specified by some other means. You can apply the same logic to
CNAMEs too, if you want :-)

> P.S. There is a typographical error in Appendix D; "RRGIG" should be "RRSIG".

Thanks.

> P.P.S. I think it has been discussed before, but this document should also
> introduce and use a new "Address RTYPE" registry or subregistry, rather than
> forever constraining ANAME exclusively to A and AAAA.

The -01 draft specified a registry but I dropped that from -02 because I
was not sure if it should include X25, ISDN, NSAP, ATMA, the ILNP types,
the Nimrod types, etc. And now I realise that it needs a lot more thought
about what will happen to interoperability when the registry changes.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at/
a fair, free and open society