Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Joe Abley <jabley@hopcount.ca> Wed, 06 March 2019 14:37 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 859B4126C87 for <dnsop@ietfa.amsl.com>; Wed, 6 Mar 2019 06:37:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level:
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 9W_BpPaSr3ww for <dnsop@ietfa.amsl.com>; Wed, 6 Mar 2019 06:37:38 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD96124BA8 for <dnsop@ietf.org>; Wed, 6 Mar 2019 06:37:38 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id y6so10361713ioq.10 for <dnsop@ietf.org>; Wed, 06 Mar 2019 06:37:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r5Mg9Bx1LjCpWH63SY7XrpqIa5gX10Pu//iK0NrruC4=; b=B9+ycT5Z7ojKPFv+8/RccmN9d/foGaRwFNqixYEpn2YV4XsbuLO3569xd439fCvQ4S 9pVZPtzWWaSbvbvh2FGH5prIhe+HTdRl/NUI88f5galg/XXoWJQ/BlSktUXfWNolRzIk ERRerclLZrOnB1VsLtaav464FqWdTo+y2I+to=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r5Mg9Bx1LjCpWH63SY7XrpqIa5gX10Pu//iK0NrruC4=; b=uHdviEfkZo//94qrfl39w9/dPnsf2wbQnsGGrP0MmEk73SvrzB6GdzxI0OYUVsl7ZW eFzkxV4e2meybb3fAyQQVkF8P/58doyezDQNK5GJjb9dCXXed6WC4+0un29vM8HrvyGf NUjKFo91HwuEtW9q2g0/Lxquf4B7yJ3TD7iIV8VpgJNO4nmANLdWwtVdwNQEA+sGTQww XN6wqKrPKUDB+PpSExeM5FUkQET1zyj1zS/6+pdadGiRugnaGFIDtYzmdEcrMKet/v0u 5R1/o4QiqcRyzD2OcWKPL+Q2Ueh9pX04357ojSkxEzDxfu8+Yje+WG+Fa/16Vadb5zXt QUlg==
X-Gm-Message-State: APjAAAX6OgYTo6lUaoVIW7wtxGvpwFFeoUombZSpuiHvskdWfJ3o5cpU rEigaQCIVrIPm5R4HOIh3a/3UUid0z+PAQ==
X-Google-Smtp-Source: APXvYqyFuMlCAj/Xnbu86NDzyxLzHBSc1hDOy4oUVQSi6Tah8/IlqcXab2qF62foTIqDrQFSeXPSQQ==
X-Received: by 2002:a5e:8345:: with SMTP id y5mr3113007iom.163.1551883057629; Wed, 06 Mar 2019 06:37:37 -0800 (PST)
Received: from ?IPv6:2607:f2c0:e786:128f:41e5:4c2a:3356:5160? ([2607:f2c0:e786:128f:41e5:4c2a:3356:5160]) by smtp.gmail.com with ESMTPSA id r21sm602508ioj.62.2019.03.06.06.37.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 06:37:36 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <alpine.DEB.2.20.1903061237440.17454@grey.csi.cam.ac.uk>
Date: Wed, 6 Mar 2019 09:37:35 -0500
Cc: Dave Lawrence <tale@dd.org>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BCC02A3-9F05-4A35-A06E-D69719EB7CB5@hopcount.ca>
References: <155094804613.28045.8648150477440044197@ietfa.amsl.com> <CA+9_gVscCzr0S8A0Z23q0V1B+BZeLtDoZRSKyEJDPZ3P=KT-tw@mail.gmail.com> <CAL9jLaYo5JH6vf+djEn0O=YGhLV2AkytMg_eKQmWn=Pma5yBFQ@mail.gmail.com> <4253851.Zqd2zPpPcC@linux-9daj> <92355508-D5AC-46DC-8FF5-C1C4155601D8@isc.org> <alpine.LRH.2.21.1903042240330.32161@bofh.nohats.ca> <23678.40176.492174.37630@gro.dd.org> <3E7AF476-0989-4FA8-8186-F5AAFC87317A@icann.org> <alpine.LRH.2.21.1903051202360.1124@bofh.nohats.ca> <23679.9798.678631.923122@gro.dd.org> <alpine.DEB.2.20.1903061237440.17454@grey.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6Hl-8BEzLKY2tu1jti8fahcEix0>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 06 Mar 2019 14:37:41 -0000

On 6 Mar 2019, at 08:03, Tony Finch <dot@dotat.at> wrote:

> Dave Lawrence <tale@dd.org> wrote:
> 
>> REFUSED is slightly murkier as to its exact meaning, thanks to
>> overloading, but in its most commonly seen usage for lameness
>> indicates a clear problem with the delegation.  Even in its other use
>> cases, notably an EDNS Client Subnet error or an actual "I am
>> authoritative for the name but administratively denying your
>> resolution of it", I submit that if the resolver has a stale answer
>> then serving it is reasonable.
> 
> This sounds like it will lead to stale answers being given instead of
> re-trying other potentially working servers. I think this is wrong, and
> it's inconsistent with your other reply, so I am confused.
> 
> https://mailarchive.ietf.org/arch/msg/dnsop/HIUK2ME8uHbA-cwztnrNVYRtqLc
> 
> I think serve-stale should only cover cases where servers are unreachable
> or unresponsive.

That phrase sounds concise and definitive, but it's not really.

How recently should a server have been checked and found not to respond to conclude that it's unresponsive? What does unresponsive mean? Presumably this involves a timeout; how long? Perhaps these questions are already answered in practice by existing implementations, but I don't know that they are written down anywhere.

If a server responds to some queries but not others (e.g. same QNAME, different QTYPEs) is that unresponsive across the board? Or does responsiveness depend on the precise (QNAME, QCLASS, QTYPE) tuple?

This is not only a pedantic, annoying observation (you're welcome) but I think the last question provides an attack vector; if you can find a set of DNS authority servers that silently discards a particular kind of query, sending such queries through resolvers that are known to support serve-stale might suppress other queries and trigger the serve-stale behaviour even though the authority servers are not actually unresponsive for them.

I think it's a fair observation that such authoritative servers are broken, but I seem to think they exist e.g. due to the ongoing existence of poorly-conceived middleboxes. If I'm mistaken about that last part then I guess we're back to pedantic and annoying.


Joe