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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
