Re: [DNSOP] Fundamental ANAME problems

Bob Harold <rharolde@umich.edu> Fri, 09 November 2018 17:41 UTC

Return-Path: <rharolde@umich.edu>
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 D254612D4EE for <dnsop@ietfa.amsl.com>; Fri, 9 Nov 2018 09:41:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.441
X-Spam-Level:
X-Spam-Status: No, score=-0.441 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, TVD_PH_BODY_META=1.559] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 qZnLbsjAX-ZC for <dnsop@ietfa.amsl.com>; Fri, 9 Nov 2018 09:41:32 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 34BA5128766 for <dnsop@ietf.org>; Fri, 9 Nov 2018 09:41:32 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id v15-v6so2266532ljh.13 for <dnsop@ietf.org>; Fri, 09 Nov 2018 09:41:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Az+LQaDc45dVJfgKEtDe+NgaRAzvOlGDdc2LWyxdHA4=; b=lfcYHiuS9KlZuF7aVh3rNqAYUF6tBXtl08XzL3p7vpF8KVb3t23DfF4hfPx1khJoZz mwTEV9wuwc8L/BT/2WOh1t4VNftIJaWXCt6vZC49WDuVJ8Lcd/Fz7hfH6inIwrdhjKN3 DvupWS2WyW3BwJ1jwm3Gx/urF1x4gwiSsz8pC0SxfvmJ3OngqW+4irFydfx8/l9TGtxm 4sujBs2xbQI0lPg7uOUky5H9c+83/s4EJD17qkZyRpTE7Kxam5LDv0//hI1W38km/nu6 m7tZ8dPG0xPsZqISW3vZpvg3upD5x9QQmSzQPGtbXe5QUbVYxOdfsHBjh+4Ee7DJJ/44 31mg==
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=Az+LQaDc45dVJfgKEtDe+NgaRAzvOlGDdc2LWyxdHA4=; b=QyPml0P/2cnZa8FsJE3KjJnffBhfewZOD6ga5asSfFptvj4gRf8NRnCCwT/XncM6yR JJKVB1i6/QEMY4eurUcN/WS2b+hLx4CvMl8EoRMMqrY30Dc/6jVVw1Vbx0P60Lb0Qfmv K/Nd77oHVz4ZAd+EWXyEhM+j3QBTy6kET5vH/KL3N7DuC28UJrXn+k6dqYzbdaKyKfWG r1FNEkHigwiXZ/xp036r1/oukk8d/XmcM9bNrF/JQejPBbvo+9Hu8trNY3+9y493G4vW 3+ipeS975Rp8n+ozcLqAW7+m1kXft3c0wfzq53HbKCQ9aoST58RaJ8hVpkgKiDajGF5O bk5Q==
X-Gm-Message-State: AGRZ1gLiBjgLtfwkC1UPQJOZM6oNq2zHHEdpFaxK4VmiScmSjnlvrAFg BoVW8no8n5QXml9Ls9G63PsshLg+zasjKbFUiC9gNw==
X-Google-Smtp-Source: AJdET5dNTR/suUx3cNESd+CZuZeEUa08X1VnvauFIPigm8Qa4owHCOt+vD3MK0gVBCRCqdgDXoHtE1mzJJbow0yIy6A=
X-Received: by 2002:a2e:4a19:: with SMTP id x25-v6mr6062511lja.19.1541785290168; Fri, 09 Nov 2018 09:41:30 -0800 (PST)
MIME-Version: 1.0
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> <alpine.DEB.2.20.1811091533160.3596@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.20.1811091533160.3596@grey.csi.cam.ac.uk>
From: Bob Harold <rharolde@umich.edu>
Date: Fri, 9 Nov 2018 12:41:17 -0500
Message-ID: <CA+nkc8AYgghvjMzDVpbf9i1+Fc8A+QAz+LSzpFV2NOCA5ZUFeA@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: richard.j.gibson@oracle.com, IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008a758a057a3edc09"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/t1rc0b3bZDJ8SIrV66D8XojQ7nk>
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 17:41:35 -0000

On Fri, Nov 9, 2018 at 11:39 AM Tony Finch <dot@dotat.at>; wrote:

> 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.
>

I think we have different viewpoints here:
- ANAME replaces existing CDN tricks, and the A/AAAA records are always
dynamically generated.  If ANAME leads nowhere, then there is no answer.
Or:
- ANAME is a new feature, which can be used instead the standard A/AAAA
records by the few server where ANAME is implemented.
Updates to the A/AAAA records can be done at the source, the same as any
normal zone update.  No special processing required on the authoritative
servers.  Only the recursive servers use ANAME if they support that new
feature.  If ANAME leads nowhere, then ignore the new broken feature and
return the standard A/AAAA records.  This option could be implementation
dependent.  (This is the view I prefer, at least until ANAME becomes
widespread.)


> > 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.
>

I am inclined to use the TTL of the sibling A/AAAA records and avoid the
work and concerns of guessing the right ttl.  That gives the zone owner the
control, rather than the owner of the ANAME target.  (I am typically a zone
owner, so I prefer to have control.  Others may differ.)


> > 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.
>

If I view A/AAAA as standard, and ANAME as optional (shiny new feature),
then I prefer the A/AAAA if ANAME fails.  CNAME is standard, which is much
different than ANAME in this viewpoint.


> > 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.
>

I agree that needs more thought, but I hope ANAME can cover future address
types.


> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at/
>
>
-- 
Bob Harold