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

Joe Abley <> Sun, 16 February 2014 16:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5ABD91A03FD for <>; Sun, 16 Feb 2014 08:48:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GfuSmWcEX9Qc for <>; Sun, 16 Feb 2014 08:48:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::234]) by (Postfix) with ESMTP id 8E8FA1A03FE for <>; Sun, 16 Feb 2014 08:48:38 -0800 (PST)
Received: by with SMTP id m12so3725008iga.1 for <>; Sun, 16 Feb 2014 08:48:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=hoy8lIzu4c/26J9UaSj7C9cGT9GZl7eHA+GZ7ylGxhg=; b=oEk8AIskzHRck39OJR+vh8hlYNpxa94o9aDwWNvP8FlqO+nbVZyQP+gHqq/P1EBtfG uqVykAzgFEZF1kEgrw6LYpF7Ls36YGZNJay6We0sp7yxwwq2+2xs/GZnUDVd+vbHfXdC 6I/Oa1ifBoYKTKhqBHR/62fkuewDgUrlGMADs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hoy8lIzu4c/26J9UaSj7C9cGT9GZl7eHA+GZ7ylGxhg=; b=PQQo1x/1I1Xzno2H+DBgdmyslMTGSmPOgmYCUuxG6cnOar8XY/nNovRJpZ4qd6FltW lugNbXNlmQvM08YN71aw4phMHpiXYtJm6NbcRESrvgTBgJEjY5YUKmMPvaNRq5wjfZDW Bq5+97I+BLm9opyLKgg+V2v23CMQ5suIEx0cAHLW56Wq3YorltjukpSxSYp16pIec36a Qdh/urpsXJZdHujL6xPYC2JSiQ2DWPcTkzafB5LV21LvaqyX6fMTQhW80KWAy2wHL9Y+ ZyTp9YwOA1ec4P1yTNG3L3ywDSRJLwmboBkNDlNyL5QDQLzH9+ubQHSaZMMY/xXfejI6 T64g==
X-Gm-Message-State: ALoCoQlbHJ9NPfG7QmFdZIJAwPCtTh0KLWk11TJLrUMVRpuagNXSpLqSuSVzVjFQb+nAB1IwioWb
X-Received: by with SMTP id la10mr14597763icc.10.1392569316098; Sun, 16 Feb 2014 08:48:36 -0800 (PST)
Received: from ?IPv6:2001:4900:1042:1:6d4a:1c1b:df6d:b7b9? ([2001:4900:1042:1:6d4a:1c1b:df6d:b7b9]) by with ESMTPSA id vu3sm23634942igc.6.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 08:48:34 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_C81CFD78-ED2C-4B3B-9C62-615CCBC099F2"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Joe Abley <>
In-Reply-To: <>
Date: Sun, 16 Feb 2014 11:48:32 -0500
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <>
X-Mailer: Apple Mail (2.1827)
Cc: dnsop <>, Paul Hoffman <>
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: Sun, 16 Feb 2014 16:48:40 -0000

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?

Anybody else feel like working on the specification for SCTP transport? :-)