[DNSOP] ANAME loop detection

[Jan Včelák <[e-mail]>]

Hello.

I would like to resurrect the discussion about ANAME loops handling
and detection. I attempted to write a discussion section on this topic
for draft-ietf-dnsop-aname
[https://github.com/each/draft-aname/pull/70] and we also talked about
this a little off-list with Shane and Matthijs.

If you are still not concerned about the loops, imagine this setup:
Let's have two authoritative servers X and Y performing ANAME sibling
address substition on the fly (i.e. they attempt to resolve the ANAME
target when the client query arrives). If server X gets a query for
FOO.TEST which is an ANAME to BAR.TEST, it will send a query to server
Y for BAR.TEST which is an ANAME to FOO.TEST. Server Y will then start
a new query to server X, which has no way to know that it is regarding
the original FOO.TEST lookup.

The only indicator of the presence of the loop in the described setup
is the network timeout. Ideally we would recognize the loop explicitly
based on the exchanged DNS messages.

The on-the-fly ANAME substitution is allowed by the draft and it's
just the most obvious scenario where the problem can be demonstrated.
I'm quite sure there are other cases which do not involve
authoritative server doing on-the-fly substitution and where the loops
will still be a problem.

The root cause is that when the server gets a query it doesn't know
why and that the server always attempts to fully resolve the ANAME
target before sending the response.

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.

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

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.

Do you have thoughts on the listed options or brand new suggestions?

It's also worth mentioning that this is an optimization in a sense.
The timeouts will be the only option to resolve the loop with
ANAME-unaware resolvers.

Jan