[DNSOP] How to respond to ANY and RRSIG queries when you don't want to

Tony Finch <dot@dotat.at> Mon, 16 March 2015 11:25 UTC

Return-Path: <fanf2@hermes.cam.ac.uk>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 87CA91A0122 for <dnsop@ietfa.amsl.com>; Mon, 16 Mar 2015 04:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.911
X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6W9TjEmr2i8F for <dnsop@ietfa.amsl.com>; Mon, 16 Mar 2015 04:25:35 -0700 (PDT)
Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk []) (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 AE28B1A00BE for <dnsop@ietf.org>; Mon, 16 Mar 2015 04:25:35 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([]:56929) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk []:25) with esmtpa (EXTERNAL:fanf2) id 1YXT9J-0006b0-FY (Exim 4.82_3-c0e5623) for dnsop@ietf.org (return-path <fanf2@hermes.cam.ac.uk>); Mon, 16 Mar 2015 11:25:33 +0000
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1YXT9J-0006zB-PI (Exim 4.72) for dnsop@ietf.org (return-path <fanf2@hermes.cam.ac.uk>); Mon, 16 Mar 2015 11:25:33 +0000
Date: Mon, 16 Mar 2015 11:25:33 +0000
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: dnsop@ietf.org
Message-ID: <alpine.LSU.2.00.1503161122260.23307@hermes-1.csi.cam.ac.uk>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/9EEvRJLYzfzIrhqkIYhgLlA6oto>
Subject: [DNSOP] How to respond to ANY and RRSIG queries when you don't want to
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 16 Mar 2015 11:25:40 -0000

This note is a consolidation of several messages to the IETF DNSOP
working group last week.

The principal motivation for not answering ANY queries is to allow for
simplified implementations which do not need to enumerate all the data
at a particular QNAME. This note also covers RRSIG queries, because
they need essentially the same enumeration mechanism as ANY queries;
the difference between an ANY and an RRSIG response is the non-RRSIG
records are omitted from the latter.

The aim of this suggestion is to provide answers that will satisfy the
client without harming interoperability, although you do lose a
debugging tool. Error responses (such as NOTIMP or REFUSED) make
clients retry at other servers, which is undesirable. NOERROR / NODATA
responses are cached in a way that causes queries for other RRtypes to
get erroneous NODATA responses.

1. When the server is authoritative for the QNAME's zone.

Respond as if the QTYPE had been CNAME.

That is, provide a CNAME answer if the QNAME is a CNAME, or provide a
NOERROR / NODATA response if other types are present at the QNAME.
This applies to wildcard matching too.

If the response would be NOERROR / NODATA and the zone is not signed,
synthesize a NULL RR and use that as the answer.

If the QTYPE was RRSIG, drop non-RRSIG records from the answer.

2. When the server is answering from cache.

If there is a cache entry for the QNAME, respond as in point 1.

Otherwise, if RD=0, respond in the standard manner (with the best
available referral).

Otherwise, if RD=1, make a query upstream with QTYPE=CNAME, then
respond as in point 1.


This is simpler than I expected it to be. I started doing a case
analysis -- zone is unsigned or signed with NSEC or NSEC3, QNAME is a
CNAME or isn't, recursion or not, etc. -- but the way to handle each
case turned out to be very similar. The key insight came from saying,
respond with a CNAME answer if there is one, or respond with NOERROR /
NODATA - which is exactly the response you would give to a CNAME
query. This leads to the suggestion of turning ANY queries into CNAME
queries when recursing.

f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Northwest Southeast Iceland: Southwesterly 5 to 7, occasionally gale 8,
becoming variable, mainly northeasterly 4. Very rough or high, becoming rough
later. Occasional rain. Good, occasionally poor.