On 4/12/19 1:05 PM, Tony Finch wrote:
> Matthew Pounsett <m...@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.
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
