Re: [DNSOP] Fundamental ANAME problems

Richard Gibson <richard.j.gibson@oracle.com> Fri, 02 November 2018 21:00 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 53F6C130DDF for <dnsop@ietfa.amsl.com>; Fri, 2 Nov 2018 14:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.769
X-Spam-Level:
X-Spam-Status: No, score=-4.769 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, URIBL_BLOCKED=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 WAWfSLcHc3Vu for <dnsop@ietfa.amsl.com>; Fri, 2 Nov 2018 14:00:53 -0700 (PDT)
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 BDB83128BCC for <dnsop@ietf.org>; Fri, 2 Nov 2018 14:00:53 -0700 (PDT)
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 wA2KxTdJ152696; Fri, 2 Nov 2018 21:00:51 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=bTANwX7+laabEnlnZxqm/cctD6Kd1QVRw7WO88tbA3A=; b=KMgAkQJp0XoqYCRREl8IWd80PnjqGxdWLzUDmaWuqkG4EKjAh8qV1T6HyIKhKfI4FXV8 EiEjgncscDwMFktwt0LIDCLaYftXuX7G43K7MRKEegj2jjYEBSDPvA4cGdZs8d0/rwNP YdxZEZ0idqoNchVSoAebz0SS1xYtmED3e4IgP6biHLUmSzJQK+uUeQU6XxYKyDTQUbH2 51NNXQcOX0yqeHvgPzf2uG6CMYAg5M776nP13c0TfS9aQFSfrY7PabBpziR4U7mAQRkU MDM4H/u7mibFRPXwdcBSbUltgHmZOl9R/CFk6emtaGFfqULiat+ICpBxl6VTnjkJu1v6 HQ==
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2ncfyqgpkk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 02 Nov 2018 21:00:51 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wA2L0n7f008786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Nov 2018 21:00:50 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wA2L0nhL007296; Fri, 2 Nov 2018 21:00:49 GMT
Received: from [172.19.128.190] (/216.146.45.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Nov 2018 14:00:49 -0700
To: Bob Harold <rharolde@umich.edu>, Brian Dickson <brian.peter.dickson@gmail.com>
Cc: IETF DNSOP WG <dnsop@ietf.org>
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com> <CA+nkc8C6yVT62cW5QP-ec2ZT7FY_n48Ecr=CLeE6FS_1duBO8g@mail.gmail.com>
From: Richard Gibson <richard.j.gibson@oracle.com>
Message-ID: <bccfabab-6fab-867e-7c12-8ced9f0d11b6@oracle.com>
Date: Fri, 02 Nov 2018 17:00:47 -0400
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: <CA+nkc8C6yVT62cW5QP-ec2ZT7FY_n48Ecr=CLeE6FS_1duBO8g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------3E7EED7B5F3117ADC06784E6"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9065 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-1811020187
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8UMgSRVTaMty38bINc8bOc8zFts>
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, 02 Nov 2018 21:00:56 -0000

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