Re: [DNSOP] New draft for ALIAS/ANAME type

Pieter Lexis <pieter.lexis@powerdns.com> Wed, 29 March 2017 16:14 UTC

Return-Path: <pieter.lexis@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 8E9DC12778E for <dnsop@ietfa.amsl.com>; Wed, 29 Mar 2017 09:14:42 -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 q5nHImMIBnFR for <dnsop@ietfa.amsl.com>; Wed, 29 Mar 2017 09:14:40 -0700 (PDT)
Received: from mango.plexis.eu (mango.plexis.eu [IPv6:2a01:7c8:aaae:3e2::1]) (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 B8FB8129519 for <dnsop@ietf.org>; Wed, 29 Mar 2017 09:14:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mango.plexis.eu (Postfix) with ESMTP id 9B79E589 for <dnsop@ietf.org>; Wed, 29 Mar 2017 18:14:28 +0200 (CEST)
Received: from mango.plexis.eu ([127.0.0.1]) by localhost (mango.plexis.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze547YfXgGmI for <dnsop@ietf.org>; Wed, 29 Mar 2017 18:14:27 +0200 (CEST)
Received: from ananas.home.plexis.eu (unknown [82.170.91.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mango.plexis.eu (Postfix) with ESMTPSA id E36FF7D for <dnsop@ietf.org>; Wed, 29 Mar 2017 18:14:26 +0200 (CEST)
Date: Wed, 29 Mar 2017 18:14:25 +0200
From: Pieter Lexis <pieter.lexis@powerdns.com>
To: dnsop@ietf.org
Message-ID: <20170329181425.3d621c30@ananas.home.plexis.eu>
In-Reply-To: <CAOZSDgCw4HA05uE0d73cru3EfuOzAJ3Pdg2SsYZmY3f49+vc2w@mail.gmail.com>
References: <CAOZSDgCw4HA05uE0d73cru3EfuOzAJ3Pdg2SsYZmY3f49+vc2w@mail.gmail.com>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-unknown-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cbL1csCO3AkAJwB58LZyj8bBqTM>
Subject: Re: [DNSOP] New draft for ALIAS/ANAME type
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: Wed, 29 Mar 2017 16:14:43 -0000

Hello Anthony,

On Wed, 29 Mar 2017 08:51:50 -0500
Anthony Eden <anthony.eden@dnsimple.com> wrote:

> https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/
> 
> This draft describes the ALIAS/ANAME record (aka CNAME-flattening)
> that numerous vendors and DNS providers are now supporting in
> proprietary fashions. I hope that this draft will eventually lead to a
> good mechanism for interop of ALIAS/ANAME records.

First off, thank you for this. I would love to hear from current implementors of ALIAS/ANAME/CNAME-flattening what their ideas/critisisms are.

This said, I have several comments after a first quick read of the document.

There is no mention of the fact that ALIAS is mostly meant for zone apexes where other records MUST be present and a CNAME cannot exist. CNAMEs would cover non-apex usecases for ALIAS.

I miss guidance what should happen when an ALIAS record is queried directly (would it be returned, should it be refused, should it be an empty response?).

I miss words on the interaction between ALIAS records and other (mostly A and AAAA) records on the same node.

Section 3.1

"The server will respond with one or more A records", I fail to see why this cannot be zero or more. Am ALIAS target without A or AAAA records should yield an empty response from the authoritative server.

"If the recursive query returns an NXDOMAIN response, then the authoritative name server MUST return an NXDOMAIN response as well.". If any other records exist (which is always the case for the apex), or if there are labels underneath the ALIAS'es name, the authoritative server cannot send out NXDOMAIN.

Section 3.3

This section has 2 similar paragraphs, one with should and the other with MUST.

Asking directly for a CNAME for a node that only has an ALIAS record should yield a response indicating that RRType does not exist at that node.

Again, thank you for starting this draft. I support adoption of this draft in the dnsop WG to facilitate better interop between ALIAS/ANAME/CNAME-flattening implementors.

Best regards,

Pieter

-- 
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com