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).
On 4/9/19 08:09, Jan Včelák wrote:
On Tue, Apr 2, 2019 at 5:54 PM Tony Finch wrote:
WRT loop detection, it is much easier if the additional section in the
response from the resolver contains the chain(s). The draft doesn't
specify that at the moment; maybe it should.
I meant a situation where an authoritative server is doing the sibling
address record substitution using an external resolver.
Imagine the following ANAME loop:
foo. ANAME bar.
bar. ANAME foo.
For simplification, expect the zones to live on different
authoritative servers and also that the ANAME processing triggers with
the first query.
The resolution steps will look something like this:
1. Authoritative receives a query for foo.
2. Authoritative finds the ANAME and calls out to the resolver asking for bar.
3. Resolver sends a query for bar to the authoritative.
4. Authoritative finds the ANAME and calls out to the resolver asking for foo.
5. goto 1
The authoritative server acting as a stub resolver doesn't have full
context of the resolution chain and therefore cannot break the loop.
We would have to pass around additional context in the queries and I'm
not sure if DNS firewalls would be happy to see messages with QR = 0
and ARCOUNT > 0.
Jan
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=4nTLZAsnHCwTJyrARtQ8uzJN8jmKg6JeQX9gDiHuHhc&s=O9ORRXkRs5TFBIKPXCdq6ck3K88lw-t7xDcNwI-ecMU&e=
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
