[DNSOP] draft-ietf-dnsop-refuse-any: points from Petr Špaček

Joe Abley <jabley@hopcount.ca> Tue, 25 July 2017 20:53 UTC

Return-Path: <jabley@hopcount.ca>
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 5BA31131F2D for <dnsop@ietfa.amsl.com>; Tue, 25 Jul 2017 13:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (OpenSSL error: data too large for key size)" header.d=automagic.org
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 Qzs2x_G3-Yz9 for <dnsop@ietfa.amsl.com>; Tue, 25 Jul 2017 13:53:26 -0700 (PDT)
Received: from mail.hopcount.ca (mail.hopcount.ca [67.215.197.156]) (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 CB676131F02 for <dnsop@ietf.org>; Tue, 25 Jul 2017 13:53:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=automagic.org ; s=hopcount; h=To:Cc:Date:Message-Id:Subject:Mime-Version: Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=QOM5e4UmvAxvkosgz18VD+Y1UPwtMrsNOe3AqpZ/4GA=; b=qCN+dK/85AkStkeLcUk0cKr7+t jQ8xxDs7AvrSxtU4qVzNQZvanmNnwOKc6n0gpK9UH7Y47cAe7c4KFehLZwTZdeNrL+pOAZ0FgT/8X qDXb+AwoHBmvds2AzteV5oQch1iS9ZqWGNgFHAvfSVnzULVa2f6dgRsy48TG8QWlHXKOdQgGSvKMT wLgVkhkYmBzHQqbE/jg2lEyOR5c+u4FlnfCXUQ3EQEbmC0xLY+FlbNztwWOp8bq9pZKZngDk/6KGi R8IP/2n3hz8zRE68NaiE57Ro43bMTd9QIuqplU95ezJqE7MkmIRmJG2K6PvPgtnNpgVePm4ecDymN q56UvHmQ==;
Received: from [2607:f2c0:101:202:8013:ad3e:5316:1b92] (helo=node-131fee54bx1ng9lsb6.ipv6.teksavvy.com) by mail.hopcount.ca with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from <jabley@hopcount.ca>) id 1da6pH-000DZc-8a; Tue, 25 Jul 2017 20:53:07 +0000
From: Joe Abley <jabley@hopcount.ca>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <9002F172-4171-41EE-A0FF-61C7A5ACAD32@hopcount.ca>
Date: Tue, 25 Jul 2017 16:53:07 -0400
Cc: Petr Špaček <petr.spacek@nic.cz>
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3273)
X-SA-Exim-Connect-IP: 2607:f2c0:101:202:8013:ad3e:5316:1b92
X-SA-Exim-Mail-From: jabley@hopcount.ca
X-SA-Exim-Scanned: No (on mail.hopcount.ca); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/a-Q3nDryF41eCZnrtfJREGZt_BA>
Subject: [DNSOP] draft-ietf-dnsop-refuse-any: points from Petr Špaček
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 25 Jul 2017 20:53:28 -0000

Hi Petr, all,

With reference to:

  https://mailarchive.ietf.org/arch/msg/dnsop/lZDOOOOnD1kCZQ1Zvm0YF6wbWtg

> 1. The casse QTYPE=RRSIG should be made more prominent so it is
> understood and not misused as ANY. There are implementations like Knot
> Resolver which are work around missing RRSIG records in replies using
> QTYPE=RRSIG.
> 
> Personally I would rename the document from
>   Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY
> to
>   Providing Minimal-Sized Responses to DNS Queries
>         that have QTYPE=ANY or QRTYPE=RRSIG
> 
> ... and extend Abstract as well:
>    The Domain Name System (DNS) specifies a query type (QTYPE)
>    "ANY" or "RRSIG". The operator of an authoritative DNS server might
>    choose not torespond to such queries for reasons of local policy,
>    motivated by security, performance or other reasons.
> 
> 2. Section Updates to RFC 1035 should use normative language, especially
> regarding RRSIG. Proposal follows:
>    RRSIG queries have the same potential as ANY queries of generating
>    large answers as well as extra work.  In the wild there are
>    implementations that return REFUSE, others return single RRSIG, etc.
>    It is RECOMMENDED returning a single RRSIG in this case.
> 
> 
> 3. Text about necessity of fallback in applications trying to use ANY
> query is burried under non-descriptive section name "Motivation". Given
> the confusion is caused among application developers, I would like to
> see it mentioned and explained again in section "Behaviour of DNS
> Initiators".
> 

I understand the points you're making, and I've read fanf's subsequent reaction to it (and your reaction to that).

I don't have any objection to any of those suggestions, and I'm quite happy to come up with text for them in the next rev of the draft (thanks for your suggestions in 1 and 2). If anybody else here has thoughts about specific text or violent objections to including QTYPE=RRSIG in general, please let me know (I looked in the mail archive but couldn't find any there).

The general approach I am picturing is one in which the issues for ANY and RRSIG are both described, but that implementors are free to address just one if they have particular circumstances that make that sensible. As we discuss (see Stephane's points) in the case of multiple transports, perhaps we can also recommend that implementors provide configuration options to allow administrators to deal with ANY, RRSIG, neither or both. That way we get flexibility that matches deployment, but we also get a reference for handling RRSIG in a predictable way.


Joe