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

Ólafur Guðmundsson <> Sat, 16 November 2019 15:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2A1A12013A for <>; Sat, 16 Nov 2019 07:15:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Saa2BGh2_Ly5 for <>; Sat, 16 Nov 2019 07:15:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBE6D1200B4 for <>; Sat, 16 Nov 2019 07:15:50 -0800 (PST)
Received: by with SMTP id n23so10610539otr.13 for <>; Sat, 16 Nov 2019 07:15:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v/8APA1qkhA30TWBpHyMRe7dpKKywoX4t9Ym38ZyFjU=; b=abbwGpuhLyPczYtB6ILfPST7LLWFhGDj/eb4nMcuNdZQOFAbskW5wnUIhay0N12Vn4 deIYMPiKspYSvLhE2RrD/yDVdcQi8FLvi/vRyfGenwFY+zhqecJ3c4h8rZc6nU0Jmjiz MnjaV8puaSWe6U8/z+lC2YMlamNDryRDXYHZM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v/8APA1qkhA30TWBpHyMRe7dpKKywoX4t9Ym38ZyFjU=; b=EQptbYSoAcoVjaLwdyFy51RYlbeTpU3w219IHykAF5OtFInLzZUM1pERCbVsm5VpZ+ +l5/PbX6xKjjUNoDm27uy1PL3Yvxmyl329hn3JGdpyKpcWL4FLyCopxs9U5wE24QxMyV ONWhopt56G2N6BoqHtGx8OmA+JUCb836sQXbpCBZqh6H2PHUkpsf3XELPPjHYwtYKYtY x1+jYTd5Vnj0REl/tEn7UwPR1yWcFUkOYvAgD6tIJ6wp30y0QA4AdvclAVm/feQq48tI cdfSN2kKRy49Cq476iGKlwtyAD/6zsBU0APRDMYWZQ71CRb2ptNXflmzUzlldhPcbOEH cSzA==
X-Gm-Message-State: APjAAAXaB8VsZCEayF0W0nkh2Lqy45EGpud0o8Cll2DYqvkJcn2UZFoz ea66T0rK3ihGl7JJqnCJUkMzRLI6XBvHeZLSaTmB0w==
X-Google-Smtp-Source: APXvYqx87v2w2D4A2eToGBzeK8u1VFSkl5JFAiU4ojbM/OH8jyi1UXxztnud5z5dMj1P5WgZMLGUoE5eBnEEEOayVaM=
X-Received: by 2002:a9d:12ae:: with SMTP id g43mr15874835otg.243.1573916923258; Sat, 16 Nov 2019 07:08:43 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <>
Date: Sat, 16 Nov 2019 07:08:32 -0800
Message-ID: <>
To: Shane Kerr <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="0000000000001e1e5e059778179f"
Archived-At: <>
Subject: Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Nov 2019 15:15:54 -0000

On Thu, Nov 14, 2019 at 6:40 AM Shane Kerr <>

> 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.
> CNAME response is small was the main reason as well as making sure things
keep working.

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.)
> I agree not mentioning DNAME in RFC8482 is an omission feel free to file
an errata.

> 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.
> Our experience at Cloudflare with ANY floods is that most/many resolvers
"exact match" caching i.e. if what is explicitly asked for in this case ANY
then is in cache, then forward.
Thus the only way to shut them down is to give them something to cache in
the " ANY" slot.

> 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.
> Just file an errata

> Cheers,
> --
> Shane
> _______________________________________________
> DNSOP mailing list

Ólafur Gudmundsson | Engineering Director