Re: [DNSOP] why no QDCOUNT>1

Mark Andrews <marka@isc.org> Sun, 21 July 2019 17:49 UTC

Return-Path: <marka@isc.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 091881200DE for <dnsop@ietfa.amsl.com>; Sun, 21 Jul 2019 10:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 zHBUkHAol4lf for <dnsop@ietfa.amsl.com>; Sun, 21 Jul 2019 10:49:44 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 A254F120154 for <dnsop@ietf.org>; Sun, 21 Jul 2019 10:49:44 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 81F583AB002; Sun, 21 Jul 2019 17:49:44 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 77F9F160045; Sun, 21 Jul 2019 17:49:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 65BCE160074; Sun, 21 Jul 2019 17:49:44 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mR9PGToBUUHU; Sun, 21 Jul 2019 17:49:44 +0000 (UTC)
Received: from [IPv6:2001:67c:370:1998:31c5:de71:5a6f:1124] (nat64-90.meeting.ietf.org [31.130.238.144]) by zmx1.isc.org (Postfix) with ESMTPSA id 13BC5160045; Sun, 21 Jul 2019 17:49:44 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <2347375.L6ogdVMl2V@linux-9daj>
Date: Mon, 22 Jul 2019 03:49:39 +1000
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DBA70901-FC44-4F59-BDFE-50E3414D7D7D@isc.org>
References: <2347375.L6ogdVMl2V@linux-9daj>
To: Paul Vixie <paul@redbarn.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Wce5NhW4PwcUT1DQr9RwnxOW_U4>
Subject: Re: [DNSOP] why no QDCOUNT>1
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: Sun, 21 Jul 2019 17:49:47 -0000

Also with IQUERY (obsolete) you could get multiple QNAMEs in the response.

> On 22 Jul 2019, at 3:29 am, Paul Vixie <paul@redbarn.org> wrote:
> 
> someone here recently asked why multiple questions are allowed by the DNS 
> header format but not implemented. this was in the context of performance 
> comparisons between tcp/53 and udp/53, vs. DoT, vs. DoH.
> 
> the reason it's not implemented is that there's only one RCODE in the 
> response, so if one question results in RCODE=0 but another is RCODE=3, there 
> is no way to signal this. there's a similar issue with AA. and if there's a 
> delegation response for one but not the other, and one is the parent of the 
> other, ambiguity runs rampant.
> 
> the reason this hasn't been repaired via a massive protocol overhaul is that 
> it's a trivial matter to pipeline multiple questions, either on udp/53, DoT, 
> or even DoH. the extra DNS headers cost ten (10) octets per question, which is 
> insignificant.
> 
> here's some undocumented advice: don't initiate transactions via UDP/53 back 
> to back, because this microburst will probably overflow a queue somewhere. if 
> pipelining, either use DoT, or make sure there's a small delay between 
> subsequent UDP/53 transactions. 1.5 milliseconds is enough.
> 
> -- 
> Paul
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org