Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)

"John Levine" <johnl@taugh.com> Mon, 17 February 2014 03:41 UTC

Return-Path: <johnl@iecc.com>
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 0942D1A042E for <dnsop@ietfa.amsl.com>; Sun, 16 Feb 2014 19:41:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.542
X-Spam-Level: *
X-Spam-Status: No, score=1.542 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=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 3IbuGX8mOm7N for <dnsop@ietfa.amsl.com>; Sun, 16 Feb 2014 19:41:44 -0800 (PST)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 671811A0332 for <dnsop@ietf.org>; Sun, 16 Feb 2014 19:41:44 -0800 (PST)
Received: (qmail 67572 invoked from network); 17 Feb 2014 03:41:40 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 17 Feb 2014 03:41:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=530184f1.xn--i8sz2z.k1402; i=johnl@user.iecc.com; bh=HNfBWDDyqC/52WEkX+zsJMDba7drkm9NoEvwIDVGCCo=; b=HheaA60CVa5bVYPATnkxv+uuZeCsAVNnL1wMxPwmzlEJ4CHIoiQYEEIZcEi/C3dMYEm/EmBC+dHZ8gH72kQYdjr/9zxxMGDFYvBDOTKYDIjIX7NqUBk4EiFUKEOQajPrXNO3y8CqXVnRPFHUI02g6sWwrrHlt1JN2kyOT3FBhueZdLaCdlfikawSOKV3j89IIt1lD60eY6PMuRcbOMF5JL95Qy27XspcGnwXw/TpVZmx5zqk+4r0Q3331GIjBzdt
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=530184f1.xn--i8sz2z.k1402; bh=HNfBWDDyqC/52WEkX+zsJMDba7drkm9NoEvwIDVGCCo=; b=lRshPSmNTin0kC6pC6m0VQun/HU38kEgHH/oNcVTASus24X1JAsKPdTzhaI4hVrkRKOFNW11v57CS2NABwHRJ0OikWl/+yG/mU50Y2Olc7DWS3uta2dn6Ic13IgatiwoWSNsCsXDfhtIwglqSTjk8XqHRZpxx5vTCkYCV64OhFvMNlkpsC9cYsyKGnE0JSQREU8Rl3nBlcOJzTPs/GW/Ex7O/N2j7pV16RQxEdZ6/y86kmfHql4p+f6r5e6SK8//
Date: 17 Feb 2014 03:41:14 -0000
Message-ID: <20140217034114.64447.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: dnsop@ietf.org
In-Reply-To: <53006595.5010207@frobbit.se>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/UvYpCrm9xNKMKCIxszrD4wNdVfM
Subject: Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
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: <http://www.ietf.org/mail-archive/web/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, 17 Feb 2014 03:41:46 -0000

>The largest problem for IETF and DNS innovation is that the consensus in
>IETF seems to be that innovation of DNS is not possible unless it
>involves reuse of the TXT resource record.

Yes, sort of.  The consensus in one part of the IETF is that adding
new RR types is too hard due to DNS server upgrades and particularly
to the web crudware that most people use to provision their DNS.  The
consensus in another part of the IETF is that adding new RR types is
trivial, and anyone who thinks otherwise is stupid.  (I oversimplify
but not by much.)

I've had a draft kicking around for a while, with recent additions
from Vixie, of an RR config language to allow the DNS to be largely
self-describing, with most new RR types having names and formats
published in a well known place so the servers and crudware can handle
new RRs without software upgrades (after a one-off upgrade to handle
the config language itself) or config changes.

The responses to the draft have been most educational.

R's,
John