Shane, On 7/4/19 2:29 PM, Shane Kerr wrote: >>> 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.
If we change the specification such that sibling address records MUST be in the response to an ANAME request that extra lookup is not needed. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
