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

Paul Wouters <paul@nohats.ca> Tue, 22 March 2016 01:14 UTC

Return-Path: <paul@nohats.ca>
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 60C9712D178 for <dnsop@ietfa.amsl.com>; Mon, 21 Mar 2016 18:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.101
X-Spam-Level:
X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no 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 bR-ca0ULZdi9 for <dnsop@ietfa.amsl.com>; Mon, 21 Mar 2016 18:14:03 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 8DAE912D168 for <dnsop@ietf.org>; Mon, 21 Mar 2016 18:14:03 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qTZTk0XvLz37S; Tue, 22 Mar 2016 02:14:02 +0100 (CET)
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id QjGjdIITTozl; Tue, 22 Mar 2016 02:14:01 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 22 Mar 2016 02:14:01 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 707206019B73; Mon, 21 Mar 2016 21:14:00 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 707206019B73
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6EE7D18D79; Mon, 21 Mar 2016 21:14:00 -0400 (EDT)
Date: Mon, 21 Mar 2016 21:14:00 -0400
From: Paul Wouters <paul@nohats.ca>
To: Marek Vavruša <mvavrusa@cloudflare.com>
In-Reply-To: <CAC=TB12Yacsj1X_4OLJmF_nPNXWFak9bEpL-R55cwusGFU1zzA@mail.gmail.com>
Message-ID: <alpine.LFD.2.20.1603212107130.16028@bofh.nohats.ca>
References: <CAC=TB13r_7TPEcUeZqH6sxqKXHRn7TgFwLwdqjBxa57aqS1MZg@mail.gmail.com> <alpine.LFD.2.20.1603212000030.16028@bofh.nohats.ca> <CAC=TB12Yacsj1X_4OLJmF_nPNXWFak9bEpL-R55cwusGFU1zzA@mail.gmail.com>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/FRVsiRMC_jqOaoWgKUR70Pg1CLs>
Cc: dnsop <dnsop@ietf.org>
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: Tue, 22 Mar 2016 01:14:04 -0000

On Mon, 21 Mar 2016, Marek Vavruša wrote:

>       What happens with the Answer Count for QTYPE=A when there are no A
>       records and only AAAA records? And can the examples also clarify this?
> 
> That's an example 5.3

The use case is, but I still have no idea what the ANCOUNT should
be. Neither the text nor the example list the ANCOUNT. I can only assume
based on the fact that the AAAA is placed in the answer section, that
you would have ANCOUNT=1. I think that is wrong. I think ANCOUNT should
be 0, and the AAAA record should be in the additional section.

> The proposal is opt-in, if the authoritative decides to throw in AAAA addresses
> then client should accept them. If it doesn't then it should requery. This is of course
> going to reduce the effectiveness in the transition period for names that have A, but don't have AAAA
> which is something I expect to change.

And I would assume QTYPE=AAAA with additional A records would become the
more common query. At least I hope we are still trying to transition to
IPv6 :)

> The rationale is not to carry unnecessary payload when most authoritatives support it, but you make a good point
> that it might be better to mandate denial of non-existence proof now, and amend the draft later.

If you want to do it your way, you need to add some signalling so the
client knows what happened and it can decide whether or not to query
again. I think it is important for the client to know whether the
answer that came back came from a server supporting this document,
as opposed to a server not supporting this document.

>       What is SNAME? Did you mean QNAME?
>  
> SNAME as in RFC1034, either QNAME or CNAME chain terminal name.

Oh thanks. a quick google didnt give me much :)

Paul