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

Petr Špaček <petr.spacek@nic.cz> Mon, 20 March 2017 11:08 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 0961C129BD1 for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 04:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 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] 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 zEDG5UWJ3XM8 for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 04:08:57 -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 33A2B129BCB for <dnsop@ietf.org>; Mon, 20 Mar 2017 04:08:55 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:b8a2:11ff:fe81:fe78] (unknown [IPv6:2001:1488:fffe:6:b8a2:11ff:fe81:fe78]) by mail.nic.cz (Postfix) with ESMTPSA id 7068860530; Mon, 20 Mar 2017 12:08:53 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1490008133; bh=YJRrXM80rSWzO2uxvXrKev+hqLmfxIsGTlwlNEl7CNo=; h=To:From:Date; b=VKM9dAZ3+F2dMbR3RCLmaHzqYkvRCgTgyPJfuQ441uD2sxw/UB3RZnYVmZkZ30s2x x26oLeiEpl87iRCFL8Er1kLOdX1hvJnku+VwEIDSeTz/kxUP924y+wZtwwrD24D9TS q0Jz6TeK6/ZvlOZTIGryfO+XE01b85CwGVBtCLyM=
To: Tony Finch <dot@dotat.at>
References: <CADyWQ+GSStfAiOs8R9Ob7+LVh0RAfPQ+AbbTFNuwsrKkO=EUWg@mail.gmail.com> <80ef59d5-a032-df88-98e7-05bdfe7f8b22@nic.cz> <alpine.DEB.2.11.1703171942200.13590@grey.csi.cam.ac.uk>
Cc: dnsop@ietf.org
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <bc9697a8-ce4c-a589-09d1-10f7d7ababff@nic.cz>
Date: Mon, 20 Mar 2017 12:08:53 +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: <alpine.DEB.2.11.1703171942200.13590@grey.csi.cam.ac.uk>
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/uo2HkYu2HbqjK21aAyAND4gJTI4>
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: Mon, 20 Mar 2017 11:08:59 -0000

On 17.3.2017 20:54, Tony Finch wrote:
> Petr Špaček <petr.spacek@nic.cz> wrote:
>>
>> 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.
> 
> Gosh! In what situations do you get missing RRSIGs? Is that not a sign
> that either your upstream server doesn't support DO=1, or that you are
> under attack from a malefactor / middlebox? Why not re-query a different
> upstream server with the full query?

Tony, I agree with you. QTYPE=RRSIG is an attempt of drowning man to
catch at a straw. It will certainly not work realiably and Knot is using
it as solution of last resort if everything else failed.
Please do not get distracted by this.

My proposal is just about properly documenting QTYPE=RRSIG behavior so
it is very clear from first read. The goal is to avoid having the very
same discussion about under-defined behavior as we have around ANY today.

If there is another RFC saying that QTYPE=RRSIG is special then please
add a pointer to it. I might have missed that one. If there is none,
please clarify the draft.

I hope it clarifies that I have no objection to proposed behavior, just
to the way it is described. Thank you for understanding.

Proposals for clarification are here:
https://mailarchive.ietf.org/arch/msg/dnsop/lZDOOOOnD1kCZQ1Zvm0YF6wbWtg


> The BIND 9.11 minimal-any implementation treats RRSIG queries similarly to
> ANY queries, so it only returns one RRset's RRSIGs (i.e. a subset of the
> RRSIGs all with the same type-covered field).
> 
> Cloudflare's response to RRSIG queries is REFUSED. Negligible risk of
> interop problems in this case, unlike ANY.
> 
> I think RRSIG is a diverting sideshow. It might merit a mention in the
> abstract but I don't think it needs to be in the title.

I'm certainly not insisting on title change. It just seemed as a cheap
way to advertise that the document touhes on QTYPE=RRSIG so I did not
see a reason for not mentioning it in the title.

-- 
Petr Špaček  @  CZ.NIC