Re: [DNSOP] Creating a query/record for A and AAAA

Mark Andrews <marka@isc.org> Sat, 30 June 2018 01:26 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 4D613130E37 for <dnsop@ietfa.amsl.com>; Fri, 29 Jun 2018 18:26:59 -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_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 m6s_Fc6FmUcH for <dnsop@ietfa.amsl.com>; Fri, 29 Jun 2018 18:26:57 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 A31BB128CF3 for <dnsop@ietf.org>; Fri, 29 Jun 2018 18:26:57 -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 817F43AB06B; Sat, 30 Jun 2018 01:26:57 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6E959160064; Sat, 30 Jun 2018 01:26:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 55F9F16007E; Sat, 30 Jun 2018 01:26:57 +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 SpAM1Q3wB7wQ; Sat, 30 Jun 2018 01:26:57 +0000 (UTC)
Received: from [172.30.42.90] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 7A4D0160064; Sat, 30 Jun 2018 01:26:56 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <5B36629B.40703@redbarn.org>
Date: Sat, 30 Jun 2018 11:26:54 +1000
Cc: Michael Sheldon <msheldon@godaddy.com>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B56C70A-2FBB-44A4-9285-11CACA9CB5C3@isc.org>
References: <b73f3dc7-b378-d5d8-c7a2-42bc4326fbae@nic.cz> <alpine.DEB.2.11.1806191428250.916@grey.csi.cam.ac.uk> <691FC45D-E5B6-4131-95BF-878520351F3A@gmail.com> <bf0ba568-1a18-f8cf-c1a0-3f547d642a78@bellis.me.uk> <0438207E-A4C2-434D-9507-9D9F54765CFB@puck.nether.net> <alpine.DEB.2.11.1806191649350.916@grey.csi.cam.ac.uk> <9a0d1bae-dc58-99b5-40d1-caa7737dbfb1@bellis.me.uk> <1B7B2BB4-F0AE-4188-B89B-DF032BE7A237@automagic.org> <CAHw9_iKWhRjK6yzSSWVsCBqjdVfTnzVkUh8PMYC5nwQUb_=yvw@mail.gmail.com> <20180622191334.GA15349@jurassic> <CAHw9_iLN0w=k0hZLsOCJXnA58afACuzxgXdYPPEn_HShm6Q4aw@mail.gmail.com> <43D87A94-E356-4B82-BB0B-C40701E981FB@dotat.at> <E2BC75AC-3E1D-43E0-AE1E-89D78E11CEB1@isc.org> <38513A04-FBB7-4579-90AE-2B5359D94907@godaddy.com> <5B366088.6040201@redbarn.org> <5315076E-4022-4CE2-B6C7-BD2BBE381BE5@godaddy.com> <5B36629B.40703@redbarn.org>
To: Paul Vixie <paul@redbarn.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4hc8EAENVPmPHQzO0jhRmYlS1wU>
Subject: Re: [DNSOP] Creating a query/record for A and AAAA
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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: Sat, 30 Jun 2018 01:27:00 -0000

> On 30 Jun 2018, at 2:47 am, Paul Vixie <paul@redbarn.org>; wrote:
> 
> 
> 
> Michael Sheldon wrote:
>> I kind of agree it's the long way around. The problem it gets around
>> is recursives not returning Additional, which has been noted as being
>> very common.
> 
> recursives could (as could authoritatives) do this today if they wanted to.
> if you think they will only do it if there's a document telling them to,
> then by all means write that document. but just describe what they can
> already do, don't define new protocol elements.

It’s not so much that they don’t return the records.  It’s that they
don’t have the records in the cache to start with so they are not returned.
This is especially true when the content is hosted by a different organisation.

It is possible to fetch all the records before returning if you want to though some
sort of signal from the client that they will use the data would be useful.  I’ve
just been working on code to do just that for BIND for SRV as a proof of concept.
It is also possible to prefetch missing additional records.  Both of these things
are being done in this MR though I might increase the number of prefetch slots used.

https://gitlab.isc.org/isc-projects/bind9/merge_requests/449

> -- 
> P Vixie
> 
> _______________________________________________
> 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