Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
"Peter van Dijk" <peter.van.dijk@powerdns.com> Mon, 10 April 2017 08:34 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 A7698126DCA for <dnsop@ietfa.amsl.com>; Mon, 10 Apr 2017 01:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 7TVWO5NFSi_A for <dnsop@ietfa.amsl.com>; Mon, 10 Apr 2017 01:34:26 -0700 (PDT)
Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA30120454 for <dnsop@ietf.org>; Mon, 10 Apr 2017 01:34:26 -0700 (PDT)
Received: from [192.168.137.1] (unknown [IPv6:2001:610:666:0:4121:72dd:65d3:c56d]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id D98E5C5C23; Mon, 10 Apr 2017 10:34:23 +0200 (CEST)
From: Peter van Dijk <peter.van.dijk@powerdns.com>
To: dnsop <dnsop@ietf.org>
Date: Mon, 10 Apr 2017 10:34:23 +0200
Message-ID: <E47ED09D-CA41-4E38-AB9D-4D3A521E6F42@powerdns.com>
In-Reply-To: <CAC94RYaqTo0rDFiUKV3GUMhoSnGbBJCfc3oXWzS630QuJwR8Lg@mail.gmail.com>
References: <20170407181139.GB66383@isc.org> <CAC94RYaC4QfOwf-_3L6sb0roqjpNPKs78S=yVtwOMzLFCbJbxw@mail.gmail.com> <C420946D-0F31-4D32-A945-82B6E78B9133@powerdns.com> <CAC94RYaqTo0rDFiUKV3GUMhoSnGbBJCfc3oXWzS630QuJwR8Lg@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/PduEQsSStSQZ5a9ik8gRz6p9f3A>
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, 10 Apr 2017 08:34:29 -0000
On 10 Apr 2017, at 1:04, Richard Gibson wrote: > On Sun, Apr 9, 2017 at 3:56 PM, Peter van Dijk > <peter.van.dijk@powerdns.com> > wrote: > >>> This section calls for limiting the TTL of cached address records to >>> the >>> lesser of the ANAME TTL and the TTL of the retrieved address >>> records, but >>> section 3 requires servers to follow chained responses. Are the TTLs >>> of >>> intermediate records in a chain supposed to be ignored? >> > What was the response on this point? Oh, right. I suppose the right answer would be to take the lowest of all involved TTLs. > Right; I definitely think there should be text explicitly defining > behavior > for timeouts, nonzero RCODEs, and bogus responses received when > looking up > ANAME targets. Section 4 covers part of it (for recursive servers > only), > but doesn't define how to determine when "resolution fails" or what to > do > when not opting to use the accompanying records as a fallback, and > there is > no guidance at all for authoritative servers. Agreed. > *Section 3.2* >>> >>> The wording of this section could use some improvement. It seems to >>> prohibit secondary servers from resolving ANAME targets when they >>> are >>> present at the same domain as address types... do I understand >>> correctly? >>> >> >> Yes, that is correct. We went through a few iterations and thought >> exercises and this seemed like the optimal behaviour. > > > Dyn went another way with our ALIAS functionality, reserving > same-domain > address record sets for fallback data to be used whenever target > resolution > doesn't yield records of the appropriate type (including, perhaps > controversially, NXDOMAIN and NODATA empty responses). Assuming a > secondary > server predating ANAME, the Dyn behavior would be slightly better when > the > primary server is ignorant of that gap (i.e., the secondary would > always > serve fallback data) and identical behavior when it is not (i.e., the > authoritative would pre-expand as the draft specifies in Section 5). > It > also provides support for multi-type host names with single-type > targets, > e.g. static AAAA records sharing a domain with an ALIAS targeting a > name > providing only A records. Where it really shines, though, is in > handling > error cases like those discussed above—it was very important to our > customers that they could prevent us from ever issuing cacheable > negative > responses. What thought exercises took you in this direction? Working back from the premise that there -will- be ANAME unaware secondaries, we allow primaries to do the ANAME expansion during outgoing AXFR (or on load, but in any case the secondary gets actual (signed!) A/AAAA records). Thus, such a secondary will simply serve the A/AAAA. To keep things simple, we decided that an ANAME aware auth will do the same, so behaviour is consistent. The alternative, of defining those records as fallback, means that ANAME aware slaves that -do- receive a pre-expanded A/AAAA set, need configuration knobs to figure out if they should look up the ANAME target or not. We could automate this to a limit - say, if you are a slave, you understand ANAME, and you do not have the private key for the zone, then obviously you have to use what you find in the zone. However, it was my feeling that this would yield more complexity than we want. Anyway, I will ponder your use case. As for ‘AAAA from config, A from ANAME’, we’ve been discussing allowing multiple ANAMEs at a node, and then you could do something like this: www.example.com. ANAME www-v6.example.com. www.example.com. ANAME example.com.my-cdn.com www-v6.example.com. AAAA 2001:db8::80 >>> Are such address records still subject to TTL decrementing >>> (presumably >>> starting at the time of zone transfer)? And when only a single >>> address >>> type >>> is present (e.g., just ANAME and A), does that still prevent >>> resolution of >>> the ANAME target for the other type? >>> >> >> (1) Yes, they are still subject to TTL decrementing, but if the slave >> is >> not ANAME-aware, no decrementing will happen and the draft allows >> this, if >> we wrote it all down correctly. >> (2) Yes, when any address records are present, the ANAME is deemed to >> have >> already been expanded. If A is there and no AAAA, then this means >> that >> there is in fact no AAAA to be had. > > I understand the motivation, but there's an interesting wrinkle with > respect to forward compatibility... what happens when a new address > type is > added to the DNS? The assumption that pre-expansion of any address > type > implies pre-expansion of all address types seems like it could lead to > some > dramatic changes in behavior as primary servers, secondary servers, > resolvers, and targeted zones become aware of the new type in a > nonuniform > fashion. Has any consideration been given to that concern? Not by me so far, I’ll readily admit. Will ponder. > On a related note, should recursive resolvers query for ANAME targets > even > when they *don't* correspond to A or AAAA QTYPEs? Probably not. >>> It is also mute on the use of DNSSEC for resolving ANAME target >>> records, >>> but that should probably be covered somewhere. >> >> This is an interesting topic actually. There are existing deployments >> of >> PowerDNS ALIAS (which of course is quite similar to ANAME) that use >> it >> instead of ‘CNAME to unsigned’ so they can sign the target >> addresses (that >> they get via a non-DNSSEC but still secure path). This draft should >> also >> allow that. If you have suggestions for a section on ANAME target >> resolving >> and DNSSEC, please let us know. > > Addressing the above points to explicitly define behavior for bogus > responses will cover the functional requirements, so this will likely > take > the form of MAY or SHOULD guidance for using DNSSEC when resolving > ANAME > targets. Indeed. 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… 神明達哉