Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Dec 2011 19:12:33 +0300
From:      Peter Andreev <andreev.peter@gmail.com>
To:        freebsd <freebsd-questions@freebsd.org>
Subject:   mutual forwarders in ISC BIND
Message-ID:  <CAE_wXn1DzpxhhN_ASF%2B-LuxRBsdfgA8Se3ydhAgeJs5p53=VPg@mail.gmail.com>
In-Reply-To: <CAE_wXn2qKfQg_Od=VfX63TcvDSRFEz2ZLCDZDs71QjP2604QOQ@mail.gmail.com>
References:  <20111228075422.GA18064@admin.sibptus.tomsk.ru> <4EFAE80D.9040900@my.gd> <20111228130734.GA23763@admin.sibptus.tomsk.ru> <4EFB1B4F.2090504@my.gd> <CAE_wXn2qKfQg_Od=VfX63TcvDSRFEz2ZLCDZDs71QjP2604QOQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
2011/12/28 Damien Fleuriot <ml@my.gd>:
>
>
> On 12/28/11 2:07 PM, Victor Sudakov wrote:
>> Damien Fleuriot wrote:
>>>
>>> If you're trying to build up a cache to improve performance and respons=
e
>>> time, here's your scenario:
>>>
>>> DNS C, forward to DNS A,B for all queries
>>> DNS D, forward to DNS B,A for all queries
>>>
>>> Your cache will start building up and only responses that are not cache=
d
>>> will be taken from your NS A and B servers.
>>
>> Sorry, I fail to see how this is any better than two independent DNS
>> servers. Perhaps a variant like
>>
>> DNS C, forward to DNS A
>> DNS D, forward to DNS A
>>
>> would be close to the goal of cache consolidation.
>>
>
> DNS A suffers an outage ; you're fucked, to put it bluntly.

BIND can be configured to deal with such troubles. =A0But still Victor's
idea isn't very good. First of all because response time increasing in
case of using forwarders.

Victor, we researched this topic and learned that response time highly
depends on distance between user and resolver, while cache influence
on this value is lesser.
So I advice you to keep all as is.

>
>
>> Matthew Seaman wrote:
>>>
>>> If you want to consolidate caches then probably your best bet is to hav=
e
>>> fewer, but larger resolvers. =A0A pretty standard server class machine
>>> dedicated to recursive DNS should be easily capable of supporting many
>>> thousands of clients.
>>
>> You are certainly right.
>>
>>>
>>> DNS is not really a fruitful target for reducing traffic volume -- ther=
e
>>> really isn't that much of it compared to all other types in any case.
>>> It's also pretty critical to the perceived performance of your networks=
.
>>> =A0Complicating and slowing down the DNS lookup path just makes everyth=
ing
>>> look slow.
>>
>> I just wanted the servers to benefit from each other's caches. That
>> could speed up the lookups.
>>
>>
>
> On a side note, have you considered unbound ?
>
> It may be better suited to your needs and scale.
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.o=
rg"



--
--
AP


--=20
--
AP



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE_wXn1DzpxhhN_ASF%2B-LuxRBsdfgA8Se3ydhAgeJs5p53=VPg>