Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt

Evan Hunt <> Fri, 26 January 2018 02:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD7F112D88B for <>; Thu, 25 Jan 2018 18:44:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZyYHdvPrkZyT for <>; Thu, 25 Jan 2018 18:44:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DDC91270AB for <>; Thu, 25 Jan 2018 18:44:56 -0800 (PST)
Received: from ( [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4A8F3AB1AE; Fri, 26 Jan 2018 02:44:51 +0000 (UTC)
Received: by (Postfix, from userid 10292) id A6E9B216C1C; Fri, 26 Jan 2018 02:44:51 +0000 (UTC)
Date: Fri, 26 Jan 2018 02:44:51 +0000
From: Evan Hunt <>
To: "Wessels, Duane" <>
Cc: dnsop <>, Peter van Dijk <>, "" <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.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: Fri, 26 Jan 2018 02:44:57 -0000

On Thu, Jan 25, 2018 at 11:51:30PM +0000, Wessels, Duane wrote:
> As an example, consider an ANAME record with TTL 3600 and a corresponding
> AAAA record with TTL 86400.

You'd want the AAAA to expire no later than the ANAME did, because the
ANAME might have been updated to point to some other name by then.

> I'm suggesting its just as acceptable to return the AAAA record with TTL
> counting down from 86400, but after 3600 seconds it is ejected/marked
> stale/whatever from the ANAME-implementing authoritative server.
> Unbound does that with its cache-max-ttl setting.
> If you do it this way then the consumers of the data (including
> ANAME-unaware clients) get to cache it for the original TTL.  

That's exactly what I'm trying to prevent.

With an ANAME-aware resolver, the address returned by the auth is ignored,
the resolver chases the answer for itself, and records are all cached with
their original TTLs.  The ANAME answer and the target answers expire when
they should, just as with a CNAME now.  In your example, the ANAME expires
after 3600 seconds, so we re-query to refresh it. If it's changed, then we
follow it to get a new AAAA, but if it hasn't changed, then since we already
have the AAAA cached, there's no need to chase it again.

But with an ANAME-unaware resolver, it asked for an address, got one, and
will cache it for whatever TTL you sent it. If your ANAME has a one-hour
TTL, then you wouldn't want to send a higher TTL than that; you'd just
overriding the ANAME TTL.

> It seems to me that ANAME gives auth servers resolver-like properties, so
> why wouldn't that apply there as well?

Yes, fair point. I'll try to come up with text to address this.

Evan Hunt --
Internet Systems Consortium, Inc.