Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt

Dave Lawrence <> Tue, 04 July 2017 00:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14DD2131811 for <>; Mon, 3 Jul 2017 17:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PUODeb1o-r_h for <>; Mon, 3 Jul 2017 17:21:00 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04364131816 for <>; Mon, 3 Jul 2017 17:20:55 -0700 (PDT)
Received: by (Postfix, from userid 102) id 173863F442; Mon, 3 Jul 2017 20:20:53 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Mon, 03 Jul 2017 20:20:53 -0400
From: Dave Lawrence <>
To: dnsop <>
In-Reply-To: <>
References: <> <>
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Jul 2017 00:21:10 -0000

Ray Bellis writes:
> This is just a "keep alive" so as to keep this draft in consideration as
> one of the multiple solutions in this problem space while DNSOP decides
> whether this is a problem worth solving.
> I still think it's the most elegant of those proposed ;-)

I whole-heartedly agree, as Ray's idea was the basic conclusion I'd
arrived at independently.  I was going to propose something very
similar (with only minor differences in details) until I found out
that I'd somehow overlooked his previous draft.

Note that I'm saying this even though I am also now working with
Warren and Wes on the multiple-response draft, which I suspect is one
of the other proposed solutions that Ray implies above.

I believe that multiple-response and multi-qtypes solve similar but
somewhat different problems.  As Wes observed during a conversation
last week, the former is for when the authoritative server believes it
knows what records you're going to want next (and even then can't
effectively signal the absence of any particular record).  The latter
is driven by the client knowing just types it'll want to know about
for a given qname, and indicates explicitly what the existence of each

Multi-qtypes is also far easier to implement and will be much more
useful much more quickly.  It can roll out in resolvers and
authorities incrementally without depending on DNSSEC and with far
fewer security concerns.  At a recent industry meeting I announcement
my intention to ask Ray to revive it and was met with fairly
widespread support from both authoritative and recursive operators.

I'm strongly behind multi-qtypes and will be proselytizing for it as
well as contributing text.