'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 <da...@sudo.sh> wrote:
>
> On Thu, May 28, 2020 at 01:02:47AM +0100, Tony Finch wrote:
>> dagon <da...@sudo.sh> 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
> da...@sudo.sh
> D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
