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