Jan, I like something like option 2 the best, I'll react to your options below.
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). 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"?). > 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. > 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. Best regards, Matthijs > 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 > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
