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

Andras Salamon <andras@dns.net> Tue, 17 March 2015 12:29 UTC

Return-Path: <andras@dns.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0641A01A5 for <dnsop@ietfa.amsl.com>; Tue, 17 Mar 2015 05:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level:
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 1NzJWUFZTPGu for <dnsop@ietfa.amsl.com>; Tue, 17 Mar 2015 05:29:35 -0700 (PDT)
Received: from server2.gaon.net (server2.gaon.net [46.4.121.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA631A008A for <dnsop@ietf.org>; Tue, 17 Mar 2015 05:29:35 -0700 (PDT)
Received: from server2.gaon.net (localhost [127.0.0.1]) by server2.gaon.net (8.14.3/8.14.3) with ESMTP id t2HCTXc4007843; Tue, 17 Mar 2015 12:29:33 GMT
Received: (from asalamon@localhost) by server2.gaon.net (8.14.3/8.14.3/Submit 0.2) id t2HCTXjf007842; Tue, 17 Mar 2015 12:29:33 GMT
Date: Tue, 17 Mar 2015 12:32:08 +0000
From: Andras Salamon <andras@dns.net>
Sender: andras@dns.net
To: dnsop@ietf.org
Message-ID: <20150317123208.GA96904@gaon.net>
References: <alpine.LSU.2.00.1503161122260.23307@hermes-1.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Disposition: inline
In-Reply-To: <alpine.LSU.2.00.1503161122260.23307@hermes-1.csi.cam.ac.uk>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/fYwI3crDp72iFD5t9YPEzkMVflk>
Subject: Re: [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: Tue, 17 Mar 2015 12:29:38 -0000

On Mon, Mar 16, 2015 at 11:25:33AM +0000, Tony Finch wrote:
>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 is elegant, except for the base case of what record type to
synthesize in the NOERROR/NODATA case.

Robert Edmonds pointed out that using NULL is not a perfect solution
here.  On the other hand, I am not convinced that creating a completely
new record type is better than NULL for achieving interoperability
with broken implementations.  These solutions are both likely to lead
to problems.

Because NOERROR/NODATA are cached, these should be avoided.  But are
problems with NULL or a new data type really a good tradeoff against
the undesirable behaviour of clients retrying at other servers?

-- Andras Salamon                   andras@dns.net