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: 神明達哉 <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
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Evan Hunt
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Paul Wouters
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Richard Gibson
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… John Levine
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Paul Wouters
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Richard Gibson
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Peter van Dijk
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Peter van Dijk
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Ray Bellis
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Peter van Dijk
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Ray Bellis
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Florian Weimer
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Jan Včelák
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… John Levine
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Evan Hunt
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Peter van Dijk
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Tony Finch
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Tony Finch
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Tony Finch
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Paul Wouters
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Florian Weimer
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Florian Weimer
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Tony Finch
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Paul Wouters
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Florian Weimer
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Florian Weimer
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Tony Finch
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Evan Hunt
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Tony Finch
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Mark Andrews
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Florian Weimer
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Evan Hunt
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Florian Weimer
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Evan Hunt
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Tony Finch
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Florian Weimer
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Tony Finch
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Peter van Dijk
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Peter van Dijk
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Peter van Dijk
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… John Levine
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… John Levine
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Tony Finch
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Peter van Dijk
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Paul Wouters
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Evan Hunt
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Florian Weimer
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… 神明達哉
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Paul Wouters
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Evan Hunt
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Paul Wouters
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Tony Finch
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… 神明達哉
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Florian Weimer
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Peter van Dijk
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Lanlan Pan
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Peter van Dijk
- [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-0… Evan Hunt
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Job Snijders
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Peter van Dijk
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… Peter van Dijk
- Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-ana… 神明達哉