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

[Richard Gibson <[e-mail]>]

On 4/12/19 07:34, Matthijs Mekking wrote:
> 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.
The strategy of never replacing siblings seems ill-advised to me, but 
not really harmful because it's functionally equivalent to being 
ANAME-ignorant and therefore matches the behavior of all resolvers and 
nearly all authoritative servers currently on the Internet, and also the 
behavior of future resolverless ANAME-aware authoritative servers.