On Thu, May 28, 2020 at 01:22:40PM +1000, Mark Andrews wrote:
> '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’.
This
On Thu, 28 May 2020, dagon wrote:
On Thu, May 28, 2020 at 01:02:47AM +0100, Tony Finch wrote:
dagon wrote:
-- Tests for ("improper") horizontal vs. vertical CNAMEs. Some
recursive speakers fail; some complain ("BAD (HORIZONTAL)
REFERRAL", but answer), and some follow without
'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 wrote:
>
> On Thu, May 28, 2020 at
On Thu, May 28, 2020 at 01:02:47AM +0100, Tony Finch wrote:
> dagon 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
dagon 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?
Tony.
--
f.anthony.n.finch
On Wednesday, 27 May 2020 19:05:35 UTC Eric Orth wrote:
> I should also note though that Chrome's built-in stub won't do any followup
> queries if the full chain is not in the response from the recursive.
that's correct behaviour. full resolvers iterate (and recurse). stubs do not.
--
Paul
On Wed, May 27, 2020 at 06:08:46PM +, 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
While I should have been doing something else, I made a rather long CNAME
chain. When I looked up chain.examp1e.com it got SERVFAIL, but after I
warmed up my cache five links at a time by looking for chain5, chain10,
chain15, and so forth, it worked. At least it worked in "dig" and "host".
When
I should also note though that Chrome's built-in stub won't do any followup
queries if the full chain is not in the response from the recursive.
Interesting point -- if the result is truncated will it requery with TCP?
On Wed, May 27, 2020 at 3:03 PM Eric Orth wrote:
On Wed, May 27,
I should also note though that Chrome's built-in stub won't do any followup
queries if the full chain is not in the response from the recursive.
On Wed, May 27, 2020 at 3:03 PM Eric Orth wrote:
>
>
> On Wed, May 27, 2020 at 1:49 PM John R Levine wrote:
>
>> While I should have been doing
On Wed, 27 May 2020, John R Levine wrote:
While I should have been doing something else, I made a rather long CNAME
chain. When I looked up chain.examp1e.com it got SERVFAIL, but after I
warmed up my cache five links at a time by looking for chain5, chain10,
chain15, and so forth, it worked.
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-
While I should have been doing something else, I made a rather long CNAME
chain. When I looked up chain.examp1e.com it got SERVFAIL, but after I
warmed up my cache five links at a time by looking for chain5, chain10,
chain15, and so forth, it worked. At least it worked in "dig" and "host".
13 matches
Mail list logo
