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

Matthijs Mekking <matthijs@pletterpet.nl> Wed, 12 June 2019 08:11 UTC

Return-Path: <matthijs@pletterpet.nl>
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 EA3021200D8 for <dnsop@ietfa.amsl.com>; Wed, 12 Jun 2019 01:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 srv95kiY-TfR for <dnsop@ietfa.amsl.com>; Wed, 12 Jun 2019 01:11:50 -0700 (PDT)
Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.24]) (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 8FBE612007A for <dnsop@ietf.org>; Wed, 12 Jun 2019 01:11:50 -0700 (PDT)
Received: from [IPv6:2001:980:4eb1:1:5ca:272c:8848:ebce] ([IPv6:2001:980:4eb1:1:5ca:272c:8848:ebce]) by smtp-cloud7.xs4all.net with ESMTPSA id ayMFhCSu95qKaayMGh6PXD; Wed, 12 Jun 2019 10:11:48 +0200
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
References: <3b136e34-7ec0-e144-2c2a-0885185ec2b1@pletterpet.nl> <20190612000459.GA60387@isc.org> <CAJhMdTP-iDbbgnCDV7WRhbh495KvhOW3cGS+0tu74VAoYfU=gg@mail.gmail.com> <CAH1iCiqE70T3fWVcCrSvA86=qJKoWwuRGFRzKnQyediMrm404A@mail.gmail.com>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <68b5997e-1c24-a366-1165-9874a36169b5@pletterpet.nl>
Date: Wed, 12 Jun 2019 10:11:47 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAH1iCiqE70T3fWVcCrSvA86=qJKoWwuRGFRzKnQyediMrm404A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfIO+hVk5wd0RQqAyLutF/pK6OmbU+ewQKhOSulEAS9HBNTXqkeAj84zYTL6zt3mjl7Sz7gn0tkWIZnn9t8k6SnMyqUw12i7hcKjwUlqz+bPPzYEcWArW JKI1GszFri07qzIbhrzzXje5DSkTLbNhYUJE49kDKz7OD5Oh0jUeXCP1vumriVRCUhBE5hrhpUwyA8iLNZuLWLlUk3axcXrq4YtbQc3zM6YOfOX5cl5uf5Pu Qmjym4wGVnDznbhaPPGLDQfqVQtmfvBwjLoNz4qg8nRDK+qaslZGACQ31fBeNfIF3x3D1PNEV64PtQIlBW+kPg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jdwG1AslE27kKNSefrp1MTdzuAk>
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 08:11:53 -0000

Brian,

Thanks for the detailed background on why DNAME worked. There are a few
things that caught my attention:

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

Following this logic, this suggests that having an ANAME in the answer
section, together with the requested A or AAAA records, the resolver
most likely will ignore the ANAME and use the A/AAAA records.


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

This is fine, because that is not what we want: We would like to add the
ANAME in the answer section with the A/AAAA records (not a CNAME).


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

This motivates me to write down that the ANAME should go in the answer
section for address type queries.


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

I actually see the A/AAAA record as the backward compatibility records:
An ANAME-aware resolver would understand the ANAME and can act upon it,
an ANAME-unaware resolver will use the A/AAAA records that the
authoritative returned.


Best regards,

Matthijs






On 6/12/19 5:09 AM, Brian Dickson wrote:
> 
> 
> On Tue, Jun 11, 2019 at 6:35 PM Joe Abley <jabley@hopcount.ca
> <mailto:jabley@hopcount.ca>> wrote:
> 
>     On Jun 11, 2019, at 20:04, Evan Hunt <each@isc.org
>     <mailto: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
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>