IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Tue, 18 February 2014 22:20 UTC

Return-Path: <marka@isc.org>
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 88DD91A026A for <dnsop@ietfa.amsl.com>; Tue, 18 Feb 2014 14:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-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 yZn8Ym8PZ2uX for <dnsop@ietfa.amsl.com>; Tue, 18 Feb 2014 14:20:07 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 01F171A02BE for <dnsop@ietf.org>; Tue, 18 Feb 2014 14:20:07 -0800 (PST)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5A949C941E; Tue, 18 Feb 2014 22:19:51 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1392762004; bh=2M+T+oOx9aO819AIskfkzO9iWqldH32F2rbQjtWhe2A=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=HSI9q26r0hpBrn6XfdYcDbtdlfe1eYkm9cCviyT+m8myDLyN/5zHSNGQ7NrYIguiL EO29LBFQe/dM/h1RKxD+9gq2v1Zv3osjmTtfDb/rYQ8E2mKyDWdV2pP1pzSZGwGugS vYsrv2CvQ96scWlQ+C+qtiX/s48uWN3r2ziGGtSM=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 18 Feb 2014 22:19:51 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4309016005B; Tue, 18 Feb 2014 22:20:38 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 094C716000C; Tue, 18 Feb 2014 22:20:38 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D7541F9EB9C; Wed, 19 Feb 2014 09:19:48 +1100 (EST)
To: Joe Abley <jabley@hopcount.ca>
From: Mark Andrews <marka@isc.org>
References: <CAESS1RPh+UK+r=JzZ9nE_DUqcvNtZiS6TNt1CDN-C0uiU7HP=A@mail.gmail.com> <52FEF407.30405@redbarn.org> <20140215140133.GA6990@sources.org> <alpine.LFD.2.10.1402151449280.23619@bofh.nohats.ca> <D82F49E8-9A06-4F52-8E3E-DF5C8D0B7549@virtualized.org> <53006595.5010207@frobbit.se> <6.2.5.6.2.20140218074550.0c380cc8@resistor.net> <5B5AE40C-6D26-419C-A16A-392AF2C33446@hopcount.ca>
In-reply-to: Your message of "Tue, 18 Feb 2014 13:58:08 -0500." <5B5AE40C-6D26-419C-A16A-392AF2C33446@hopcount.ca>
Date: Wed, 19 Feb 2014 09:19:48 +1100
Message-Id: <20140218221948.D7541F9EB9C@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/GykD6mJC5nTC2P19ao8GKLFoiKo
Cc: SM <sm@resistor.net>, dnsop <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>, David Conrad <drc@virtualized.org>
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: Tue, 18 Feb 2014 22:20:11 -0000

In message <5B5AE40C-6D26-419C-A16A-392AF2C33446@hopcount.ca>, Joe Abley writes
:
> On 2014-02-18, at 10:54, SM <sm@resistor.net> wrote:
>
> > Seriously, it may take some effort to get things deployed but that is
> not an insurmountable task [1].  One of the problems is that there isn't
> any money in doing that.
> >
> > [...]
> >
> > 1. I actually looked into it some time back.
>
> I had some experience with this recently with the document that became
> RFC 7043.
>
> Code-point assignment was swift. Implementation in major nameservers was
> swift (although one or two of them left the types commented out in the
> source until the RFC was published). The RFC publication process was not
> arduous, even given the privacy concerns with this particular proposal.
>
> I appreciate that knowing the process made things easier (mainly; I was
> wrong about some things and had to be educated). But I would not describe
> the process as difficult, and certainly not insurmountable.
>
>
> Joe

The process for getting a new type hasn't been *hard* for a decade
now.

Nameserver developers have been deploying new types quickly for
over a decade now.

Recursive servers have had the bugs w.r.t. handling unknown types
removed over a decade ago.

Being able to lookup a unknown type is a REQUIREMENT of RFC 103[45]
and there have been (stub) resolvers that can do this for the entire
life of DNS (Microsoft just fail to ship one).

We defined how to specify UNKNOWN record types in master files a
decade ago and most nameserver vendors have shipped code that support
unknown types for over a decade now.  Microsoft is the obvious
exception.

There are some load balancers that don't handle unknown types
properly.  Lots of these don't handle anything other than A. Not
AAAA, TXT, SOA, NS. These need to be chased down and removed /
replaced / upgraded with extreme prejudice.

There are the stupid DNS administration panels the don't handle
UNKNOWN types or for that matter anything other that A, NS and maybe
AAAA and TXT.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email