[DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME

Shane Kerr <shane@time-travellers.org> Thu, 14 November 2019 14:40 UTC

Return-Path: <shane@time-travellers.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 89552120052 for <dnsop@ietfa.amsl.com>; Thu, 14 Nov 2019 06:40:32 -0800 (PST)
X-Quarantine-ID: <g5hfOWbfgBLO>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...T_ADDRESS@@ for details.\n \n Content previ[...]
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 g5hfOWbfgBLO for <dnsop@ietfa.amsl.com>; Thu, 14 Nov 2019 06:40:30 -0800 (PST)
Received: from saturn.zonnestelsel.tk (tunnel317214-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:77a::2]) (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 3014B120025 for <dnsop@ietf.org>; Thu, 14 Nov 2019 06:40:29 -0800 (PST)
Received: from earth.zonnestelsel.tk ([2001:470:78c8:2::9]) by saturn.zonnestelsel.tk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <shane@time-travellers.org>) id 1iVGIL-0003vC-D3 for dnsop@ietf.org; Thu, 14 Nov 2019 14:40:27 +0000
From: Shane Kerr <shane@time-travellers.org>
To: dnsop@ietf.org
Message-ID: <a8e99b8e-101e-7516-8af6-f8c1ffe436b8@time-travellers.org>
Date: Thu, 14 Nov 2019 15:40:25 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score-Int: -28
X-Spam-Bar: --
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/h3lVarMTG390dx199m5kV0HiNUo>
Subject: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME
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: Thu, 14 Nov 2019 14:40:33 -0000

Hello,

We just implemented DNAME support on an authoritative server that 
already implements giving an HINFO response to ANY queries, as described 
in RFC 8482.

RFC 8482 is clear about not allowing the HINFO response if there is a 
CNAME record at the name. While no rationale is given in the RFC, it 
seems clear that this is because a CNAME cannot exist with any other 
record, so replying with HINFO might break things, or at least cause 
confusion.

What is not clear is what to do DNAME subtree responses. (For ANY 
queries that match the name of the DNAME record itself, we apply the 
normal RFC 8482 logic, which seems reasonable.)

DNAME provides synthesized CNAME answers, presumably to help resolvers 
that do not support DNAME. On the one hand, if this is important then 
probably performing the normal DNAME logic and returning these 
synthesized records makes sense. On the other hand, it seems unlikely 
that any resolver actually sends ANY queries to authoritative servers. 
However RFC 8482 seems to disagree with this, since the 
resolver/authoritative interaction is specifically called out:

    Alternative proposals for dealing with ANY queries have been
    discussed.  One approach proposes using a new RCODE to signal that an
    authoritative server did not answer ANY queries in the standard way.
    This approach was found to have an undesirable effect on both
    resolvers and authoritative-only servers; resolvers receiving an
    unknown RCODE would resend the same query to all available
    authoritative servers rather than suppress future ANY queries for the
    same QNAME.

We have chosen to perform CNAME synthesis for ANY queries that match a 
DNAME subtree, based on the logic that if CNAME is special when added by 
hand then it is probably also special when synthesized.

I'm interested in what the DNSOP group thinks the correct behavior is, 
and also if it makes sense to update RFC 8482 to clarify the expected 
behavior for DNAME.

Cheers,

--
Shane