[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
- [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME Shane Kerr
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … John Levine
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Viktor Dukhovni
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Tony Finch
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Tony Finch
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Viktor Dukhovni
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … John Levine
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Ólafur Guðmundsson
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Andrew Sullivan
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Andrew Sullivan
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Viktor Dukhovni
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Mark Andrews
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Viktor Dukhovni
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Paul Vixie
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Viktor Dukhovni
- Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and … Paul Vixie