Re: [DNSOP] Fundamental ANAME problems

Richard Gibson <richard.j.gibson@oracle.com> Fri, 09 November 2018 17:54 UTC

Return-Path: <richard.j.gibson@oracle.com>
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 6BCEA12D4EE for <dnsop@ietfa.amsl.com>; Fri, 9 Nov 2018 09:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.211
X-Spam-Level:
X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, TVD_PH_BODY_META=1.559] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
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 JsYEJuYcsHEJ for <dnsop@ietfa.amsl.com>; Fri, 9 Nov 2018 09:54:20 -0800 (PST)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 13039128766 for <dnsop@ietf.org>; Fri, 9 Nov 2018 09:54:19 -0800 (PST)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wA9HsEBW180142; Fri, 9 Nov 2018 17:54:15 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=corp-2018-07-02; bh=rc78BA+lTj2kdnr/z5RUsyUfOwO3+vmjUHJVYCM42U8=; b=4/9BX1ozepyfrcCn/Ac2jD+0bRy60aEp/3qSR75BVIpy6qKspiHb1/wCK5Tx4jLOYLAO othZPG1/F4hMgw7UR4hJhhvI3LCpfDUCrIZnl7qnew0fOyggJj/XR8QMmk4Q71trzZHl 1vo9IMM5V7YqtX2UpUbaab6rwGBMKhsMtsvolA7hgV6MkTsa7tIrKIxcJkco3HTa15TH 45kovYgeHxFvc2hWCQHcXdZur/9Ofo2mYMrvsVnv5eu5hft/Ur4j+6A/rwSLBIdHdeWl toZPIt2CXSH31axz5Hgktx3HaZ3wSzfchjoXhMprUtcWOGvJPwqa6p/bu+WzK26KXF5Z 5Q==
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2nh3mq8fqq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 09 Nov 2018 17:54:15 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wA9Hs9Cv014596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 9 Nov 2018 17:54:09 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wA9Hs91n021007; Fri, 9 Nov 2018 17:54:09 GMT
Received: from [172.19.131.114] (/216.146.45.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Nov 2018 09:54:08 -0800
To: Tony Finch <dot@dotat.at>
Cc: IETF DNSOP WG <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>
From: Richard Gibson <richard.j.gibson@oracle.com>
Message-ID: <55cc2acd-7782-f44d-1c7e-c4855da62183@oracle.com>
Date: Fri, 9 Nov 2018 12:54:02 -0500
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: <alpine.DEB.2.20.1811091533160.3596@grey.csi.cam.ac.uk>
Content-Type: multipart/alternative; boundary="------------7CFAFACA98D9FBE01664DABE"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9072 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811090163
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/roKmw2aZ9-GS4kCJ0jwP8BUO_rA>
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: Fri, 09 Nov 2018 17:54:22 -0000

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.

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