IETF Logo Mail Archive

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

Tony Finch <dot@dotat.at> Mon, 02 July 2018 09:53 UTC

Return-Path: <dot@dotat.at>
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 86F7F130FD4 for <dnsop@ietfa.amsl.com>; Mon, 2 Jul 2018 02:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 vcRvHfh3g7s1 for <dnsop@ietfa.amsl.com>; Mon, 2 Jul 2018 02:53:41 -0700 (PDT)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 33D78130FCF for <dnsop@ietf.org>; Mon, 2 Jul 2018 02:53:41 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:35728) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fZvWY-000j4n-2r (Exim 4.91) (return-path <dot@dotat.at>); Mon, 02 Jul 2018 10:53:34 +0100
Date: Mon, 02 Jul 2018 10:53:34 +0100
From: Tony Finch <dot@dotat.at>
To: Paul Vixie <paul@redbarn.org>
cc: Michael Sheldon <msheldon@godaddy.com>, dnsop@ietf.org
In-Reply-To: <5B366088.6040201@redbarn.org>
Message-ID: <alpine.DEB.2.11.1807021034570.916@grey.csi.cam.ac.uk>
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>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qocbD60Dh5y9h7w1BR-HHR9_58A>
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: Mon, 02 Jul 2018 09:53:50 -0000

Paul Vixie <paul@redbarn.org> wrote:
>
> for QTYPE=A, add AAAA as a desired additional data type.
>
> for QTYPE=AAAA, add A as a desired additional data type.

How does the server signal to a client that made an A query that there
are no AAAA records so the client does not need to make a followup AAAA
query? My answer: use DNSSEC :-)

What are the incentives to implement this? The current state of the art is
happy eyeballs version 2, which specifies concurrent AAAA and A queries;
the client has already made both queries before it finds out it only
needed to make one. I'm not sure how a client could know in advance that
it only needs to make one query.

I think there would be some benefit to this between auth and recursive,
provided the recursive server eagerly validates additional records and
promotes them to the authoritative answer level of RFC 2181 trust.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
partnership and community in all areas of life

v2.23.0 | Report a Bug | By Email