Re: [DNSOP] Minimum viable ANAME

Paul Vixie <paul@redbarn.org> Sun, 04 November 2018 08:01 UTC

Return-Path: <paul@redbarn.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 073E1127133 for <dnsop@ietfa.amsl.com>; Sun, 4 Nov 2018 01:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 e8aLDbScFiwk for <dnsop@ietfa.amsl.com>; Sun, 4 Nov 2018 01:01:30 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E647D130E08 for <dnsop@ietf.org>; Sun, 4 Nov 2018 01:01:30 -0700 (PDT)
Received: from [10.0.29.176] (unknown [12.169.103.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 88EED892C6; Sun, 4 Nov 2018 08:01:29 +0000 (UTC)
Message-ID: <5BDEA757.7040208@redbarn.org>
Date: Sun, 04 Nov 2018 01:01:27 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ray Bellis <ray@bellis.me.uk>
CC: dnsop@ietf.org
References: <20180919201401.8E0C220051382A@ary.qy> <08C8A740-D09B-4577-AF2A-79225EDB526B@dotat.at> <20180920061343.GA754@jurassic> <E944887D-51ED-41A0-AC5A-3076743620D8@isoc.org> <acef1f69-8e4f-52cc-dca5-3ada9446e0ee@bellis.me.uk> <5BDE34E3.5030602@redbarn.org> <a149f8ba-7350-327f-ab13-8c6eeb76f2f5@bellis.me.uk> <a85e1f2e-4feb-3f9e-fb8c-62214de98fd2@bellis.me.uk>
In-Reply-To: <a85e1f2e-4feb-3f9e-fb8c-62214de98fd2@bellis.me.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Fk0TG6JsH3SRfejOCgzcW5O7GNY>
Subject: Re: [DNSOP] Minimum viable ANAME
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, 04 Nov 2018 08:01:32 -0000


Ray Bellis wrote:
>
>
> On 04/11/2018 08:05, Ray Bellis wrote:
>
>> AFAIK, BIND does not currently do this.  That said, MarkA has a patch
>> that supports it, so we do know it's possible.
>
> Correction - BIND *does* do this, but only for address records that are
> already in the cache. If the AAAA for the target is in the cache, but
> the A record isn't, that's all you'll get.

that's all we need. it's all we do for MX and NS additional data, too.

> Mark's patch forces BIND to pre-fill the cache with the A and AAAA
> records for the SRV target before replying.

that would be a mistake. we are hitting for average here not power -- 
the behaviour to optimize for is whatever's most common. if the SRV is 
used, the AAAA or A RRsets will be fetched, and thus cached. if the SRV 
is only used once, that caching effort will be wasted. if the SRV is 
used many times, then the dominant use case will be that the additional 
data is found in cache because the client caused this to be so.

-- 
P Vixie