Re: [v6ops] DNS AAAA for free

Sander Steffann <sander@steffann.nl> Sat, 09 April 2016 10:55 UTC

Return-Path: <sander@steffann.nl>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF9C12D0E6; Sat, 9 Apr 2016 03:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
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 4UgKezw3pyEO; Sat, 9 Apr 2016 03:55:14 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (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 66D9D12D0BB; Sat, 9 Apr 2016 03:55:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A547838; Sat, 9 Apr 2016 12:55:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :content-type:content-type:mime-version:subject:subject:received :received; s=mail; t=1460199309; bh=4W+o1sPFvXJfBB4RHmBskjwW/V50 m/j3COY2A2a5w0E=; b=H2fvv1QO7l38sOz2kxayHoEJ7Tl+k0HW+ArU9wzyU4p6 4IaiMLHlWFmFCloNAoIsu0fslL5r+8B71gF24xLzpJdKI/y+8bdUU5JF6bL97vxf Lcr1D9r9/OOqzT/GCq8oNruR9s6MFFU6C9j7r1PDghOI3eKyUqB53AgeAun9AbQ=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YpcSBgfCY9BC; Sat, 9 Apr 2016 12:55:09 +0200 (CEST)
Received: from [IPv6:2a00:8640:1::3c8b:3db7:267:4e94] (unknown [IPv6:2a00:8640:1:0:3c8b:3db7:267:4e94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 800B337; Sat, 9 Apr 2016 12:55:06 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_E9B6D0AD-539B-46F9-92CB-268AD4A022AF"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.6b2
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
In-Reply-To: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org>
Date: Sat, 09 Apr 2016 12:55:05 +0200
Message-Id: <8BE0F8C3-D08E-487E-A12D-508C822337BB@steffann.nl>
References: <07DA627D-867F-45AD-BF43-400CB06458CC@employees.org>
To: otroan@employees.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/8EfhiwHDaZmN4zIyNYC_MUFw46o>
Cc: v6ops list <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Subject: Re: [v6ops] DNS AAAA for free
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2016 10:55:16 -0000

Hi,

> On 08 Apr 2016, at 13:27, otroan@employees.org wrote:
> 
> Here is an interesting draft being presented in dnsop today.
> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/?include_text=1
> 
> The proposal is to allow AAAA records in response to A queries.

One question: if clients send requests for both A and AAAA records simultaneously, how will including the AAAA answer in the A request help? The client will just get the AAAA answer twice: once on the A request and once on the AAAA request. If lookups were serialised and the A request/response was completed before starting the AAAA request it would make the second request unnecessary, but that's not what I see in practice...

It looks like good intentions, I'm just trying to figure out how this would work in practice :)

Cheers!
Sander