Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

Florian Weimer <fweimer@redhat.com> Wed, 23 March 2016 19:14 UTC

Return-Path: <fweimer@redhat.com>
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 9D0B812D834 for <dnsop@ietfa.amsl.com>; Wed, 23 Mar 2016 12:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.932
X-Spam-Level:
X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 F2wmdnFr-IWS for <dnsop@ietfa.amsl.com>; Wed, 23 Mar 2016 12:14:36 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F106012D758 for <dnsop@ietf.org>; Wed, 23 Mar 2016 12:14:35 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id AE36EC0467EC; Wed, 23 Mar 2016 19:14:35 +0000 (UTC)
Received: from oldenburg.str.redhat.com (ovpn-204-38.brq.redhat.com [10.40.204.38]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2NJEX16023507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2016 15:14:35 -0400
To: Marek Vavruša <mvavrusa@cloudflare.com>, dnsop@ietf.org
References: <CAC=TB13r_7TPEcUeZqH6sxqKXHRn7TgFwLwdqjBxa57aqS1MZg@mail.gmail.com>
From: Florian Weimer <fweimer@redhat.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56F2EB19.5040304@redhat.com>
Date: Wed, 23 Mar 2016 20:14:33 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CAC=TB13r_7TPEcUeZqH6sxqKXHRn7TgFwLwdqjBxa57aqS1MZg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/D5Ioev018pGI6HA0FgSNWlO2M5w>
Subject: Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 23 Mar 2016 19:14:37 -0000

On 03/22/2016 12:45 AM, Marek Vavruša wrote:

> there was an interest in reducing latency for address record lookups.
> Me and Olafur wrote a draft on adding AAAA records to A answers and
> treating them as authoritative. This fixes latency issues with NS
> A/AAAA discovery in resolvers and improves caching for clients (AAAA
> already cached by the time client comes asking for it).
> 
> Comments, feedback and snarky remarks would be great!
> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/

The glibc stub resolver already implements this draft in its response
processing by accident.  I was planning to fix that.

I don't see how this proposal reduces latency or server load.  We still
have to do dual A/AAAA queries.  In the majority of cases, there is no
AAAA record, so we have to wait for the second reply to arrive.

We could reduce server load by sending the AAAA query only after the A
response, but we'd have to send it in most cases because we cannot take
absence of an AAAA RRset as proof of its non-existence.

On the server side, doing AAAA lookups for all incoming A queries, on
top of A lookups, isn't free (although it should be fairly cheap because
the server at least knows where to send the AAAA query).

Florian