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

Matthijs Mekking <matthijs@pletterpet.nl> Fri, 12 April 2019 11:34 UTC

Return-Path: <matthijs@pletterpet.nl>
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 E04E01202BD for <dnsop@ietfa.amsl.com>; Fri, 12 Apr 2019 04:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 W9nkhFm8iUd8 for <dnsop@ietfa.amsl.com>; Fri, 12 Apr 2019 04:34:19 -0700 (PDT)
Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 CFEBC12028F for <dnsop@ietf.org>; Fri, 12 Apr 2019 04:34:18 -0700 (PDT)
Received: from [IPv6:2001:980:4eb1:1:7ded:78bc:2f3d:68df] ([IPv6:2001:980:4eb1:1:7ded:78bc:2f3d:68df]) by smtp-cloud9.xs4all.net with ESMTPSA id EuRihwFhLiLOmEuRjhEyaI; Fri, 12 Apr 2019 13:34:16 +0200
To: 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> <alpine.DEB.2.20.1904121159150.17454@grey.csi.cam.ac.uk>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <317dae7d-7f8c-b724-0a00-06a6d318138b@pletterpet.nl>
Date: Fri, 12 Apr 2019 13:34:14 +0200
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: <alpine.DEB.2.20.1904121159150.17454@grey.csi.cam.ac.uk>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfA8yHHcUbw9IvQ4aZQdA/T6aRI2vp7JAzBUPOm3GUALp3fTIM94pv8itPQfoVayVjI4U+LgPJ9Dod7cGogsp5ETojcEGbSbqkvYZG23W+0qGWrqkleQI n1TGrBnP9Yznej4o6sqdz4El/b1eCENi83kD1hLpa6g/PBCAoRefegwv6n9l99bR6yCuc2OeQ+m9Mp1BGHeHQtQs1KFMWKL2pAhhTkDT0jO5ePeDIJ8k9oSV 9kWC/pZAgRy1D7s3mbWulWEi8zE/K7DzNs46p6Nm7q0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GF0idvgFduuCEYcrVORUe0uJgrY>
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 11:34:24 -0000


On 4/12/19 1:05 PM, Tony Finch wrote:
> Matthew Pounsett <matt@conundrum.com> wrote:
>>
>> I feel like this is creating an even bigger potential problem.  What
>> happens when the owner of the ANAME target legitimately wants that
>> name to go away, but some other zone owner is leaving an ANAME in
>> place pointing to that now-nonexistent name?  Continuing to serve the
>> sibling records indefinitely seems like serve-stale gone horribly
>> wrong.
> 
> It's worth noting that Oracle's ANAME model does not couple the sibling
> addresses to the ANAME target addresses. As I understand it, they have
> additional "fallback" infrastructure (web servers and whatnot) which is
> used when the ANAME target isn't available.
> 
> I'm not sure how this would work as a replacement for CNAME, when the
> request from the user comes without any information about how to set up a
> fallback server.

I think the logic suggested for ANAME is given this example:

1. Have ANAME and A and AAAA sibling address records.
2. Look up ANAME target A and AAAA target records.
3. If there is no positive answer (SERVFAIL, NXDOMAIN, NODATA) keep
sibling address records.
4. Otherwise replace sibling address records with ANAME target records.

This is different than NS1, that will never replace sibling address
records.  Instead, if there is no sibling address record, it will
perform ANAME resolution.  If that response is a SERVFAIL, NXDOMAIN or
NODATA, that is what will be given to the client (although returning
SERVFAIL won't be a thing in the ANAME specification).

In order to fit both use cases I think we need to relax the steps in the
ANAME resolution logic, but am hesitant to do that: If you make steps
optional it will be unclear what the optional resolver's behavior is
going to do.  I would very much like to see an agreement on the ANAME
resolution logic, especially so that customers can have multiple
providers or switch providers and can expect the same thing in both places.


Best regards,

Matthijs





> 
> Tony.
>