Re: [DNSOP] Fundamental ANAME problems

Matthijs Mekking <> Fri, 09 November 2018 10:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E06CF1292AD for <>; Fri, 9 Nov 2018 02:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FcmUJJYTUwJG for <>; Fri, 9 Nov 2018 02:03:43 -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 EC4A812777C for <>; Fri, 9 Nov 2018 02:03:42 -0800 (PST)
Received: from [IPv6:2001:980:4eb1:1:7d31:179:2099:8c3a] ([IPv6:2001:980:4eb1:1:7d31:179:2099:8c3a]) by with ESMTPSA id L3dcg0Aot0ZZEL3ddgVo4u; Fri, 09 Nov 2018 11:03:41 +0100
References: <> <> <> <>
From: Matthijs Mekking <>
Message-ID: <>
Date: Fri, 09 Nov 2018 11:03:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfB4b9bOLKkpmuHzhIqfIZPZhFLmPNjBWcATKiHs1Z5vdQ+YbJauRqgC9lFqR6Pwmyyxqz0DhFI/mS0Cn1erUgalrZza9owKvM3LQEVcrWRZBG8fLpBX/ X9jg4/9LqQ/zAYXRnkeDCxRP6goxdSbL9XRVDsuMlf46KJutEkTGdLjLj40gkO/UvHVMhdJ9QbYvr6Q3ctrrqqcNWYIJxlsInYgqP4rIrRLNdu55AI/gKaRq K34aDzqhiuO3Dn6vNeJLu0VMYcgBIYxH0nbRVdjPpdY=
Archived-At: <>
Subject: Re: [DNSOP] Fundamental ANAME problems
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Nov 2018 10:03:45 -0000

On 11/9/18 4:27 AM, Richard Gibson wrote:
> I have finally reviewed the latest draft directly, and like the overall 
> direction but have a small number of issues (however, the issues 
> theirselves are somewhat fundamental). They broadly break down into 
> concerns about zone transfers and TTL stretching, and ultimately seem to 
> stem from a disagreement with my position that the proper conception of 
> ANAME sibling address records is as fallback data to be used in cases 
> where ANAME target resolution fails or is never attempted.
> First, I am troubled by the requirement that ANAME forces the zone into 
> a dynamic zone. That a primary master would dynamically replace sibling 
> records on its own, update the zone serial, and then propagate that 
> dynamic data via zone transfer overrides user conception about the state 
> of a zone, induces undesirable churn between authoritative nameservers, 
> /and/ stretches the TTLs of ANAME targets on downstream servers by the 
> amount of time between successive updates. These consequences are just 
> too much for what is supposed to be a low-impact feature. Anyone willing 
> to opt-in to them should be updating the ANAME sibling address records 
> on their own, not forcing authoritative server implementations to choose 
> between taking on that dirty work or being labeled noncompliant.

It seems that everyone thinks that the latest ANAME draft requires DNS 
UPDATE. This is just a use case that Tony provides and would help him in 
his daily operations. However, it is not required to do so: ANAME 
resolution can also happen by updating the zone file before loading it 
into the primary server. Or it may happen in the authority server if 
people desire to implement it there.

I think the draft should be updated to make that absolutely clear. The 
draft should standardize how ANAME resolution is done, and what it means 
to have ANAME and sibling address records in the zone for address rtype 
(A, AAAA, ...) and ANAME query lookup.

The customer does not care about the address records, other than it may 
want to provide a default address. So in their provisioning dashboard 
they will only add a domain name that represents their CDN or whatever.

The DNS provider will perform ANAME resolution somewhere between where 
the customer provides the ANAME and hands out the addresses to the DNS 

> Second, and relatedly, I think the TTLs of replacement records 
> established for non-transfer responses are too high. Respecting the TTL 
> of every record in a chain that starts with the ANAME requires the TTL 
> of final replacement records to be no higher than the minimum TTL 
> encountered over the chain, potentially /reduced/ nondeterministically 
> to mitigate query bunching. I would therefore add language encouraging 
> resolvers synthesizing those records to engage in best-effort 
> determination of original TTLs by (e.g., by directly querying 
> authoritative servers and refreshing at 50% remaining), but *requiring* 
> them to decrement TTLs of records for which they are not authoritative.

I agree, the TTL language in this document is not ready and needs more 

> And finally, back on the question of what ANAME sibling address records 
> actually represent, I think that NXDOMAIN and NODATA results should be 
> treated as errors for the purposes of ANAME sibling replacement. This 
> position can be justified on both practical and principled 
> grounds—replacing functional records with an empty RRSet is undesirable 
> for DNS users (or at least the sample of them that are Oracle+Dyn 
> customers), and could inappropriately stretch the maximum specified 
> ANAME sibling TTL (on the ANAME record itself) to the SOA MINIMUM value 
> (which is doubly bad, because it results in extended caching of the 
> /least/ valuable state). And adding insult to injury, resolvers in 
> general will not even have the SOA, and will need to perform more 
> lookups in order to issue a proper negative response of their own. Let's 
> please just eliminate all of that by specifying that ANAME processing 
> can never replace something with nothing.


Best regards,


> P.S. There is a typographical error in Appendix D; "RRGIG" should be 
> "RRSIG".
> P.P.S. I think it has been discussed before, but this document should 
> also introduce and use a new "Address RTYPE" registry or subregistry, 
> rather than forever constraining ANAME exclusively to A and AAAA.
> On 11/2/18 17:00, Richard Gibson wrote:
>> I haven't reviewed the full draft yet, but am happy to see some people 
>> echoing my sentiments from earlier versions [1]. I particularly wanted 
>> to agree with some statements from Bob Harold.
>> On 11/2/18 15:20, Bob Harold wrote:
>>> Another option to give users is a non-updating fallback A record, 
>>> that could point to a web redirect.  That saves all the hassle of 
>>> updates.
>> YES! This means a slightly worse fallback-only experience for users 
>> behind ANAME-ignorant resolvers that query against ANAME-ignorant 
>> authoritatives (the introduction of ANAME awareness to /either/ 
>> component allowing an opportunity to provide better address records by 
>> chasing the ANAME target), but provides a dramatic reduction in the 
>> amount of necessary XFR traffic. And even more importantly, it forces 
>> TTL stretching to be an explicit decision on the part of those 
>> administrators who choose to perform manual target resolution and 
>> update their zones to use them as fallback records (as they would do 
>> now to approximate ANAME anyway), rather than an inherent and enduring 
>> aspect of the functionality.
>> Treating ANAME-sibling address records as fallback data also supports 
>> better behavior for dealing with negative results from resolving ANAME 
>> targets (NODATA, NXDOMAIN, signature verification failure, response 
>> timeout, etc.)—serve the fallbacks.
>>> My preference would be a *NAME record that specifies which record 
>>> types it applies to.  So one could delegate A and AAAA at apex to a 
>>> web provider, MX to a mail provider, etc.  That would also be 
>>> valuable at non-apex names.  But I am happy to support ANAME as part 
>>> of the solution.
>> I agree on both counts (arbitrary type-specificity and deferment to a 
>> later date).
>> [1]:
> _______________________________________________
> DNSOP mailing list