Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

Petr Špaček <petr.spacek@nic.cz> Fri, 17 March 2017 12:14 UTC

Return-Path: <petr.spacek@nic.cz>
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 4EF53128C82 for <dnsop@ietfa.amsl.com>; Fri, 17 Mar 2017 05:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 ien7RNN3rl2D for <dnsop@ietfa.amsl.com>; Fri, 17 Mar 2017 05:14:02 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB7E126C7A for <dnsop@ietf.org>; Fri, 17 Mar 2017 05:14:01 -0700 (PDT)
Received: from [192.168.4.155] (unknown [212.71.184.5]) by mail.nic.cz (Postfix) with ESMTPSA id 93FA860140 for <dnsop@ietf.org>; Fri, 17 Mar 2017 13:13:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1489752839; bh=cKg519uRFMbiigsrkK4ZgM+eueUsHT4ODYSge5jqOpY=; h=To:From:Date; b=sEdkyG4gWU+tpI9Opeitj9+b8sXG0vmmUrXWIpLGn/XJdqCG67DpTiV2whnYuDa23 cFAutDFISTrftvk49NvIdu4jqCK24aFSJCb+pm+d33F+EQdHuPEbqVI6PHB38qPuz6 ShOoAaGqD9XS/IIN6U6SQ2rXzaoSSFStGZQ7u354=
To: dnsop@ietf.org
References: <CADyWQ+GSStfAiOs8R9Ob7+LVh0RAfPQ+AbbTFNuwsrKkO=EUWg@mail.gmail.com>
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <80ef59d5-a032-df88-98e7-05bdfe7f8b22@nic.cz>
Date: Fri, 17 Mar 2017 13:13:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CADyWQ+GSStfAiOs8R9Ob7+LVh0RAfPQ+AbbTFNuwsrKkO=EUWg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lZDOOOOnD1kCZQ1Zvm0YF6wbWtg>
Subject: Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any
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: Fri, 17 Mar 2017 12:14:04 -0000

Hello,

and sorry for being so late.

While reading the draft and related discussion I realized that the draft
has two important problems which were not obvious at first:

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 believe that it would greatly improve readability of the draft.
Petr Špaček  @  CZ.NIC

On 16.3.2017 08:11, tjw ietf wrote:
> 
> All
> 
> During the first WGLC of draft-ietf-dnsop-refuse-any, several issues
> were raised by the working group that needed to be addressed. The
> Authors addressed the issues, but the changes are enough that there
> should be a second Working Group Last Call on the changes. 
> 
> This begins a Second WGLC for draft-ietf-dnsop-refuse-any.  The Document
> is located
> here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
> 
> However, the changes that were made since the last WGLC can be found here:
> 
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-refuse-any-03&url2=draft-ietf-dnsop-refuse-any-04
> 
> Please take a few moments to refer the changes and let the working group
> know if the document is ready to move forward.   We're mostly looking
> for remaining issues that have not been addressed.  
> 
> This WGLC ends on Thursday 30 March