Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

"John Levine" <johnl@taugh.com> Wed, 19 July 2017 21:58 UTC

Return-Path: <johnl@taugh.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 295791317D4 for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 14:58:14 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 iRzCVtQ4yPsR for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 14:58:12 -0700 (PDT)
Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22CC12F29A for <dnsop@ietf.org>; Wed, 19 Jul 2017 14:58:12 -0700 (PDT)
Received: (qmail 14488 invoked from network); 19 Jul 2017 21:58:11 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Jul 2017 21:58:11 -0000
Date: 19 Jul 2017 21:57:49 -0000
Message-ID: <20170719215749.2241.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dnsop@ietf.org
Cc: paul@nohats.ca
In-Reply-To: <alpine.LRH.2.20.1707190347390.10419@ns0.nohats.ca>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cCrNAdxIL_V_reTcZEHsjjXq8BU>
Subject: Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
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: Wed, 19 Jul 2017 21:58:14 -0000

In article <alpine.LRH.2.20.1707190347390.10419@ns0.nohats.ca> you write:
>We are adding something to DNS that's not just a new RRTYPE. It requires
>code changes and has a deployment and long tail. ...

I realize that my biggest problem with this draft is not that I don't
think that it's useful -- we have lots of RFCs that turned out to be
useless but harmless.  It's that it breaks the DNS by being
egregiously not backward compatible.

I would strongly prefer if we defer consideration of this draft until
we figure out how to do DNS versioning, some way to say that this
record type (and consequently, the zone returned to this AXFR or IXFR)
requires special processing, and if you don't know how to do the
processing, don't guess.  This would update or perhaps even replace
RFC 3597.

We did this in a horrible ad-hoc way with DNSSEC, and even with DNSSEC
there's the fallback that the unsigned answers you get from a server
that doesn't understand RRSIG et al. are for many purposes adequate.
But with BULK, if a secondary doesn't understand it, the answers will
just be wrong.

This might be something like an EDNS item which includes the
need-to-understand rrtypes, but I'd prefer to do it in a way that will
make the AXFR or IXFR result invalid to an old server that doesn't
understand it.

R's,
John

PS: h/t to Andrew Sullivan who replied to my suggestion that people do
BULK in a stunt server by noting that we're here to make things
interoperate.