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

"Peter van Dijk" <peter.van.dijk@powerdns.com> Sun, 09 April 2017 19:56 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 F24B31276AF for <dnsop@ietfa.amsl.com>; Sun, 9 Apr 2017 12:56:22 -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 TJ5AQjz9uAPk for <dnsop@ietfa.amsl.com>; Sun, 9 Apr 2017 12:56:21 -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 99B0D128656 for <dnsop@ietf.org>; Sun, 9 Apr 2017 12:56:19 -0700 (PDT)
Received: from [192.168.137.1] (unknown [IPv6:2001:610:666:0:f021:3c9d:c1a0:9cfd]) (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 263B3C1B96; Sun, 9 Apr 2017 21:56:16 +0200 (CEST)
From: "Peter van Dijk" <peter.van.dijk@powerdns.com>
To: dnsop <dnsop@ietf.org>
Date: Sun, 09 Apr 2017 21:56:27 +0200
Message-ID: <C420946D-0F31-4D32-A945-82B6E78B9133@powerdns.com>
In-Reply-To: <CAC94RYaC4QfOwf-_3L6sb0roqjpNPKs78S=yVtwOMzLFCbJbxw@mail.gmail.com>
References: <20170407181139.GB66383@isc.org> <CAC94RYaC4QfOwf-_3L6sb0roqjpNPKs78S=yVtwOMzLFCbJbxw@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/lYrimaORIVQy_XAZ8HDouvkLfSg>
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: Sun, 09 Apr 2017 19:56:23 -0000

Hello Richard,

On 9 Apr 2017, at 3:38, Richard Gibson wrote:

> I'm happy to see progress being made on this front. Some comments:

Thank you for taking the time for this.

> *Section 3.1*
>
> 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 is the expected behavior when the target record set is empty, or
> bogus, or when resolution fails?

Empty becomes empty. The common case will be ‘the ANAME target only 
has A, no AAAA’ which means the AAAA lookup encounters a valid ‘no 
data’.

If resolution fails (i.e. runs into an actual SERVFAIL-like error 
condition, including ‘bogus’), we should also SERVFAIL. If the draft 
is unclear on this we should definitely fix that.

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

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

> *Section 3.3*
>
> Although labeled "DNSSEC signing", this section also contains more 
> general
> specification (e.g., "the master server MUST respect the TTLs of the
> address records" and "TTLs [of address records in a secondary server] 
> will
> count down").

Then the section is misnamed or those specifications should be moved. I 
will look at that.

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

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/