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

Richard Gibson <> Sun, 09 April 2017 01:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 786B3126B72 for <>; Sat, 8 Apr 2017 18:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CMUnjlhPHIML for <>; Sat, 8 Apr 2017 18:38:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::248]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E9E0128B92 for <>; Sat, 8 Apr 2017 18:38:50 -0700 (PDT)
Received: by with SMTP id u103so6706986uau.19 for <>; Sat, 08 Apr 2017 18:38:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oepguoSqOjcK0m1MtJQsdFFRNkaEoAOSvu5j1l6mNG8=; b=AW52bn0YnJR3wcXyNWXf3zEbhrHATwQY3BIzPX43HMsGlRrAYebDhz9WJHthT5kGnQ KEnqNuivSC9wPF8IYJWhnX9MqhMySitGnnPA7LAaDglG3U+nc9yyHg8H5adnvH/uxfv6 hKeYHSrjM/TFPWsLqBXA7osDZy90Ny5cpul50=
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; bh=oepguoSqOjcK0m1MtJQsdFFRNkaEoAOSvu5j1l6mNG8=; b=CrBZyAPOHdWI08CqR54Bvi4xtpZMYXpW7zVhkS3vaicrdfK8pRtv9aPFTu/95YM2Xe TiqyQ2brMTkUaVgKIQxrAVZg7QxFiKu6J21EqJUrIREIK8OwxgA44vQbE/zT6zR7V2cK VW3/fk9DN5UkfNno4nP0Vn5SIMsh8rcMAmB5veM7EHUTlNlqlqbnJOYYuEEsUHauh/Wb 1P82i6mwzBRIBNEpWHVmwLY0jmffHqD/dr1Ih6v8MomLUzfiNXi6QH+SoDw6d3VDbzAl B4Xo8PnnhfdTx1GulYbWfx1kmfpokXu4Dwh15XcbLyANiMmt2l/oq6GmCRrM5ZoJoKa+ 1tww==
X-Gm-Message-State: AN3rC/49FNlFY4SYuqGTdJ5LREPaNsIRfYLa6ib/VEh45gu8uYxWRJ84A0qdUroK45DjdFQVCTAUJi7++CU5OKJJ
X-Received: by with SMTP id c130mr6604137vka.127.1491701929427; Sat, 08 Apr 2017 18:38:49 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 8 Apr 2017 18:38:29 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Richard Gibson <>
Date: Sat, 8 Apr 2017 21:38:29 -0400
Message-ID: <>
To: Evan Hunt <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary=001a114469c09d58d4054cb1ebd9
Archived-At: <>
Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
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: Sun, 09 Apr 2017 01:38:53 -0000

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

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

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

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

It is also mute on the use of DNSSEC for resolving ANAME target records,
but that should probably be covered somewhere.

On Fri, Apr 7, 2017 at 2:11 PM, Evan Hunt <> wrote:

> Greetings,
> Here's the new ANAME draft I mentioned last week.
> This is similar to existing non-standard approaches (ALIAS records,
> CNAME-flattening, etc) but also sends the ANAME record to the resolver so
> that, if the resolver understands the ANAME type, it can re-query for the
> answer just as it would with a CNAME.
> Please have at it.
> ----- Forwarded message from -----
> From:
> To: Evan Hunt <>rg>, Peter van Dijk <
> >,
>         Anthony Eden <>
> Subject: New Version Notification for draft-hunt-dnsop-aname-00.txt
> Date: Fri, 07 Apr 2017 11:04:39 -0700
> A new version of I-D, draft-hunt-dnsop-aname-00.txt
> has been successfully submitted by Evan Hunt and posted to the
> IETF repository.
> Name:           draft-hunt-dnsop-aname
> Revision:       00
> Title:          Address-specific DNS Name Redirection (ANAME)
> Document date:  2017-04-07
> Group:          Individual Submission
> Pages:          10
> URL:  
> drafts/draft-hunt-dnsop-aname-00.txt
> Status:
> Htmlized:
> Htmlized:
> aname-00
> Abstract:
>    This document defines the "ANAME" DNS RR type, to provide similar
>    functionality to CNAME, but only redirects type A and AAAA queries.
>    Unlike CNAME, an ANAME can coexist with other record types.  The
>    ANAME RR allows zone owners to redirect queries for apex domain names
>    in a standards compliant manner.
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> The IETF Secretariat
> ----- End forwarded message -----
> --
> Evan Hunt --
> Internet Systems Consortium, Inc.
> _______________________________________________
> DNSOP mailing list