If an implementation has a resolver, then that component is the logical
place for deduplication (e.g., the second inbound query for a given
ANAME target does not result in a second outbound query, but rather
waits on completion of the first).
On 4/9/19 11:15, Vladimír Čunát wrote:
On 4/9/19 3:38 PM, Richard Gibson wrote:
This loop is one reason of several to eliminate inline resolution for
ANAME if possible and minimize it otherwise, but is not quite as bad
as it seems because all involved servers can—and should—avoid issuing
queries that are redundant with an already-active request. But even if
they don't, the early queries eventually time out and rate limiting
eventually detects and caps the runaway load.
In other words, this misconfiguration does not create any new
vulnerabilities, and existing mechanisms are already sufficient to
handle it (although the document should explicitly mention them to
avoid subjecting new implementers to unnecessarily painful lessons).
I can't even see a simple way of detecting this. At least in the
implementation suggested by Jan where you have an authoritative that
calls out to a resolver (which calls out to authoritatives...) - it
would need some magic that somehow links one query of the cycle to the
other but regular DNS queries do not currently carry such information
AFAIK. Am I missing some obvious approach?
--Vladimir (Knot Resolver)
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
