Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

Andrew Sullivan <ajs@anvilwalrusden.com> Sat, 26 March 2016 20:43 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 8C36812D5FC for <dnsop@ietfa.amsl.com>; Sat, 26 Mar 2016 13:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Y38w1t0haqdC for <dnsop@ietfa.amsl.com>; Sat, 26 Mar 2016 13:43:36 -0700 (PDT)
Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id E123712D622 for <dnsop@ietf.org>; Sat, 26 Mar 2016 13:43:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 87C6310ACE for <dnsop@ietf.org>; Sat, 26 Mar 2016 20:43:35 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSQ-jJVoi7Zt for <dnsop@ietf.org>; Sat, 26 Mar 2016 20:43:34 +0000 (UTC)
Received: from mx2.yitter.info (c-73-142-157-135.hsd1.nh.comcast.net [73.142.157.135]) by mx2.yitter.info (Postfix) with ESMTPSA id C6A6C10ACB for <dnsop@ietf.org>; Sat, 26 Mar 2016 20:43:34 +0000 (UTC)
Date: Sat, 26 Mar 2016 16:43:32 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20160326204332.GU5239@mx2.yitter.info>
References: <20160325230119.GA5239@mx2.yitter.info> <20160326025121.14477.qmail@ary.lan> <CAN6NTqzHOqp5QF1CO1Mt+O=U_iHTkWu2G0jQ3-inFhG-oc6khQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAN6NTqzHOqp5QF1CO1Mt+O=U_iHTkWu2G0jQ3-inFhG-oc6khQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/n8RUZuEnJLFmlRuUIua48p2grnE>
Subject: Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free
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: Sat, 26 Mar 2016 20:43:37 -0000

On Sat, Mar 26, 2016 at 03:59:39PM -0400, Ólafur Guðmundsson wrote:
> There are 3 possible outcomes when a DNS querier gets an aswer like this
> #1 It accepts everything from authority section
> #2 It tosses the non queried RRset
> #3 it Rejects the answer and tries again

#4 it panics and you don't know that.

There's no way to know whether #4 cases are out there, and nothing in
any data you collect would tell the difference between 1 and 4.  I
think the chances are pretty low because of the experience with DNSSEC
deployment, but at least there we were relying on the DO bit.  What
you're proposing is to change the protocol for people who don't even
set DO.  Surely that's risky?

> For #2 that means convincing the software vendors to adopt more relaxed
> approach

No, it means making a protocol change to a well-established,
long-deployed standard and _then_ getting people to adopt it, and
doing so without any signals about the deployment.

Please don't think I'm saying no: my employer feels this pain just as
much as yours does, and I also am anxious to support ideas that move
the state of the art ahead.  But I cannot believe we are seriously
talking about deploying stuff that changes a 30 year old
connectionless protocol without any signal in the protocol that the
change is ok for the involved players in each exchange.  If that's
really the sort of thing we're going to do, then we might as well just
start uploading protocol definitions to github and tell people to try
to track them.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com