IETF Logo Mail Archive

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

Richard Gibson <richard.j.gibson@oracle.com> Fri, 12 April 2019 18:46 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 4D8D3120486 for <dnsop@ietfa.amsl.com>; Fri, 12 Apr 2019 11:46:12 -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 XxvS6pWe3WUl for <dnsop@ietfa.amsl.com>; Fri, 12 Apr 2019 11:46:10 -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 97EA8120817 for <dnsop@ietf.org>; Fri, 12 Apr 2019 11:46:10 -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 x3CIhbAY042146; Fri, 12 Apr 2019 18:46:09 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : from : to : cc : references : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=/W4X6aqFlYBfWquEH5dYmHinYQNKiBBbrkEJ5LsfqA0=; b=jwvTB6LCv5aD8Ys/PoyLRl0tfxXz8mLxznAdKW7dDzAOxhSQMMaRT9GZxAwGHQSdMuPN 9/SLeifZW1ppormpHayuncyNnZVMMfqq2AmjkNAJsaW/8zUsEA7Uie22BiGsnNYAkRJA Sby07oupKlvCO+sXvaRKQD1cQbRNUCmDAm5N4HoFgPr6bJDE3JNy43v5pswuFOqig0rl nF0gw6n2acNLldFe5tPYFljev18FPkOif7gEi05LQI0cXU9NtuSSre56ijTK4CVszWg2 HgH32DhAp9lQvhGkUEND2mBvmYrOTulJvslWRRFyGZhM1L8EZeDrRNqYuZVfgf7qdETk 1Q==
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2rpmrqr033-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 12 Apr 2019 18:46:08 +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 x3CIk1ng000946; Fri, 12 Apr 2019 18:46:08 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 2rtyj2rm2t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 12 Apr 2019 18:46:08 +0000
Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x3CIk2MZ006016; Fri, 12 Apr 2019 18:46:06 GMT
Received: from [192.168.1.213] (/67.189.230.160) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 12 Apr 2019 11:46:02 -0700
From: Richard Gibson <richard.j.gibson@oracle.com>
To: Matthew Pounsett <matt@conundrum.com>
Cc: Bob Harold <rharolde@umich.edu>, dnsop <dnsop@ietf.org>
References: <d8ccad4a-cd0c-4c97-b4d7-2099657351dc@oracle.com> <CA+nkc8BM+mfTBm3XyOaZUF5hMg23t9aSY4nq4Y4=BQ-sjcjkVg@mail.gmail.com> <25b38d21-c572-d782-6b35-a187fa0caae8@oracle.com> <CAAiTEH9Eg0oYw9HR9Ab5pYikFUvcbWXneF39_8xasp6tE9PpCA@mail.gmail.com> <516fda75-bb6e-67c6-cd52-0a5017bc889f@oracle.com> <CAAiTEH-ghaJB1XUm_3NJhzscH4ZTRHs34Rwndm40MVoD5FBGxw@mail.gmail.com> <734743c3-6603-3d93-de58-e6cf347c783f@oracle.com>
Message-ID: <913d85b5-89eb-7465-88cd-a5865e4bb8c0@oracle.com>
Date: Fri, 12 Apr 2019 14:46:00 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <734743c3-6603-3d93-de58-e6cf347c783f@oracle.com>
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=9224 signatures=668685
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-1810050000 definitions=main-1904120126
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9224 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904120126
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7W0UcKuZ3ecizJaDjXAZCJPStNM>
Subject: Re: [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: Fri, 12 Apr 2019 18:46:12 -0000

In further support of preserving sibling records when target chasing 
comes back negative, I'd like to further explore my offhand mention of 
"A and/or AAAA records".

For a domain owner wanting to use a currently IPv4-only service provider 
(names withheld) while still supporting IPv6, the logical approach would 
be configuring an ANAME record with one or more AAAA siblings. But that 
won't work if the AAAA NODATA response from chasing the ANAME target is 
allowed to override those siblings with nothing. This seems to force a 
needless choice between abandoning the provider or abandoning IPv6.

v2.23.0 | Report a Bug | By Email