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

Matthijs Mekking <matthijs@pletterpet.nl> Fri, 06 January 2017 15:28 UTC

Return-Path: <matthijs@pletterpet.nl>
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 05467129567 for <dnsop@ietfa.amsl.com>; Fri, 6 Jan 2017 07:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
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 oqH-KGzTueqN for <dnsop@ietfa.amsl.com>; Fri, 6 Jan 2017 07:28:24 -0800 (PST)
Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 6584B129566 for <dnsop@ietf.org>; Fri, 6 Jan 2017 07:28:24 -0800 (PST)
Received: from [172.19.128.50] (vpn-10-mht.dyndns.com [216.146.45.33]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 96DCA87C3 for <dnsop@ietf.org>; Fri, 6 Jan 2017 16:28:21 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl
To: dnsop@ietf.org
References: <CADyWQ+FwGf66+HL3W46C2d1BJZoyRxBDPPw8Yuup8k0Haise=g@mail.gmail.com> <20170104171112.GA1967@sources.org>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <818f1d43-87c1-1c1c-9125-bf9dbe7022c3@pletterpet.nl>
Date: Fri, 06 Jan 2017 16:28:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <20170104171112.GA1967@sources.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4anhGcOWyPmJKkvxbhc0G8U-QHI>
Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 06 Jan 2017 15:28:26 -0000


On 04-01-17 18:11, Stephane Bortzmeyer wrote:
> On Fri, Nov 25, 2016 at 07:50:48PM -0500,
>  tjw ietf <tjw.ietf@gmail.com> wrote
>  a message of 114 lines which said:
>
>> This starts a Working Group Last Call for
>> draft-ietf-dnsop-refuse-any
>
> Since we'll apparently have one more iteration of the draft, one small
> detail. The draft says:

I'll add some more feedback for the next iteration, that came up during 
a discussion with some colleagues, to make the document more clearer:

1. In section 7, "Updates to RFC 1035" the draft says "ANY does not mean 
ALL" and that it is consistent with RFC 1035, while in fact 1035 does 
say that QTYPE=* means a request for all records. It would be good to 
clarify the statement in section 7 that even if RFC 1035 says that the 
ANY query is a request for *all* records, it is not reliable that this 
also means you get all records. In other words, the response behavior is 
consistent with 1035.

2. "Conventional ANY response" is used but not defined. A line or two 
that defines Conventional ANY response to be "a response that includes 
all the available records at the QNAME" or something like that would be 
a good addition.

3. Insisting that the HINFO OS field SHOULD be empty seems a little too 
strong; perhaps it's better to say "The OS field of the HINFO RDATA 
SHOULD be short to minimize the size of the response. It MAY be empty or 
MAY include a summarized description of local policy." Perhaps even the 
keywords can be lowercased?

Furthermore I would be interested in the problems that Cloudflare 
encountered when implementing the HINFO response. All I could find in 
this thread was "probably a validator will requery with QTYPE=HINFO". Is 
that statement based on observations or assumptions?


Best regards,
   Matthijs