Re: [DNSOP] CNAME chain length limits

[dagon <[e-mail]>]

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
[e-mail]
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717