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

神明達哉 <jinmei@wide.ad.jp> Thu, 13 April 2017 20:27 UTC

Return-Path: <jinmei.tatuya@gmail.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 08E0412956C for <dnsop@ietfa.amsl.com>; Thu, 13 Apr 2017 13:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 8kNB84-z3xuF for <dnsop@ietfa.amsl.com>; Thu, 13 Apr 2017 13:27:16 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E244127076 for <dnsop@ietf.org>; Thu, 13 Apr 2017 13:27:15 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id m36so54578255qtb.0 for <dnsop@ietf.org>; Thu, 13 Apr 2017 13:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lWXnXZ0Wq88D4OBriVLhLQb4m2OCgpE9wjFhk5jzyfM=; b=l5UCYQ0yep8FmNe0QAtm+NmgVSfNUjht2jFYOo6etJ/K3ig7zqvGQuiHe1zB11qmZi HvtY6MJ7JYMpt57FvOE4uy46uHGA9PN5Pf3Baw1BuLZmSVazXtmD+EC7NwwWBoUrWpU4 i20Tnx32cWFbdkoJf44M0WmhL1IAlbP1VBkyIZYXqQYdD78vCIBpWK3EVkSlQrsKGzAA oqUmN8LjwxT4FOby9DucBhvBzArMSTtLrPdIbPfapDZHR6TG3Oc3fdLCKG/XjlL/Iuz+ 94tOMZCCIjsok0a/2aMevb0MvoLxazHRXPN2lwE2nIWPJx2qlXC4hrsTP1x6slrN8t5C IdaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lWXnXZ0Wq88D4OBriVLhLQb4m2OCgpE9wjFhk5jzyfM=; b=SS5IXqBRbqht6KyRgQ4WdkuRcRJArMbG/f7FdynZtA6PYdJ70mv3zzSPsnRJzm1xED wnD59URElNsp0/hsiSBEXSOCCl4Ke9M4u80cqOsC/yTaw+ypVNM3EtO7XGdGBHA2Nk4u Dsx45GZrxmVzCtwHyjjwUxDn2dONBa5P/ws2C5VohPG7sO+5prbUXsKhJGBzlJ6Sh56l SN+i/+J59Ug1z0sA46OAoaLpDzkMUWlzHEDbW8ungej9Hw4Z+h4WQrmk0jAkU8svTwNC o6a8zYwYRD2G2XTK8VbzSdfDKu3E6bd/cTLYkUaZaGOcZImCBbB1HFHqhL1+1UCQJ1gs j8XQ==
X-Gm-Message-State: AN3rC/7Hafj85djk6Y8xlcj1H/HdMAl4okFzx8yC8eS8NrKpqi+tEtLo KgAG0NyZhRcSx5fW9+qyFOKAS6Mxxg==
X-Received: by 10.200.42.151 with SMTP id b23mr4142727qta.163.1492115234453; Thu, 13 Apr 2017 13:27:14 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.60.208 with HTTP; Thu, 13 Apr 2017 13:27:13 -0700 (PDT)
In-Reply-To: <20170407181139.GB66383@isc.org>
References: <20170407181139.GB66383@isc.org>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Thu, 13 Apr 2017 13:27:13 -0700
X-Google-Sender-Auth: qp5cNVHMPPJX1hyx1w13jgneFzM
Message-ID: <CAJE_bqd03qfTs+9gXbwJJp5TJOiJG+mUDp8CxFfwmBWRq+2aOg@mail.gmail.com>
To: Evan Hunt <each@isc.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4WSrIgDEWDHOK-jTrh3ETS0qNlU>
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: Thu, 13 Apr 2017 20:27:17 -0000

At Fri, 7 Apr 2017 18:11:39 +0000,
Evan Hunt <each@isc.org> wrote:

> Here's the new ANAME draft I mentioned last week.
>
> This is similar to existing non-standard approaches (ALIAS records,
> CNAME-flattening, etc) but also sends the ANAME record to the resolver so
> that, if the resolver understands the ANAME type, it can re-query for the
> answer just as it would with a CNAME.

I've read draft-hunt-dnsop-aname-00 and have some comments on it.  I'm
aware that similar comments on some points have been made in this
thread, but I'm providing my own version at the risk of repeating as I
think these are not necessarily a complete duplicate.

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 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.  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
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.

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?

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?

- 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.

- 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.

--
JINMEI, Tatuya