Re: [DNSOP] Fundamental ANAME problems

Matthijs Mekking <matthijs@pletterpet.nl> Tue, 20 November 2018 15:07 UTC

Return-Path: <matthijs@pletterpet.nl>
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 27089129C6A for <dnsop@ietfa.amsl.com>; Tue, 20 Nov 2018 07:07:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhywEn3FFoER for <dnsop@ietfa.amsl.com>; Tue, 20 Nov 2018 07:07:33 -0800 (PST)
Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86BA12F295 for <dnsop@ietf.org>; Tue, 20 Nov 2018 07:07:32 -0800 (PST)
Received: from [IPv6:2001:980:4eb1:1:9845:1311:c6f0:32bd] ([IPv6:2001:980:4eb1:1:9845:1311:c6f0:32bd]) by smtp-cloud9.xs4all.net with ESMTPSA id P7caght3CQPpyP7ccgEJKJ; Tue, 20 Nov 2018 16:07:27 +0100
To: dnsop@ietf.org
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com> <CA+nkc8C6yVT62cW5QP-ec2ZT7FY_n48Ecr=CLeE6FS_1duBO8g@mail.gmail.com> <bccfabab-6fab-867e-7c12-8ced9f0d11b6@oracle.com> <f78934dc-bb05-a9b8-da81-6e610346c827@oracle.com> <alpine.DEB.2.20.1811091533160.3596@grey.csi.cam.ac.uk> <55cc2acd-7782-f44d-1c7e-c4855da62183@oracle.com>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <15e4e3fc-eedb-227d-cffa-0029fc8815c8@pletterpet.nl>
Date: Tue, 20 Nov 2018 16:07:24 +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: <55cc2acd-7782-f44d-1c7e-c4855da62183@oracle.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfMvV3At128gD5dZT7YA1Z5d1sloTAlw8VuxAIVGfsA3g5Wk/IhNVNBHTGt9g2WIj72YS8/r3ri11x9D37vFkVK+c0VrK3AwJb+nodrdI+e3c4lTmBDaz RrKy201bmW7lK0O6KKnc5igIMLPsgr01y40/OEA7E3Cq/gBeqKg41ZzDDvJLbMdU6j8sXl/f1Pm9L947Y5h3tWIH5tZub1XZVhjR9V9nxdxBXYn45VyHqMO6 j8U+PnwZmNBrjYPZVPpBTwMfhP1Ho0BpKMPw5PT9NiQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NU08oxyplBRiSrDeCIMDbMIShdQ>
Subject: Re: [DNSOP] Fundamental ANAME problems
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 20 Nov 2018 15:07:36 -0000

Follow-up.

tldr:
- The first argument is just an issue of wording.
- Authoritative servers or provisioning scripts that do ANAME processing 
should honor the target address records TTL.
- Sibling address records should be used as a default if ANAME 
processing fails.


On 11/9/18 6:54 PM, Richard Gibson wrote:
> Responses inline.
> 
> On 11/9/18 11:39, Tony Finch wrote:
>> Richard Gibson<richard.j.gibson@oracle.com>  wrote:
>>> First, I am troubled by the requirement that ANAME forces the zone into a
>>> dynamic zone.
>> I don't see how it is possible to implement ANAME without some form of
>> dymamic behaviour, either by UPDATEs on the primary, or on-demand
>> substitution on the secondaries, or some combination of the two.
> 
> I am advocating for the special behavior of ANAME be limited to 
> processing of non-transfer queries (i.e., explicitly excluding AXFR and 
> IXFR). For example: ANAME-aware authoritative servers MAY attempt 
> sibling replacement in response to address or ANY queries and SHOULD add 
> records to the additional section in response to address or ANAME 
> queries; ANAME-aware resolvers SHOULD do both. But all authoritative 
> servers should agree that the sibling records—including their original 
> TTLs—are a non-special part of zone contents for the purposes of transfers.

It looks like there is a non-issue: The draft allows you to do ANAME 
resolution however you want:
1. An anamifier script that updates a zone file before loading it into 
the primary.
2. A tool that translates ANAME target lookups into Dynamic Update.
3. An authoritative server that implements ANAME resolution.
4. ...

The point is that we would like to standardize the ANAME resolution, and 
what it means on the wire.

