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

Paul Wouters <paul@nohats.ca> Tue, 04 July 2017 10:13 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5069B131DAE for <dnsop@ietfa.amsl.com>; Tue, 4 Jul 2017 03:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 T9a1TW26nVX0 for <dnsop@ietfa.amsl.com>; Tue, 4 Jul 2017 03:13:37 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4804C131DAB for <dnsop@ietf.org>; Tue, 4 Jul 2017 03:13:37 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3x20Fn2dyHzvk; Tue, 4 Jul 2017 12:13:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1499163213; bh=XqPLTiRKP9jgI5ic2F5HvnbV6xvdGT1LVbARF5cRAgM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sgIooFNj2BwUJPsAdceT0/w7VyxgeWcJWjdlZI+XvbG5fsdjnIFNAw2iKPA6zdvdz f9Mz2KgVA87vZBBOmZ1u1SEZWRZED7WmKCCNEAZGDedKc+dCM5wjpJLqHkwq7KlHF+ IDJtFQjSI0c8RsttJuL/ReSZTUtNfkK8wXXmaKNA=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id gWicBysbw47Y; Tue, 4 Jul 2017 12:13:32 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 4 Jul 2017 12:13:32 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2C85730AF02; Tue, 4 Jul 2017 06:13:31 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 2C85730AF02
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0FE0340D3592; Tue, 4 Jul 2017 06:13:30 -0400 (EDT)
Date: Tue, 4 Jul 2017 06:13:30 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Dave Lawrence <tale@dd.org>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <22874.57189.46244.876797@gro.dd.org>
Message-ID: <alpine.LRH.2.21.1707040609320.29386@bofh.nohats.ca>
References: <149910381354.22770.11872478488745133368.idtracker@ietfa.amsl.com> <c30f8582-5371-1ef0-9067-c8c236ed8e42@isc.org> <22874.57189.46244.876797@gro.dd.org>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_tivVN8EPw8Zmhe8_wTbBHl2Hao>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 04 Jul 2017 10:13:40 -0000

On Mon, 3 Jul 2017, Dave Lawrence wrote:

>> 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 agree.

> 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
> is.
>
> 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.

Good!

And I think any ANAME/ALIAS record should be used in combination with
these, and of itself not define any new special handling.

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)

Another issue to look at is returning any prefix special records,
such as TLSA records which do not match the QNAME, but are strongly
related to the QNAME and would benefit from being returned along.

Paul