On Wed, May 27, 2020 at 06:08:46PM +0000, Evan Hunt wrote:
> On Wed, May 27, 2020 at 01:48:32PM -0400, John R Levine wrote:
> > is there any consensus as to the maximum CNAME chain length
> > that works reliably, and what happens if the chain is too long? Hanging
> > seems sub-optimal.
>
> BIND cuts CNAME chains off at 16. As far as I know that was an arbitrarily-
> selected value, but it's been in the code since 1999 and so far as I can
> recall, no one's complained. The maximum reliable chain length won't be any
> longer than that; it might be shorter.
>
> When a chain is too long, I think BIND just returns a response with the 16
> CNAMEs it's found so far, and without a final answer. The client can start a
> new query from where the response left off, but I would expect most to
> treat it as a non-answer.
This is an interesting topic.
Some recursives cut off at 8 CNAME chains. Some (Level 3, if I
recall) fail at less, but retry right after sending SERVFAIL or
RCODE!=0 to the stub, perhaps to populate cache farms. Some major
"cloud DNS" (e.g., Google if I recall) chase 30 chains before fail.
Some appear to have a ~3-sec window for the outbound queries (meaning
they have no chain count limit, only time); some appear to have a hard
numbered limit like BIND.
Poorly crafted DNS crawler scripts seem to follow CNAMEs forever (up
to some script mediated timeout period, or until the operator stops
the script and complains to the parent zone's registrar, on the theory
that unexpected behavior is abuse---despite CNAME chains being useful
for path diagnosis in VPN operation, passive DNS monitoring, etc.)
The CNAME behavioral matrix can also be extended to include:
-- Tests for ("improper") horizontal vs. vertical CNAMEs. Some
recursive speakers fail; some complain ("BAD (HORIZONTAL)
REFERRAL", but answer), and some follow without complaint.
-- All should avoid graph cycles in CNAME chains back to ancestral
records.
-- Tests for slow responses, where the authority crafting the CNAME
delays by some variable millisecond time period, to test whether
the chain depth is time or count based.
-- One could test for 1034 s.3.6.2 restart to chase discovered
CNAMEs, absent additional records being added to cache. Some
platforms (Azure, if I recall) return just the CNAME, even if
local cache (evidently) holds a terminating record. I've not
tested if this (re)introduces circular dependencies, but
Azure(?)'s explanation would be that the restart and cycle
detection must now occur in the stub. But one should test
with/without BIND's minimal-responses (and similar configurations
in other recursives), and implications for cycles.
-- All of the above, but for DNAME instead of CNAME. PowerDNS will
not support this of course, for what I infer are (understandable)
architectural and commercial demand reasons. But conceptually an
authority creating synthetic CNAME records is a workable
substitute for DNAMEs. Some DNAME chase limits follow the CNAME
chain limits. One can chain multiple CNAME chains together using
DNAME, and this may count against the original chain counter, or
start a new one (and sometimes within some timeout period of
course). This also stops many script-based crawlers, which don't
handle DNAMEs or don't bother to substitute synthesize the query
under the new zone tree. (I.e., they appear to cut/grep DNAME
answers, and not handle out-zone synthesis, making them blind to
the referral subzones.)
-- Same, but for so-called ANAME or 'rooted CNAME' records.
-- Measure all of these behaviors tests where the NS has essentially
zero TTL (e.g., to measure whether retries are with/without NS
delegation rediscovery).
-- Measure all of the above with/without DNS authorities that are
whitelisted for EDNS Client Subnet. (It is hard to think of a
reason to allow ECS in a CNAME, PTR, or similarly constrained
query type. But some architectures use "turtles all the way
down", and the CDN itself needs a CDN via ECS, which then needs a
CDN via ECS, etc.
I've tested all of these combinations and more. There are also many
valid commercial uses for CNAME chains beyond CDN and zone agility
(e.g., path discovery, edns-client-subnet testing, etc.) So
blocking/limiting CNAME chains seems unwise.
--
David Dagon
[email protected]
D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
