Re: [DNSOP] CNAME chain length limits

[Mark Andrews <[e-mail]>]

'BAD (HORIZONTAL) REFERRAL' has nothing to do with CNAMES.  It’s reporting
a referral to a set of servers that in turn return a referral to another
set of servers server at the same depth.  It’s reported by ‘dig +trace’. 

> On 28 May 2020, at 12:44, dagon <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]