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

Anthony Eden <> Wed, 29 March 2017 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E66771296EA for <>; Wed, 29 Mar 2017 12:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q4QuPNY2mv2l for <>; Wed, 29 Mar 2017 12:27:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C629A1296DE for <>; Wed, 29 Mar 2017 12:27:47 -0700 (PDT)
Received: by with SMTP id f11so22102742qkb.0 for <>; Wed, 29 Mar 2017 12:27:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YsrNpN0kCxk38NrKKwVLJPXhbv8fu/fP1tJChdM0rFw=; b=GEbbcQL068mL9joe4jMewVmQPFENYfGPzVCeZbGq7WqiuIXUJEAXdQEnK7tGeK0plp 8dvAzHqv/srEjnVGHf3vO139034xaLMNIuKOKPAmkgCeWdoLARP5H91GsNdah5HiJzuF nbfKS8yeMF+QKx9sE1JO1PeERlaEnrrqlnlxg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YsrNpN0kCxk38NrKKwVLJPXhbv8fu/fP1tJChdM0rFw=; b=mocCAisGpvdZX7AJL+4qQEz6oFJkjpBMDufnhyOzgGmT6rJZVScdkN+lK8QrNpTdid 7GPdsHo/cBHa9TWbJPRFOvGm4hez5GBy0AJAXmcz0oV9CFE6cxwffBxAm3+5bZxAdVgq rt+hsr9+PFic4Ns+SdCGLZDmNtN21ThJTsnAjaFmtQuxNO+RX9CJA6WgM0d6kiSbKrky a0YzTJvYZyK9o1F/WvE0PGan7Di9I4cIzYvEy1sKl69NsfUNoNAcjs8o0KDxvXtZBpFS ThrcL0YinuLJGUmqp9wV4PbMsc4NvBc7O0cCR4Tqupp+SZit4+x/C8Tu0kZCbdXKIoYU 5aAQ==
X-Gm-Message-State: AFeK/H0LaBSZCmKss8D3D+hhJOW4nA46k+w+VWkJjFVmiR3j3yrmm6Ioi9PsfnI/MYjq3IKJJrbDOu14nmRXTg==
X-Received: by with SMTP id s7mr2193632qkb.60.1490815666869; Wed, 29 Mar 2017 12:27:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 29 Mar 2017 12:27:46 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Anthony Eden <>
Date: Wed, 29 Mar 2017 14:27:46 -0500
Message-ID: <>
To: Pieter Lexis <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] New draft for ALIAS/ANAME type
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Mar 2017 19:27:51 -0000

On Wed, Mar 29, 2017 at 11:14 AM, Pieter Lexis
<> wrote:
> Hello Anthony,
> On Wed, 29 Mar 2017 08:51:50 -0500
> Anthony Eden <> wrote:
>> 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.

As Tony pointed out, there are use cases for non-apex nodes as well.

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

It's a good point. Our implementation doesn't expose the ALIAS itself
as a queryable type, but there is a legitimate argument to allow it.

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

+1. In our case we would return both the static records as well as the
materialized records.

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

Good point.

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

Also a good point. I actually need to check our implementation to see
how it behaves now in this case.

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

Yes, I am removing the extra paragraph and going 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.

I agree.

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

Thank you for your feedback, I appreciate it.


Twitter: @dnsimple