[DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses)

Shane Kerr <shane@time-travellers.org> Thu, 28 May 2020 08:00 UTC

Return-Path: <shane@time-travellers.org>
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 9EAA13A0BB0 for <dnsop@ietfa.amsl.com>; Thu, 28 May 2020 01:00:19 -0700 (PDT)
X-Quarantine-ID: <bBxtL84ORmS3>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...T_ADDRESS@@ for details. Content previ[...]
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 bBxtL84ORmS3 for <dnsop@ietfa.amsl.com>; Thu, 28 May 2020 01:00:17 -0700 (PDT)
Received: from saturn.zonnestelsel.tk (saturn.zonnestelsel.tk [IPv6:2001:470:78c8:2::11]) (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 F3BD13A0B0A for <dnsop@ietf.org>; Thu, 28 May 2020 01:00:12 -0700 (PDT)
Received: from earth.zonnestelsel.tk ([2001:470:78c8:2::9]) by saturn.zonnestelsel.tk with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <shane@time-travellers.org>) id 1jeDSP-0001EE-Rq for dnsop@ietf.org; Thu, 28 May 2020 08:00:09 +0000
From: Shane Kerr <shane@time-travellers.org>
To: dnsop@ietf.org
References: <CAMOjQcHAKC6ge2te8eqPz3JFmmLrpBoTSt2yKKxFXHpQEyjLqg@mail.gmail.com> <1852098.ajqZCkXiOD@linux-9daj> <e0567177-b1b4-e9e7-d2a8-faddbbc911bc@nic.cz> <2e1faccd-bdc4-b156-c460-1bada946d1c9@bellis.me.uk>
Message-ID: <fa89c1ec-7748-3952-0597-524d6bd8ce6d@time-travellers.org>
Date: Thu, 28 May 2020 10:00:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <2e1faccd-bdc4-b156-c460-1bada946d1c9@bellis.me.uk>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score-Int: -28
X-Spam-Bar: --
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/F5Dh_K_G6AkgBKj2FPK_Bc-kXbI>
Subject: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 28 May 2020 08:00:20 -0000

Ray and other DNS operations folks,

On 27/05/2020 10.30, Ray Bellis wrote:
> 
> 
> On 27/05/2020 07:33, Petr Špaček wrote:
> 
>> I would much rather spent time on
>> https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03
>>
>> That would bring benefit to broader set of clients and has advantage
>> that server does not send back data nobody asked for (thus wasting
>> resources on unnecessary work).
> 
> I'd be very happy to revive that work if there's interest.

As I have mentioned several times on microphone, I think this draft has 
huge potential, potentially cutting the number of queries handled by 
recursive resolvers almost in half - since they could ask for A and AAAA 
records in a single query.

I wonder what work is left other than implementation?

Possibly it makes sense to describe client how stub or forwarding 
resolvers may want to probe their full-service resolvers? I expect that 
normal behavior would be:

1. Send a query with the Multi-QTYPE option and see if the resolver 
supports it.
2. If it does to send single queries for address lookups instead of 
parallel AAAA/A queries.
3. Fallback to parallel AAAA/A queries as soon as they get a response 
that does not support Multiple-QTYPE.

Similar description for recursive-to-authoritative might be helpful, 
since resolvers cache information about authoritative servers. I guess 
we could expect resolvers to ask for DNSKEY and NS together when it 
makes sense, for example.

Of course, these use cases can be left as an exercise to the implementer.

--
Shane