Re: [DNSOP] ANAME in answer or additional section [issue #62]

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 12 June 2019 03:09 UTC

Return-Path: <brian.peter.dickson@gmail.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 9C9E0120041 for <dnsop@ietfa.amsl.com>; Tue, 11 Jun 2019 20:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8h9cc9I4FTIv for <dnsop@ietfa.amsl.com>; Tue, 11 Jun 2019 20:09:32 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 5156212002F for <dnsop@ietf.org>; Tue, 11 Jun 2019 20:09:32 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id n11so14990378qtl.5 for <dnsop@ietf.org>; Tue, 11 Jun 2019 20:09:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=agClvQvzMEhiexbUjYUpTaNe554kW7JuWaThM+6AQM8=; b=Upmmg2SgYX01W2XnElCVULISUisDbZBB7fxLkHrXxK0l9UG0B+vBqthk5lA+A0DYrO eNFQrMKkaeHo2MX4CoZLYv96klVIunE4WKDac0MaotH6F+5YICbNUiPISC+tV9Tv91tR BY156gtGfY596U7w2EZWb5gxuz/R7y9aKmIS/aOwuTUqnlLkG+j3bHAT1WQlTyQe6di1 hruAxm6bc6TH3R3Ef61fsE1ICch+AWQ5UwiMgvMtbzL1MeHE4xCiQ1d3Pwa72yMgH2hn s1BznbDmBxpP9+KWiD7+L/UDMaAFw1zqAGoeEDTpq9k29KFGcFwNu2jnNboYjZ2vDQrl EU5Q==
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=agClvQvzMEhiexbUjYUpTaNe554kW7JuWaThM+6AQM8=; b=p5tlRHrpUKfcx0MMlliA2UrrMVSv2BmYeFOQEO3NhO9ZvNSEpmkls3Y3+UDozF6nso zvmEM2IG3pXZX/+byR9BGkpV0jOYcpOc8ySSI74hFTxcqz55c2n9hcdFvA4v+OB4G2lv gtEByy/2n+F3u/m2JtpIjx/GBKrSGCVPyLnRraQ7rO4GrrCxRfNT4D5lMHHlvLTaguy1 KEAwcveC87ZeXMSeQYwQ19nLqf+eS6qmw0N9b3RF4rluhO2bJGTYksP1AXqaJ5DhNDC5 3nKpb8Vf/YLYDxX7iqW1wZxHuuYNY7lk4sdKFZhMmVIpvnL8eDSBYPMmkOWi//G83TQq H9ng==
X-Gm-Message-State: APjAAAW2BGl0Aq1ORkPsly2Hn11jd7Ctu5MTWo3mSbGdOB843KlV815Q FEIfmkDhGNRF2GXBmVNogd0EI3qVaPoIfRfRX4A=
X-Google-Smtp-Source: APXvYqww4//T3mOY02C1UDLE6pRwyA6c/1o4InGmslWLUAIbZyja7Hdt0SsDDkk2tWJmQlMpEMBMOyJur1/PQK8unNA=
X-Received: by 2002:ac8:5485:: with SMTP id h5mr65721037qtq.253.1560308971410; Tue, 11 Jun 2019 20:09:31 -0700 (PDT)
MIME-Version: 1.0
References: <3b136e34-7ec0-e144-2c2a-0885185ec2b1@pletterpet.nl> <20190612000459.GA60387@isc.org> <CAJhMdTP-iDbbgnCDV7WRhbh495KvhOW3cGS+0tu74VAoYfU=gg@mail.gmail.com>
In-Reply-To: <CAJhMdTP-iDbbgnCDV7WRhbh495KvhOW3cGS+0tu74VAoYfU=gg@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 11 Jun 2019 20:09:19 -0700
Message-ID: <CAH1iCiqE70T3fWVcCrSvA86=qJKoWwuRGFRzKnQyediMrm404A@mail.gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Cc: Evan Hunt <each@isc.org>, Matthijs Mekking <matthijs@pletterpet.nl>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fb184c058b17bdb1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1lqOnsxGpomdrWxGzD27OfEfeW8>
Subject: Re: [DNSOP] ANAME in answer or additional section [issue #62]
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, 12 Jun 2019 03:09:35 -0000

On Tue, Jun 11, 2019 at 6:35 PM Joe Abley <jabley@hopcount.ca> wrote:

> On Jun 11, 2019, at 20:04, Evan Hunt <each@isc.org> wrote:
>
> > MHO, the ANAME is the real answer we're sending; the A and AAAA records
> > are just friendly hand-holding for legacy servers.  It doesn't make sense
> > to me to demote the real answer into the additional section, any more
> than
> > it would have to move DNAME there. The protocol specificaions are clear
> on
> > this point - the more so considering we've already deployed DNAME - and
> my
> > sympathies for an implementation that got it wrong would be limited.
>
> I think DNAME provides a useful example. I think emulating DNAME's
> demonstrated success in both being tolerated and interpreted correctly
> is useful.
>

I agree that there is much from DNAME that can be useful to learn from.

I think it helps to articulate what DNAME did, and why it worked (well, and
at all):

DNAME returned both DNAME and synthesized CNAME records, for queries
received below the DNAME "cut" (query longer than the matching label for
the DNAME).
When a recursive queried an authority server, if it got back a DNAME but
did not understand it, it ignored the DNAME but processed the CNAME (as if
only the CNAME existed) (plus any other data like chained CNAMEs or A/AAAA
records)
When a client queried a recursive, there were two possible kinds of
recursive: DNAME-aware, and DNAME-unaware. The same general answers were
received, modulo the presence of the DNAME.
If the client received, and understood, DNAME, it was effectively the same
as if no CNAMEs had ever been sent or cached. If the client did not
understand DNAME, then it would ignore any DNAME, and use the CNAME -- at
that point, the question of whether the resolver spoke DNAME was more or
less moot.

The elegance of this was due to the fact that a synthesized CNAME was
compatible with the namespace structure which might include a DNAME, as
well as additional CNAMEs and/or DNAMEs.

All of this is unfortunate, because of the fact that there is no genuinely
backward compatible record similar to ANAME that can be used, without a
very strong likelihood of breaking things.
>From authority to recursive: You can't return an ANAME and a CNAME (as a
backward-compatible rewrite signal that corresponds to the ANAME), since
the CNAME will effectively obscure other RRTYPEs that might coexist (e.g.
at the zone apex).
>From recursive to client: An ANAME-aware resolver can maybe return a
fully-resolved A/AAAA record, along with an ANAME (optionally with
additional ANAME/CNAME/DNAME records chained) -- but I think testing this
would strongly be advised.

So, I suspect having the ANAME in the Answer section is worth experimenting
(and the history of DNAME suggests it would not break badly).

The real problem here, is the "other" record for backward compatibility
isn't a rewrite-type (such as CNAME or DNAME), but is a "promoted" A/AAAA
record of potentially limited utility and questionable provenance (due to
geo-ip stuff, TTL stuff, and RRSIG problems).

Brian