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

Jay Daley <> Mon, 17 February 2014 06:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EAEF91A0375 for <>; Sun, 16 Feb 2014 22:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2woykkwTjD0X for <>; Sun, 16 Feb 2014 22:39:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6EC8A1A036E for <>; Sun, 16 Feb 2014 22:39:09 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 6D1C54B9819; Mon, 17 Feb 2014 19:39:04 +1300 (NZDT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GNjQZOnrsVds; Mon, 17 Feb 2014 19:38:55 +1300 (NZDT)
Received: from [] ( []) (Authenticated sender: jay) by (Postfix) with ESMTPSA id 6E9D04B9818; Mon, 17 Feb 2014 19:38:55 +1300 (NZDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Jay Daley <>
In-Reply-To: <>
Date: Mon, 17 Feb 2014 19:38:53 +1300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Joe Abley <>
X-Mailer: Apple Mail (2.1827)
Cc: dnsop <>
Subject: Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Feb 2014 06:39:13 -0000

On 17/02/2014, at 5:48 am, Joe Abley <> wrote:

> On 2014-02-16, at 11:39, Patrik Fältström <> wrote:
>> - We can not use new RR Types, lets use A and TXT
>> - DNSSEC will never take off
>> - Lets just use HTTP for transport
> I think we are suffering from a knee-jerk instinct to say no to ideas that we assume will never work in the real world.
> We can't add more transports (e.g. SCTP), because even if implemented there's just too much middleware in the world that will interact badly.
> We can't add more resource records, because there are nameserver implementations that don't deal with opaque types properly, and won't allow the new resource records to be published.
> We can't do anything that will cause larger responses, because EDNS support is not widespread, and in any case the network can't reliably deliver fragments.
> If we believe all these problems are intractable, then we might as well just accept that overloading TXT records and reflection attacks are a fact of life, and stop worrying about them.
> What I would prefer, though, is a more entrepreneurial approach where the likelihood of short-term operational problems (or even long-term failure of the work) should not stop us from trying. Rich people are the ones that realise that you only need one out of ten business ventures to succeed to get a pay out.
> So, how about a starting point where we assume that if a particular extension has value to anybody, the operators (the market) will adjust to allow it to work, and if it doesn't, then adjustments are not necessary?

Very well put indeed.

The default position currently seems to be that consensus is so hard to achieve because it demands so much that very little can pass.  A particular symptom of that is the increasing calls for a "requirements draft" or "problem statement" (which is obviously wider than DNSOP).

We'd do well from turning that on its head and making the default position that everything passes unless consensus is that it shouldn't, which would generally be because it is truly awful, duplicative, nobody understands it, etc.

As Henry Ford probably didn't say "If I had asked people what they wanted, they would have said faster horses.”.  Or better still a genuine quote from Steve Crocker in the final ICANN board vote on new TLDs:  "The case for new TLDs is a little harder to pin down.  But one of the most important principles in the creation of the Internet from a very long time ago was not to stifle or prejudge what the paths for innovation are.  So the default has to be that, absent a strong case that such things will cause harm, we must move forward.  And I strongly support this."


> Anybody else feel like working on the specification for SCTP transport? :-)
> Joe
> _______________________________________________
> DNSOP mailing list

Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840