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

Dave Lawrence <> Tue, 04 July 2017 17:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C3021325BF for <>; Tue, 4 Jul 2017 10:34:21 -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 a-XKCj7PT4oW for <>; Tue, 4 Jul 2017 10:34:19 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 812211325CD for <>; Tue, 4 Jul 2017 10:34:19 -0700 (PDT)
Received: by (Postfix, from userid 102) id 1F1223F438; Tue, 4 Jul 2017 13:34:18 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Tue, 04 Jul 2017 13:34:18 -0400
From: Dave Lawrence <>
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 17:34:21 -0000

On 7/4/17 6:13 AM, Paul Wouters wrote:
>> Although, we should also be a bit careful not to create a new ANY
>> type query that will get abused for amplification, so it should
>> really all have source verified IP transports (DNS-COOKIES, TCP, etc)

Ray Bellis writes:
> I'd rather not constraint this to source verified transports.
> There's a limit of 7 additional QTYPEs in the draft, which could be
> trivially reduced to 3 (with little effect on the functionality) if that
> would mitigate concerns about amplification.

I very much agree with Ray about not constraining it like this.

While for my own imagined use cases three is adequate, such as for
querying MX, A and AAAA simultaneously, I also don't see any
compelling reason to drop it from his proposed seven.  In my own
scheme I had planned on using a NSEC-like type bitmap, but having
spoken with Ray about this a while ago I know he's not keen on that.

To me the focus on answer size amplification is misdirected.  I am far
more concerned about packet count than packet size, and in any event
constraining this option to only verified channels makes it
immediately less useful.