Re: [DNSOP] CNAME chain length limits

[dagon <[e-mail]>]

On Thu, May 28, 2020 at 01:02:47AM +0100, Tony Finch wrote:
> dagon <[e-mail]> wrote:
> >
> >   -- Tests for ("improper") horizontal vs. vertical CNAMEs.  Some
> >      recursive speakers fail; some complain ("BAD (HORIZONTAL)
> >      REFERRAL", but answer), and some follow without complaint.
> 
> Can you explain what these are, please?

If a canonical answer points to the same level as the 'owner name',
then the left and right sides share NS.  (This is the most common
case, and even outlined in 1034.)  If this discovery occurs during a
CNAME chain chase with yet another empty answer, the NS is in a sense
making a referral to itself, or its pool of secondary NS serving the
same delegation cut level---the bad horizontal referral.

1034 merely says resolution should be robust, and that "CNAME chains
should be followed and CNAME loops signalled as an error", s.3.6.2.
But that doesn't mean resolvers have to put up with this behavior
quietly.  Dig issues warnings in such cases; see followup_lookup() in
dighost.c:

   if (namereln == dns_namereln_equal) {
      if (!horizontal)
         printf(";; BAD (HORIZONTAL) REFERRAL\n");
      horizontal = true;

Tools that warn about this seem to take the larger view that such
referrals should be directed maybe to a new sibling tree (e.g.,
something in example.org CNAME'd to some place in example.com) or
further downward (implying there's a zone cut, but that aspect is not
enforced or audited by dig.)  There's sense in this: during the second
empty answer in CNAME to a mere sibling label, the recursive is
*already* talking to the right authority, dammit, and frankly it's
inability to sort the zone into a non-chained state is an unhelpful
referral.  (It may also symptomatic of a zone configuration error---
implicit $ORIGINs and inconsistent fqdns, and such---which is probably
why dig included this warning.)

You can actually experience something like horizontal referrals in
some US airport security screenings, which segregate passenger lines
based on ticket classes.  If you have a higher ranked ticket, but
stand in the *longer* lower ranked line to chat with your friend, you
might be referred back to the end of the higher ranked ticket line,
just to arrive again at the very same screening point---a bad
horizontal referral in most people's view.  I never encountered this
in European airports, and so it is very fitting that ldns tools and
kdig don't check horizontal referrals like dig.

By this analogy, DNS resolvers have a choice in chained horizontal
follows: quietly continue the journey, continue on but argue to anyone
logging complaints (dig), or just abruptly cancel the flight
(SERVFAIL).

It would be useful to have a survey of all such behaviors for various
appliances and tools on the Internet, since this sometimes leads to
zones being unavailable.  You can find a few anecdotes in the BIND
support lists.
 
-- 
David Dagon
[e-mail]
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717