Description of problem:
resolved < v248 apparently decides that if a lookup chain includes more than 8 CNAMEs, there must be a loop and fails the lookup. This causes at least one major website (LinkedIn.com) to fail to load in my location, as their static content edge servers have nine chained CNAME records before the A records.

Version-Release number of selected component (if applicable):
Experienced in Fedora 33 using systemd-246.13-1.fc33.x86_64

How reproducible:
100% in my location (edge content servers may vary by geography/ISP/etc)

Steps to Reproduce:
1. Query static-exp1.licdn.com with dig or resolvectl
resolvectl query static-exp1.licdn.com
dig -t A static-exp1.licdn.com (using default config with local stub resolver)

2. Compare results to querying an upstream nameserver
dig -t A static-exp1.licdn.com @8.8.8.8

Actual results:
resolvectl returns an error like:
static-exp1.licdn.com: resolve call failed: CNAME loop detected, or CNAME resolving disabled on '<REDACTED>.trafficmanager.net'

dig returns an empty result set with SERVFAIL status.

Expected results:
A records are returned successfully

Additional info:
It looks like this may be fixed (or at least less likely to occur) in systemd 248, based on the commit below.
GitHub issue: https://github.com/systemd/systemd/issues/9690
Linked commit: https://github.com/systemd/systemd/commit/e0ae456a554d0fce250f9a009c561b97f20c41f8

Workaround:
I have enabled DNS over HTTPS in Firefox to work around the defect in resolved. In this configuration, LinkedIn.com content loads correctly.