[DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

Richard Gibson <richard.j.gibson@oracle.com> Tue, 09 April 2019 17:56 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 CD25F12089D for <dnsop@ietfa.amsl.com>; Tue, 9 Apr 2019 10:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ckd7SXK-WOPe for <dnsop@ietfa.amsl.com>; Tue, 9 Apr 2019 10:56:41 -0700 (PDT)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 EEC561203A6 for <dnsop@ietf.org>; Tue, 9 Apr 2019 10:56:40 -0700 (PDT)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x39HrU2g121933 for <dnsop@ietf.org>; Tue, 9 Apr 2019 17:56:39 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=to : from : subject : message-id : date : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=t8QF7kI+/2N/gxKwysH4JVyMMCTgmtyT/TnPpxA5qnQ=; b=YugRy8BJzysnUJMJU9FzneVINiKX8Kv32Rr95zk8dyiI91pKTN54iQmmn9vWvpCsNBm3 fNH5LoyYrAKZe01JqIBii4V0mTqYH+FhionYsa7ZdPTRXHUrK4D67VVQQoUOSsLDVX7/ KwrBFM6Jh2W4wsDOgtwq7TeAzU6YFT34/GlnimopxjdoQc33JQfzCaL91QSF5RdxMc5+ SGypD9Yc0n+PfqLtOZpU4whUFQoebvHE5idp/XSrCrxdTuWuhRF13nsKdBWqXmSQMJKZ XwQFsoDUtIEhBqrrcIUrE9jwdkjU8X5BbMmGQZtORALTZuKmLSbryCVylVKUh/jvB/qJ BQ==
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2rpmrq6jyg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org>; Tue, 09 Apr 2019 17:56:39 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x39HtqqM175351 for <dnsop@ietf.org>; Tue, 9 Apr 2019 17:56:39 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 2rpkeje1wu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org>; Tue, 09 Apr 2019 17:56:39 +0000
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x39HucJb008442 for <dnsop@ietf.org>; Tue, 9 Apr 2019 17:56:38 GMT
Received: from [172.19.128.66] (/216.146.45.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Apr 2019 10:56:37 -0700
To: dnsop <dnsop@ietf.org>
From: Richard Gibson <richard.j.gibson@oracle.com>
Message-ID: <d8ccad4a-cd0c-4c97-b4d7-2099657351dc@oracle.com>
Date: Tue, 09 Apr 2019 13:56:29 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9222 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=1 spamscore=0 mlxscore=0 mlxlogscore=589 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904090113
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9222 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=602 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904090113
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1xiinJW_hDSOI84f7pJDu1VmYUs>
Subject: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?
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, 09 Apr 2019 17:56:43 -0000

Copied from https://github.com/each/draft-aname/issues/54 per Tony Finch.

The current draft specifies

> We treat missing address records (i.e. NXDOMAIN or NODATA) the same 
> successfully resolving as a set of zero address records, and distinct 
> from "failure" which covers error responses such as SERVFAIL or REFUSED.

This is both undesirable for customers of DNS service providers (whose 
active sites will occasionally be inaccessible to some clients for 
$SOA_MINIMUM seconds), and operationally cumbersome because resolvers 
are not in a good position to synthesize the necessary SOA records for 
NXDOMAIN responses (e.g., example.com. ANAME example.invalid. alongside 
example.com. A 192.0.2.1). Tony suggested that this was to be "as much 
like CNAME as possible", but I disagree because unlike CNAME, ANAME can 
have sibling records which are therefore available for use.