Re: [DNSOP] ANAME loop detection

[Matthijs Mekking <[e-mail]>]

Jan,

On 7/8/19 11:32 AM, Jan Včelák wrote:
> On Thu, Jul 4, 2019 at 4:55 PM Matthijs Mekking wrote:
>> On 7/4/19 2:32 PM, Matthew Pounsett wrote:
>>> 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?
> 
> I also understand the sibling address records only as a mean to gap
> the adoption period. It should not be a feature.

It's not a feature, its an optimization: If the requester receives a No
Data response to its ANAME query, he can finalize the target lookup with
an address query to the last target in the chain.


> If the DNS provider (i.e. authoritative server) wanted to perform some
> magic to provide more optimal answer than the resolver could get by
> resolving the ANAME then there is no point of involving ANAME. You can
> perform the magic with A/AAAA already.

Not more optimal than the resolver, but more optimal than the default
sibling address records that are put into the zone.  The benefit of that
is that the resolver has more sane addresses to hand out to the client
in case it is unable to perform ANAME target lookup (due to timeout for
example).


>>> 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 speculative. The conditions may be very different in each setup.
> 
>>> 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.
> 
> This probably makes me like the option #1 the most.
> 
> Jan
>