Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

Paul Vixie <vixie@tisf.net> Mon, 28 December 2015 19:30 UTC

Return-Path: <vixie@tisf.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9691AC3D3 for <dnsop@ietfa.amsl.com>; Mon, 28 Dec 2015 11:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level:
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001] autolearn=ham
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 HJWlxEhM_kDn for <dnsop@ietfa.amsl.com>; Mon, 28 Dec 2015 11:30:33 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40E71AC3D2 for <dnsop@ietf.org>; Mon, 28 Dec 2015 11:30:32 -0800 (PST)
Received: from linux-85bq.suse (unknown [24.104.150.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 74BAD1814C; Mon, 28 Dec 2015 19:30:32 +0000 (UTC)
From: Paul Vixie <vixie@tisf.net>
To: Olafur Gudmundsson <ogud@ogud.com>
Date: Mon, 28 Dec 2015 11:30:32 -0800
Message-ID: <5004966.q9dYLaveqz@linux-85bq.suse>
Organization: TISF
User-Agent: KMail/4.14.10 (Linux/4.1.13-5-default; KDE/4.14.10; x86_64; ; )
In-Reply-To: <A82E8E5B-4295-439D-9293-0C7C8941D863@ogud.com>
References: <20151228044020.48378.qmail@ary.lan> <A82E8E5B-4295-439D-9293-0C7C8941D863@ogud.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart7803232.HOeW6Yme7b"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/QHGNNZHFZABeLHcehsXvISvZ48U>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Dec 2015 19:30:34 -0000

On Monday, December 28, 2015 09:43:01 AM Olafur Gudmundsson wrote:
...> In 1999 or 2000 we started seeing LoadBalancers that returned NXDOMAIN for
> any query other than A for a name. At the time the bind-9 team argued about
> what to do, I still think that the behavior selected was the wrong one i.e.
> ignore NXDOMAN for AAAA query and ask for A.

i agreed with you and still do. the operators consuming BIND9 didn't and still don't.

> IMHO a resolver that does not like the answers it is getting from a
> authority has full right to stop trying to find the answer and return
> SERVFAIL. I understand that operators of said resolver will get complaints
> that important cat pictures are unavailable,……

i would love it if operators would want the best long term outcome, and would tolerate short 
term pain in order to inflict tough love elsewhere in the economy. however, just as comcast 
didn't like being the only operator whose DNSSEC validation was causing nasa.gov not to 
resolve during a high-profile landing on some asteroid somewhere, it's also the case that no 
operator can afford to take phone calls and trouble reports from large numbers of customers 
at once.

> I think for all practical purposes this situation is a great example of the
> “Prisoners Dilemma” as there is no way to educate the people writing the
> crap software as they are insulated by multiple layers of protection.

i agree with this analysis.

arguably, the moment we all agreed that DNSSEC's only purpose was to cause more 
resolution failures more often for more and new reasons, we ought to have said it can't be 
deployed and shouldn't be designed at all. i'm glad we did the foolish thing and kept going, 
though.

-- 
P. Vixie