Re: [DNSOP] ANAME loop detection

[Shane Kerr <[e-mail]>]

Matthijs,

On 04/07/2019 11.54, Matthijs Mekking wrote:
> 
> I like something like option 2 the best, I'll react to your options below.

I like something like option 1. Details below as well. 😊

> On 7/4/19 11:37 AM, Jan Včelák wrote:
>> Hello.
>>
> [ ... ]
> 
>> We had been thinking about how this could be fixed and here is what we
>> have came with:
>>
>> 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).

I think that your understanding is correct, and is basically what is 
meant. Again, the idea is to avoid having the authoritative server do 
lookups on behalf of anything trying to follow an ANAME chain.

So the language would probably be like, "An ANAME-aware server that 
receives a query with the 'do not follow ANAME' option MUST NOT send DNS 
queries in order to look up ANAME targets. It MAY include ANAME targets 
in the response if getting those does not require sending DNS queries."

> 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 suppose this makes a certain amount of sense, although the service 
needs to be careful to ensure that ANAME records timeout no later than 
the sibling records so that no resolvers will resolve ANAME without 
going to it.

If this is a use case that we care about, it might be worthwhile to have 
some explicit text around this, possibly in the "On preserving TTLs" 
section?

>> 2. QTYPE=ANAME: According to the current version of the draft, server
>> answering to ANAME must include the ANAME and should include the
>> sibling records. Let's modify the behavior and say the server should
>> not (must not) include the sibling records. Then the server performing
>> ANAME sibling address resolution could first query for ANAME before
>> trying A or AAAA. We get the same loop detection mechanism as with
>> CNAMEs at the cost of an extra query per ANAME
> 
> Again, I think what we should clarify is that it is a signal to not do
> do ANAME target lookup. Sibling address records are fine and required at
> some point.
> 
> I like this option the best, because the requester is interested in the
> ANAME record in the particular zone, and so there is no need for
> chasing.  While with address queries the requester is actually
> interested in the target address, and so chasing makes sense.
> 
> We could change the specification such that a server that does ANAME
> target lookups MUST use QTYPE=ANAME and servers receiving ANAME queries
> MUST NOT chase the target and would solve the loop problem.

My main concern about this approach is the extra lookup required.

Keep in mind that most ANAME targets are NOT going to be ANAME 
themselves (although probably many will), so this means that in most 
cases ANAME servers will have to do an extra lookup before moving on to 
usual A/AAAA lookups. These QTYPE=ANAME cannot be done in parallel with 
A/AAAA queries, since those might trigger the ANAME loops that we are 
trying to prevent.

Everything will work, and caching might make this unimportant. Still, I 
think that the EDNS option is a better choice overall.

I will admit that QTYPE=ANAME will have an advantage in complex setups 
because EDNS is hop-by-hop and DNS queries will relayed without this 
concern.

>> 3. EDNS "seen names" options: An option with a list of visited ANAMEs
>> would be introduced. The requester would add the option into the query
>> when resolving an ANAME target. The receiving server would consult the
>> list in case another ANAME was encountered and either broke the loop
>> or forwarded the updated option to the next server.
>>
>> 4. EDNS "nonce" option: Variance on the previous option which would
>> include a numeric nonce instead of full domain names. A receiving
>> server would break the loop if it has seen their nonce. It would be
>> more compact but the question is how to select the nonce pragmatically
>> especially if there can be more servers serving the same zone.
> 
> These options feel like more work and if one of the earlier options work
> I would rather do that.

Totally agreed. I am happy that they are here for completeness though.

Cheers,

--
Shane