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/