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

Jared Mauch <jared@puck.nether.net> Mon, 02 July 2018 13:34 UTC

Return-Path: <jared@puck.nether.net>
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 7E70A131153 for <dnsop@ietfa.amsl.com>; Mon, 2 Jul 2018 06:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 4EodyafRzNTm for <dnsop@ietfa.amsl.com>; Mon, 2 Jul 2018 06:34:43 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D8D131106 for <dnsop@ietf.org>; Mon, 2 Jul 2018 06:34:43 -0700 (PDT)
Received: from [IPv6:2603:3015:3606:cbe1:d1d0:7afa:68c:95a7] (unknown [IPv6:2603:3015:3606:cbe1:d1d0:7afa:68c:95a7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id BD2FE541282; Mon, 2 Jul 2018 09:34:39 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <5B366088.6040201@redbarn.org>
Date: Mon, 02 Jul 2018 09:34:36 -0400
Cc: Michael Sheldon <msheldon@godaddy.com>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FAA64421-42EE-49BB-A222-B9CE936B5C96@puck.nether.net>
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>
To: paul vixie <paul@redbarn.org>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jWUZtmEqvgGo-9soRWAKZvI6R-c>
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 13:34:48 -0000


> On Jun 29, 2018, at 12:38 PM, Paul Vixie <paul@redbarn.org> wrote:
> 
> 
> 
> Michael Sheldon wrote:
>> Breaking this out of the ANAME discussion, since it has wider use.
>> 
>> I've been thinking on this one. If I was to create a record, I'd set
>> aside a byte or two at the beginning to denote family, but I'm just
>> paranoid and OCD that way.
> 
> that seems like the long way around.
> 
> for QTYPE=A, add AAAA as a desired additional data type.
> 
> for QTYPE=AAAA, add A as a desired additional data type.
> 
> advantages:
> 
> no fork-lifts. incremental. opportunistic. no protocol changes. start today.
> 
> any server which does it will give better time-to-first-ad benchmarks, and will therefore outcompete any server who doesn't do it in all bakeoffs.
> 

I guess this depends on how the vendors implement the various minimal response bits.  I’ve turned this on because in ye olden days (I think it was the 2nd half of the 90s) you could poison a cache by dumping in additional data, sometimes even out of the zone additional and cause this trouble.

This is also documented as a performance gain, either due to less time packing the response or other wins.

As a longtime ANY (ab)user, I welcome an approach where we get AAAA + A at the same time.  This can be done by just returning the additional but it really depends on if the clients or stubs will use it.

- Jared