Re: [DNSOP] ANAME loop detection

[Matthew Pounsett <[e-mail]>]

On Thu, 4 Jul 2019 at 05:54, Matthijs Mekking <[e-mail]>
wrote:

> >
> > 1. EDNS "do not follow ANAME" option: The requester would indicate
> > that it is capable of following ANAME and that the server receiving
> > the query should not include the ANAME sibling address records. The
> > loop detection would then work exactly the same ways as with CNAMEs.
>
> This would be an easy addition I think, however I thought the "do not
> follow ANAME" option actually meant "really don't do a target lookup I
> can do it myself".  The authoritative server can still send the sibling
> address records that are placed in the zone, they can be used if the
> requester fails to perform the ANAME target lookup (for example due to a
> network error or outage).
>
> Furthermore, a service provide receiving such a request might want to
> ignore it if it feels strongly it should hand out more appropriate
> addresses than the sibling records (basically because that is the
> service they provide their customers, will they rely on an EDNS option
> from the requester saying "no really I can do this"?).
>

I would say they should rely on that.  Why shouldn't they?  Isn't our goal
to get downstream servers to adopt the extension and do their own lookup?
The server-side lookups and sibling records are bolt-ons to handle the
adoption period.  Remember, this record is geared toward customers of CDNs
being able to do get similar behaviour to:
www.example.com. IN CNAME webfarm.cdn.net.
at the apex of example.com.  That was the original problem we're trying to
solve.  I read your statement above about "the service they provide their
customers" being about the CDN resolving webfarm.cdn.net, which most CDNs
can already do within their own infrastructure.

Sending out the sibling records in the presence of this EDNS option might
make sense as a backup, since that is low effort on the part of the
authoritative, but a declaration by the querying server that it understands
ANAME and is prepared to do its own lookups should be trusted by the
authoritative server, and it should not to recursive lookups.  To take that
further, why would the authoritative server believe that the results of any
lookups it does would not be thrown away?

This EDNS option should also be useful to recursive servers that understand
ANAME, and are planning to do their own ANAME resolution.  They can get
their answer from the authoritative server much faster this way.

This is also a way to measure adoption.  As the ratio of "EDNS do not
follow ANAME" queries to total ANAME queries approaches 1.0, we know that
adoption has been successful.  Maybe we could even begin to deprecate
authoritative resolution (of ANAMEs) at that point, and begin to get back
to something that looks more like plain CNAME.

I would suggest that better EDNS semantics would be just "I
understand/support ANAME".   That gets the desired information across
without the sense of sending a command to the upstream server.

Option #2 gets similar behaviour but at the cost of additional lookups.  #3
and #4 don't work well in the presence of server farms.