On 27/05/2020 07:33, Petr Špaček wrote:
> I would much rather spent time on
> https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03
>
> That would bring benefit to broader set of clients and has advantage
> that server does not send back data nobody asked for (thus wasting
> resource
On Wed, May 27, 2020 at 2:34 AM Petr Špaček wrote:
> On 27. 05. 20 1:05, Paul Vixie wrote:
> > so, this way lies madness, and the solution we see most often is a
> host-level
> > cache of DNS results. the old INN (usenet net news) server had one of
> these,
> > and all modern browsers have one. m
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".
Wh
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-
se
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.
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 someth
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, 2020
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
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 cu
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 27/05/2020 17:40, Eric Orth wrote:
> Maybe a better solution, but considering that the issue I'm dealing with
> is when the stub is unwilling to send additional queries or queries for
> new types out of concerns of middlebox ossificiation (especially from
> older home routers) on additional q
Paul Hoffman wrote:
>
> Add where in the response? In the Answer section or in the Additional
> section? The semantics and usefulness are wildly different for those
> two.
We learned from DNAME that a lot of DNS software gets very upset if there
are unexpected records in the answer section. If yo
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.finchhttp://dota
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 e
'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 01:02
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 comp
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 thre
17 matches
Mail list logo
