Re: [DNSOP] ANAME loop detection

[Matthijs Mekking <[e-mail]>]

Matthew,

On 7/4/19 2:32 PM, Matthew Pounsett wrote:
> 
> 
> On Thu, 4 Jul 2019 at 05:54, Matthijs Mekking <[e-mail]
> <mailto:[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 <http://www.example.com>. IN CNAME webfarm.cdn.net
> <http://webfarm.cdn.net>. 
> at the apex of example.com <http://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 <http://webfarm.cdn.net>, which most CDNs can already do
> within their own infrastructure.

I am talking about DNS providers that perform CNAME at the Apex like
features: a customer goes to them and opts in to this feature. Such a
provider wants to make sure that it is providing the behavior the
customer expects and thus wants to make sure it hands out appropriate
addresses.

Also what is wrong with an authoritative server already giving out more
optimal answers than just the ANAME and sibling address records?


> 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.

I am not sure if that is true. Perhaps if you do ANAME target lookup on
the fly yes, but I think most implementations will have a side process
that does the target lookup and the query resolution can get the target
addresses just from cache.


> 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.

I am fine with a "understand/support ANAME" signal, I don't like if that
prohibits the receiver to do its own target lookups. So I am in favor of
a signal that says "this query is part of an ANAME target lookup" to
distinguish it from an address query.


> 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.

If addresses are in the response to the ANAME request there is no
difference in number of lookups between 2 and 3 I think.

Best regards,

Matthijs