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/
- 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… 神明達哉