Richard makes a good point though that is: ANAME on zone transfers 
should have no special logic.



>>> 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'm not sure I understand which TTLs you are worried about here. What are
>> "non-transfer responses"? There's certainly some rewording needed to make
>> it more clear, but the TTLs returned by resolvers that do sibling address
>> record substitution are decremented in the usual way, and resolvers make
>> no attempt to determine the original TTLs.
 >>

non-transfer responses are responses for QTYPE != AXFR or IXFR.


> I hope the above clarifies... my TTL concerns relate not to resolvers, 
> but to authoritative servers. In particular, I take issue with the 
> "/Sibling address records are committed to the zone/" and "/Sibling 
> address records are served from authoritative servers with a fixed TTL/" 
> text, which stretches the TTL of one or more RRSets along the target 
> name's resolution chain.

Richard and I discussed this. In order for me to understand the issue I 
had to look this from the point of the resolver, that does ANAME resolution.

Suppose a resolver has an ANAME in its cache with a high TTL, say 3600, 
but not the target A and AAAA records. It can do the lookup for the 
targets. If successful, it will retrieve the A and/or AAAA records. 
Let's say they have a short TTL, 60. They time out after a minute, but 
the resolver can still use the ANAME record to do its own ANAME resolution.

In other words, if the resolver does ANAME resolution, the TTL of the 
target address records are honored. Now what does that mean for the 
authoritative side? What TTL should they use for the A and AAAA records 
that have been expanded by ANAME? It would only be logical that the 
authoritative side does the same.

This means that when adding A and AAAA records into the zone as a result 
of ANAME processing, the TTL to use is at most that of the TTL of the 
address target records. If you use a higher value, this will stretch the 
TTL which is undesired.



>>> 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),
 >>>
>> Maybe so, but that's what happens with CNAME records.
 >>
> CNAME does not allow for siblings, and therefore its processing is 
> incapable of replacing functional records with an empty RRSet. Further, 
> clients are required to understand CNAME and can therefore always 
> identify at which domain name an issue lies (and in particular that it 
> is not the queried name).
 >
>>> Let's please just eliminate all of that by specifying that ANAME
>>> processing can never replace something with nothing.
 >>>
>> So when the target goes away, you would prefer to leave behind zombie
>> address records, and stretch their TTL indefinitely? If the zone admin is
>> given only a target hostname (just like a CNAME) they don't have any
>> alternative addresses to use when the target goes away. So the options are
>> to copy the target by deleting the addresses, or ignore the target and
>> leave the addresses to rot.
 >>
> When the target goes away, there is no longer anything to replace the 
> sibling records, which are not zombies but rather part of the zone 
> contents and always issued by authoritative servers with their original 
> TTL (just like every other record, including the ANAME itself). Only if 
> there are no sibling records could an authoritative server issue a 
> NODATA response, and if a /resolver/ cannot successfully resolve an 
> ANAME target to non-expired records, then it should re-resolve the 
> requested RRSet anyway—it will get from upstream either refreshed 
> fallbacks or a NODATA, and in either case then has a response for its 
> own client.
 >
>> I'm inclined to say that fallback records should remain a non-standard
>> feature. The semantics can be that when you see the target go AWOL, delete
>> the ANAME and its siblings, and replace them with the fallback records
>> that were specified by some other means. You can apply the same logic to
>> CNAMEs too, if you want :-)
 >>
> A system that complicated would /have/ to be non-standard, but I think 
> you're reading too much into my use of the term "fallback". It's not a 
> specification of special treatment, but rather the absence of such that 
> gives ANAME sibling records that status... they're what to serve when 
> nothing replaces them (i.e., the current semantics of every record in 
> every zone that is not itself occluded by a delegation).

Perhaps a better word is "default". If a default is set it is used if 
the ANAME processing resulted in a negative answer. If no default is 
set, a negative answer is used as the final response. This allows for 
both use cases.

I am in favor of specifying that sibling address records are used as a 
default. If you don't want that functionality, then don't add sibling 
address records. If you do want it: you have a way of doing so.

I am hesitant to accept an argument like "CNAME does it this way". We 
are not trying to recreate CNAME logic here.



Best regards,

Matthijs