Where Yast asks for forwarders, you can give your ISP dns servers as forwarders. Alternatively, it should be okay to leave the list empty.
The defaults for other choices should work for a caching server.
The first screen has “Netconfig DNS policy”. If you leave that at “auto”, then you will probably continue to use your ISP dns servers unless you manually edit “/etc/resolv.conf”. If you change to “static”, it should set it up for using the caching server. I’m inclined to suggest that you leave it at auto; you can then make a backup copy of “resolv.conf”, then edit it to use 127.0.0.1 as the nameserver. That will allow experimenting. You can make those changes permanent at a later time.
One of the screens gives you a choice of starting manually, or start up now and when rebooting. You probably want “now and when rebooting”.
There’s an option to open port in firewall. You should not need that, unless you want other computers to consult your DNS server. You can change the firewall settings later if you decide to do that.
On Thu, 19 May 2011 11:36:05 +0000, suse kid wrote:
> (a) Will enabling DNS caching improve my Internet experience ?
Maybe, maybe not. Caching DNS servers also are generally configured to
negatively cache services they cannot locate for a set period of time, so
if you happen to cache a non-response from the upstream DNS provider,
your local cache will just tell you the service doesn’t exist.
If your experience is that none of the upstream providers are consistent
enough and perform poorly, that tells me there’s a problem at your ISP.
While it’s not unusual to occasionally lose DNS connectivity, dropping
DNS connectivity isn’t a normal thing and as such, you shouldn’t be
trying to work around the problem with a band-aid, but be working with
the ISP to figure out what the problem is to fix it permanently.
What happens is, suppose I configure Google DNS & start using it. It works well for a long time …for months but one fine morning I see a delay in name resolution …then I switch to 4.2.2.x & it gets fast again.
So, if this is a ISP related problem how come it gets fast instantly as I disconnect & connect my dsl connection (after manually changing the DNS servers)?
You know better but I guess these public DNS servers go through their ups & downs. Once repaired they perform well I am too impatient to wait for that. lol!
On 05/19/2011 04:36 PM, suse kid wrote:
>
> @hendersj
>
> What happens is, suppose I configure Google DNS& start using it. It
> works well for a long time …for months but one fine morning I see a
> delay in name resolution …then I switch to 4.2.2.x& it gets fast
> again.
>
>
>
> So, if this is a ISP related problem how come it gets fast instantly as
> I disconnect& connect my dsl connection (after manually changing the
> DNS servers)?
>
> You know better but I guess these public DNS servers go through their
> ups& downs. Once repaired they perform well I am too impatient to wait
> for that. lol!
It could be buffer bloat anywhere in the path from you to the DNS server. Once
you select a new path, all those big/full buffers are eliminated from the path.
Speed Test #96986166 by dslreports.com
Run: 2011-05-19 19:07:27 EST
Download: 554 (Kbps)
Upload: 314 (Kbps)
In kilobytes per second: 67.6 down 38.3 up
Boost: 1033
Latency: 264 ms
Tested by server: 3 flash
User: anonymous
User's DNS: bsnl.in
Okay …Done …And its working …the only ip that is currently in mt /etc/resolve.conf is 127.0.0.1 and I have added my choice of public DNS servers during the setup process.
Again, I am curious, where is the internal DNS service of openSUSE storing the name to ip records ? …Any ideas ???
On 05/19/2011 06:06 PM, suse kid wrote:
>
> lwfinger;2341987 Wrote:
>>
>> It could be buffer bloat anywhere in the path from you to the DNS
>> server. Once
>> you select a new path, all those big/full buffers are eliminated from
>> the path.
>
> How to detect a bufferbloat ?
>
> How to fix/prevent it ?
As usual, Google is an excellent place to start learning.
> Okay …Done …And its working …the only ip that is
> currently in mt /etc/resolve.conf is 127.0.0.1 and I have added my
> choice of public DNS servers during the setup process.
Leave only the 127 one, ie, your own local server. It is your local server
which will consult first the public DNS.
> Again, I am curious, where is the internal DNS service of openSUSE
> storing the name to ip records ? …Any ideas ???
memory, IIRC.
You can dump it.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
On 2011-05-19 19:12, Jim Henderson wrote:
> you shouldn’t be
> trying to work around the problem with a band-aid, but be working with
> the ISP to figure out what the problem is to fix it permanently.
Good luck talking to my ISP >:-P
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
> I once saw a DNS server running on Win Server 2003.
>
> In Win Server, I noticed that the records are stored within the server
> & stays there until the admin removes them.
Suse Kid;
Are you sure you were not observing local zone files? Bind keeps the local
zones in /var/lib/named/. The actual sub directory that contains these zone
files varies depending on how the server is configure. For DDNS they are
in /dyn for the slave servers they are in /slave, they might also be
in /master. We only use the former two. All other sites are held in cache,
which is why we refer to a “caching server”. Here DNS is on 24-7 and never
(cross my fingers here and knock on wood) are more than one server down at a
time.
To be honest, I don’t think Bind was intended for the home user who reboots
frequently.
–
P. V.
“We’re all in this together, I’m pulling for you.” Red Green
On Fri, 20 May 2011 00:33:07 +0000, Carlos E. R. wrote:
> On 2011-05-19 19:12, Jim Henderson wrote:
>> you shouldn’t be
>> trying to work around the problem with a band-aid, but be working with
>> the ISP to figure out what the problem is to fix it permanently.
>
> Good luck talking to my ISP >:-P
Oh, yes, some ISPs can be very difficult to work with if you’re not using
Windows or Mac (I’ve experienced that myself on several occasions).
