Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

"Peter van Dijk" <peter.van.dijk@powerdns.com> Mon, 03 July 2017 09:22 UTC

Return-Path: <peter.van.dijk@powerdns.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 C3FF2131545 for <dnsop@ietfa.amsl.com>; Mon, 3 Jul 2017 02:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JRhIbwRlFpUz for <dnsop@ietfa.amsl.com>; Mon, 3 Jul 2017 02:22:26 -0700 (PDT)
Received: from shannon.7bits.nl (shannon.7bits.nl [89.188.0.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69485131546 for <dnsop@ietf.org>; Mon, 3 Jul 2017 02:22:26 -0700 (PDT)
Received: from [10.242.2.15] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 26C5C1BCE3; Mon, 3 Jul 2017 11:22:21 +0200 (CEST)
From: "Peter van Dijk" <peter.van.dijk@powerdns.com>
To: dnsop <dnsop@ietf.org>
Date: Mon, 03 Jul 2017 11:23:01 +0200
Message-ID: <8FFF06E9-59D8-4033-B914-43E9C1DE16E8@powerdns.com>
In-Reply-To: <CAJE_bqd03qfTs+9gXbwJJp5TJOiJG+mUDp8CxFfwmBWRq+2aOg@mail.gmail.com>
References: <20170407181139.GB66383@isc.org> <CAJE_bqd03qfTs+9gXbwJJp5TJOiJG+mUDp8CxFfwmBWRq+2aOg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bvnkfu0QWii7GQMk-gmy_sE2CaA>
Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 03 Jul 2017 09:22:29 -0000

Hello Jinmei,

apologies for the delay. Due to the length of your email I flagged it 
for later reading and then I got distracted by other things.


On 13 Apr 2017, at 22:27, 神明達哉 wrote:

> Overall I agree this is worth trying to achieve.  There is a clear
> need for the ability of defining an alias at a zone apex, and it will
> be nicer if we provide a standard-compliant and interoperable way for
> that.  I also agree that a long-term goal (hope) should deploy it in
> the resolver side even if it will take quite long (if not fail), so
> that authoritative server implementations can be kept lightweight and
> simple.

I do not envision a future in which all resolvers support it, so I fear 
auths that want it will need to do it, forever.

> I have one high-level concern in terms of the merit of providing a
> standard/interoperable version of 'alias'.  As already noted in the
> draft there are currently several proprietary mechanisms of 'alias',
> mainly to allow an alias at a zone apex.  In order for the standard
> version to be successful, it will have to be compatible with these
> existing ones as much as possible and as long as it doesn't break
> other DNS standards.

I’d like to agree, but if the existing implementations are not all the 
same, this is unfeasible.

> In that sense I see some disparity with the
> ALIAS record of Amazon Route53, one of the earliest (and probably
> largest) players of the idea:
> - Supporting other types of records than AAAA and A
> - Allowing different target names for different types

As I replied to John Levine, we do not feel this is prudent at this 
stage. Operational experience with ANAME, once standardised and 
deployed, would be a good basis for another draft that is more 
extensive, like having a type bitmap - this would support both these 
features.

> I don't know how critical these are for existing R53 ALIAS users, but
> depending on that ANAME may not be able to be successful in practice.

Outside of R53, most implementations appear to be similar. That’s a 
pretty decent installed base that we can try to convert!

> I also wonder whether it's okay to allow 'AAAA or A' and ANAME to
> coexist for the same owner name.  Shouldn't it be prohibited similar
> to that CNAME and other types can't coexist?

If A and/or AAAA coexist with ANAME, no ANAME expansion happens, as this 
is deemed to have already happened during provisioning or slaving etc.

> Some specific comments on the draft text follow:
>
> - Section 3
>
>    If the original query is for type A, and an RRset of type A exists 
> at
>    the final ANAME <target>, then that A RRset (with <owner> changed 
> to
>    match that of the ANAME RR), MUST be appended to the answer section
>    after the ANAME RRset.
>
>   What if the target name of ANAME does not exist (NXDOMAIN)?
>   Returning NXDOMAIN is quite likely to be a bad choice, since the
>   owner name of the query actually does exist.  It will be certainly
>   problematic if it's a zone apex.  So should it be translated into
>   NOERROR+NODATA?  Or something else?  Also, if the zone is signed,
>   what kind of proof should be returned?

The draft does not usefully cover this right now. Indeed returning 
NXDOMAIN would be wrong, so a NODATA-ish response would be right. The 
proof would consist of a signed NSEC(3) with a type bitmap containing 
ANAME, and if at the apex, also SOA, NS, perhaps MX, etc. A/AAAA would 
not be in the type bitmap.

> - Section 3.1
>
>    Address records cached locally MUST have a limited TTL.  The 
> initial
>    TTL for locally-cached address records MUST be set to the lesser of
>    the ANAME TTL and the TTL of the address records retrieved from the
>    ANAME <target>.  The local TTL MUST count down, just as it would in 
> a
>    conventional resolver cache.[...]
>
>   Should the local TTL count down, even if the initial value is from
>   the ANAME TTL?  I suspect that's not the intent, and if I'm correct
>   I think the current text is confusing and should clarify it.

Noted.

> - Section 3.2
>
>    If the zone is configured with an A or AAAA RRset at the same DNS
>    node as ANAME, then the ANAME is considered to have been 
> pre-expanded
>    for zone transfer purposes.  When a zone is being transferred to a
>    secondary server, if any address record already exists at the same
>    node as an ANAME RR, then the ANAME RR MUST NOT be further expanded
>    by the authoritative server.
>
>   (I have a more fundamental concern about the coexistence as stated
>   above, but ignoring it in this context) I'm afraid this text talks
>   about something not explained before this point or not even
>   explained clearly anywhere in the draft.  I guess the "pre-expand"
>   means the following behavior described in section 3.3, but not
>   necessarily with RRSIGs:
>
>    Implementers MAY allow address records associated with the ANAME to
>    be populated and signed by the primary server, then sent along with
>    their RRSIGs to secondaries via zone transfer.
>
>   If my understanding is correct, the concept of population/pre-expand
>   behavior for zone transfer should be explicitly introduced before
>   the discussion in Section 3.2.

Also noted.

Thank you for your extensive review!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/