Re: [DNSOP] Fundamental ANAME problems

Richard Gibson <richard.j.gibson@oracle.com> Fri, 09 November 2018 03:27 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 BED3E1292F1 for <dnsop@ietfa.amsl.com>; Thu, 8 Nov 2018 19:27:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.77
X-Spam-Level:
X-Spam-Status: No, score=-4.77 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] 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 ZY-vZUX4eeYP for <dnsop@ietfa.amsl.com>; Thu, 8 Nov 2018 19:27:27 -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 BF92A1277BB for <dnsop@ietf.org>; Thu, 8 Nov 2018 19:27:27 -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 wA93NwFB085362 for <dnsop@ietf.org>; Fri, 9 Nov 2018 03:27:26 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : from : to : references : message-id : date : mime-version : in-reply-to : content-type; s=corp-2018-07-02; bh=JvBDlzG4nXzJrlXMQ+ne6+Fkf124nO1bzrK31RKLnek=; b=Y3AMo4F7HA7PkMVAaIv1Vcv2rA+eLGgdhRSMnJv3TI8PbIoe0L1cv/EQP7527/LMnlqC BZHErHVC4oyY1RbUHdAgvau3g2T+AotL/xBeOvvsXntbXyWK1YTPauZdzRFojruXiRIa SqkX9t+H0H2FBxI8y6osmzVl3URSPuL3h5+PXdYGZDtXylzKsqibnchaxkAC7Izosow0 yibrQvB8+01kO/6HcaD5S1TNhzchwWLJtPyuyAgUxR7R/m4Bvjl67Y3CgemMbGasaE9S eoAly7q3irSiha2uEnPpLvz5m9A1cgtw7IpTynxX5e3we/7Bn45hWkB4faLoMTTx9Etr Ig==
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2nh3mq4wfu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org>; Fri, 09 Nov 2018 03:27:26 +0000
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wA93RPtF025625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org>; Fri, 9 Nov 2018 03:27:25 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wA93RPgd016407 for <dnsop@ietf.org>; Fri, 9 Nov 2018 03:27:25 GMT
Received: from [172.19.129.30] (/216.146.45.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Nov 2018 19:27:25 -0800
From: Richard Gibson <richard.j.gibson@oracle.com>
To: 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>
Message-ID: <f78934dc-bb05-a9b8-da81-6e610346c827@oracle.com>
Date: Thu, 8 Nov 2018 22:27:23 -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: <bccfabab-6fab-867e-7c12-8ced9f0d11b6@oracle.com>
Content-Type: multipart/alternative; boundary="------------570AEE3370BC4E8F8D0BCB2C"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9071 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-1811090029
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/c1zZkf4BSDVrpaCcWnX0PSgfjsU>
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 03:27:30 -0000

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.

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.

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.

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]: https://www.ietf.org/mail-archive/web/dnsop/current/msg21722.html
>