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
- [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop-qna… Barry Leiba
- Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop… Stephane Bortzmeyer
- Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop… Tim Wicinski
- Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop… Stephane Bortzmeyer
- Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop… John Levine
- Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop… Paul Wouters
- Re: [DNSOP] Refusing NS queries, was Barry Leiba'… John Levine
- Re: [DNSOP] Refusing NS queries, was Barry Leiba'… Paul Wouters
- Re: [DNSOP] Refusing NS queries, was Barry Leiba'… Shumon Huque
- Re: [DNSOP] Refusing NS queries, was Barry Leiba'… Paul Vixie
- Re: [DNSOP] Refusing NS queries, was Barry Leiba'… John Levine
- Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop… John Levine
- Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop… Paul Vixie
- Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop… John R Levine
- Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop… Olafur Gudmundsson
- Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop… Mark Andrews
- Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop… Paul Vixie
- Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop… Jared Mauch