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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
