BIND caching question: resolve vs forwarder

I run Slack 9.1 with SBC-DSL via dhcpcd talking to a Linksys router. The SBC
DNS is slow, so I have done a lot of reading on how to set up a name-only
caching DNS server with BIND. There is a lot of info out there (a lot of it
rather old.)

Some web pages say to add your ISP's nameservers to BOTH resolv.conf AND make
them "forwarders" in named.conf while others say only put them resolve. (And
a few pages say just make them forwarders and forget about resolve.conf.)

What is the story here?

Thanks,
Al

"Al. C" <(E-Mail Removed)> wrote in
news:cPtsd.38836$(E-Mail Removed). com:

> I run Slack 9.1 with SBC-DSL via dhcpcd talking to a Linksys router.
> The SBC DNS is slow,

Quantify slow.
What utility was used to arrive at the conclusion that SBC DNS is "slow"?

Why do you conclude that your own DNS server would be faster than SBc's?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Al. C wrote:
|
| Some web pages say to add your ISP's nameservers to BOTH
resolv.conf AND make
| them "forwarders" in named.conf while others say only put them
resolve. (And
| a few pages say just make them forwarders and forget about
resolve.conf.)

Aside from the comment about why you think they are slow in another
thread....

In general the prevailing view over in comp.protocols.dns.bind is
forwarders are an unnecessary complication for the vast majority of
set-ups anyway. I've benchmarked it for my connection and my ISP,
and it gives me a measurable improvement for my connection, so I
would consider using "forward-first" on my DNS server local to me,
but then my ISP doesn't have overloaded DNS servers.

If your ISPs DNS servers are overloaded, get an ISP with a clue, but
how you would establish this readily, unless you have a firm enough
grasp of DNS to be confident you aren't hitting misconfigured
domains, I've no idea.
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFBsoCvGFXfHI9FVgYRAvhOAJ9r38D4DLbwzpPKPwSD+I 8BjNvxoACfeFCC
gM6BJ1e+rkBFZSvfrOvPu2c=
=uv0i
-----END PGP SIGNATURE-----

In comp.os.linux.networking <cPtsd.38836$(E-Mail Removed) m> Al. C <(E-Mail Removed)> wrote:
> Some web pages say to add your ISP's nameservers to BOTH resolv.conf AND make
> them "forwarders" in named.conf while others say only put them resolve. (And
> a few pages say just make them forwarders and forget about resolve.conf.)

It depends on what you want to do. The resolver is the bit of library
code that lets applications talk to nameservers. resolv.conf tells
it what nameservers to talk to. named.conf tells a copy of BIND running
as a local nameserver how to work. The forwarders configuration in it
essentially says "instead of finding the answer yourself, forward the
query to _these_ other nameservers and get an answer from them". There's
also a switch to control whether or not, if it can't get an answer to a
forwarded query, it'll try it's normal "get the answer yourself" process.

I'd break the configurations down this way:

1. Put your ISP's nameservers in resolv.conf and do not run BIND locally.
This will have you depending entirely on your ISP for DNS. Results will
not be cached, so you'll have little insulation from problems on your ISP's
side. This is, however, the simplest since the DHCP client can automatically
update resolv.conf with whatever nameservers your ISP's DHCP server tells
it to. You won't have problems if your ISP changes nameservers without
warning.

2. Run a copy of BIND locally. Configure it to forward to your ISP's
nameservers and to only forward. Set resolv.conf to point to 127.0.0.1
as the only nameserver. This is often called a caching-only nameserver
configuration. You'll still depend on your ISP for DNS, but BIND will
cache results locally and answer out of it's cache when it can, so
you won't be as affected by glitches on your ISP's side. In this mode
you don't need to worry about the root-zone hints file or keeping it
up to date (not that it changes often).

3. Run a copy of BIND locally with a fully-configured root-zone hints
file. Set resolv.conf to point to 127.0.0.1 as the only nameserver.
This gives you a fully-functional nameserver operating completely
independently of your ISP. You'll need to occasionally check with
rs.internic.net and make sure you've got an up-to-date named.cache
hints file, but most distributions come with a current one and it
tends to go years between changes so this isn't too onerous. To
compensate for the little bit of trouble, you're pretty much immune
to DNS screw-ups by your ISP. The only thing you have to worry about
is complete loss of connectivity.

If you run a home LAN, if you take options 2 or 3 you can also set
BIND to listen on all interfaces and allow queries from local hosts
and nets, then set resolv.conf or the equivalent on all other machines
to point to the local IP address of the machine running BIND. That
way they all use it's nameserver.

--
All I want out of the Universe is 10 minutes with the source code and
a quick recompile.
-- unknown

IANAL_VISTA wrote:

> "Al. C" <(E-Mail Removed)> wrote in
> news:cPtsd.38836$(E-Mail Removed). com:
>
>> I run Slack 9.1 with SBC-DSL via dhcpcd talking to a Linksys router.
>> The SBC DNS is slow,
>
> Quantify slow.
> What utility was used to arrive at the conclusion that SBC DNS is "slow"?
>
> Why do you conclude that your own DNS server would be faster than SBc's?

That's a good question. All I can say is that over the past several weeks
(about 5) SBC has done something to their DNS servers such that resolution
has been much slower. On the www.dslreports.com site it has been documented,
but no one is very sure what they did.

My guess is that they cut the TTL parm down to nothing OR they have run out of
cache, making resolution much slower than it used to be. My bet is that they
simply eliminated a number of servers. I don't know. But I do know that 'new'
web pages take a lot longer to display than a few months ago.

<editorial>
SBC has, in my opinion, degraded their DSL service in the past 3 months to the
point where it is more cost-effective for them. I know the margins are small
and because they are a terribly inefficient company, they have had to make
changes to increase returns via reducing service. I expect that in my area
(Fair Oaks, CA (just outside of Sacramento) we will have a new competitor who
knows and understands both broadband and customer service.... Surewest
Communications.)
</editorial>

ANC

In article <Xmvsd.54651$(E-Mail Removed)> , Al. C wrote:

>That's a good question. All I can say is that over the past several weeks
>(about 5) SBC has done something to their DNS servers such that resolution
>has been much slower.

Look at the man page for 'dig' (the most over featured tool around). It
reports query time as part of the normal output. Second, use the '@server'
option to cause dig to use specific nameservers, and see if one is slow
or dead or whatever.

>My guess is that they cut the TTL parm down to nothing OR they have run out of
>cache, making resolution much slower than it used to be.

Running out of cache is a possibility - but not all that common. As for them
messing with TTL - look at the data you are getting back - all of the query
tools (dig, dnsquery, host, nslookup) can show the TTL. If the TTLs are
NOT something common (an hour, day, week, month - all in seconds), then
the nameserver probably has cached the data.

>My bet is that they simply eliminated a number of servers. I don't know.

Hard to say - have the servers in /etc/resolv.conf changed? Are they all
still working?

>But I do know that 'new' web pages take a lot longer to display than a few
>months ago.

Name resolution time is only part of the question.

>SBC has, in my opinion, degraded their DSL service in the past 3 months to
>the point where it is more cost-effective for them.

Yes, but if you also look in the news.admin.net-abuse.* newsgroups, you'll
also find an increasing number of complaints about SBC - maybe second only
to UU.net/MCI as being shunned. What you could ALSO be seeing is the result
of networks declining to accept connections from SBC.

Old guy

Moe Trin wrote:

> Yes, but if you also look in the news.admin.net-abuse.* newsgroups, you'll
> also find an increasing number of complaints about SBC - maybe second only
> to UU.net/MCI as being shunned. What you could ALSO be seeing is the result
> of networks declining to accept connections from SBC.
>
> Old guy

Thanks for the tips. I'll have to "dig around" with dig. But this much I can
tell you. I set up the name-only caching BIND server and I see a HUGE
difference on many (most) of the web sites I visit. Obviously, the first time
is slow, but subsequent hits are sometimes twice as fast (or seem so) as they
were before. For example, our own web page www.adams-blake.com is pretty
obscure and does not get many hits (as opposed to our www.jaya123.com page).
Thus, the IP is not likely to stay cached by SBC (as popular pages such as
newsforge or slashdot or a yahoo would). Before setting up the server if I
hit our home page at say 1 PM and tried it at 2 PM the second hit took just
as long as the first. Now subsequent hits just snap.

Since I keep this machine up 24/7 this is a good deal for me because the local
cache will not be purged.

Anyway, thanks again for all the help on this. All I can say is that if you
are in N. Calif. and are seeing latency in page resolution, try setting up
this caching server thing and see if it helps. It's working great for me.

Al C.
__________________________________________________ ________
Adams-Blake Company, Inc.
***
JAYA123 - the web-based total-office system for the
small biz. Order entry, billing, bookkeeping, etc. for $14.95
a month. Perfect for the small business or start-up.
See demo at: http://www.jaya123.com
***

In article <38Osd.54950$(E-Mail Removed)> , Al. C wrote:

>Thanks for the tips. I'll have to "dig around" with dig. But this much I can
>tell you. I set up the name-only caching BIND server and I see a HUGE
>difference on many (most) of the web sites I visit. Obviously, the first time
>is slow, but subsequent hits are sometimes twice as fast (or seem so) as they
>were before.

Like I say - look at the TTLs reported by the DNS query tools. Also look
at the reported response times from each name server using 'dig'. This
could also be a network congestion problem - /sbin/ifconfig might give
clues about that, as might tcpdump.

>For example, our own web page www.adams-blake.com is pretty obscure and
>does not get many hits (as opposed to our www.jaya123.com page).

You might want to talk to the hosting company, and perhaps whoever is
running your DNS for those sites. Both have the TTL set at 3600 (seconds)
or one hour. After that time, ANY name server should drop the cached
info. Now, when I looked, only one of the two authoritative name server
addresses were cached, and the TTL when I looked at that was 19645
seconds or about 5.5 hours (no idea what it might have started at, but
24 hours or even a week would not be unreasonable for a name server).
OK, just queried the other name servers address, and it has a TTL of
2 days for it's _own_ address. Both of yours are still at 3600 seconds.

>Since I keep this machine up 24/7 this is a good deal for me because the
>local cache will not be purged.

You want to re-read the DNS-HOWTO relating to cache times. If the
authoritative site for domain X says the TTL is 3600 seconds, that data
is gone in one hour, no matter if your system is up 8/5 or 24/7.

>All I can say is that if you are in N. Calif. and are seeing latency in
>page resolution, try setting up this caching server thing and see if it
>helps.

Usually, the ones that are helped the most by the caching name server are
those running windoze, because that O/S has diarrhea of the network, and
is CONSTANTLY badgering the name servers trying to find new hosts to share
with. Linux (or indeed virtually all Unix) don't have this problem. Because
I don't run windoze, and my ISPs seem to be reasonable, I haven't seen any
real difference in running a caching name server or not. But then again,
I'm not with SBC either.

Old guy

Moe Trin wrote:


> Usually, the ones that are helped the most by the caching name server are
> those running windoze, because that O/S has diarrhea of the network, and
> is CONSTANTLY badgering the name servers trying to find new hosts to share
> with. Linux (or indeed virtually all Unix) don't have this problem. Because
> I don't run windoze, and my ISPs seem to be reasonable, I haven't seen any
> real difference in running a caching name server or not. But then again,
> I'm not with SBC either.

SBC used to be much faster than it is now. Not sure why.

Here is a question. When you run a name-caching only server as I'm doing, what
happens when something like the following occurs.

site-A is at 1.1.1.1 and site-B is at 2.2.2.2. All is well. Then there is a
change.

Let's say they are swapped to that now
site-A is at 2.2.2.2 and site-B is at 1.1.1.

If I ask for www.site-A.com my internal table will resolve to 1.1.1.1 but I
will NOW get site-B. How does BIND get around this issue? Is the answer to
simply "killall named" and restart it every week or two? Seems to defeat the
purpose of createing a cached name=>IP-Address table. Read all the HOWTO docs
and didn't see anything about this.

Thanks,

Al

Al. C <(E-Mail Removed)> wrote:
> site-A is at 1.1.1.1 and site-B is at 2.2.2.2. All is well. Then there is a
> change.
>
> Let's say they are swapped to that now
> site-A is at 2.2.2.2 and site-B is at 1.1.1.
>
> If I ask for www.site-A.com my internal table will resolve to 1.1.1.1 but I
> will NOW get site-B. How does BIND get around this issue? Is the answer to
> simply "killall named" and restart it every week or two? Seems to defeat the
> purpose of createing a cached name=>IP-Address table. Read all the HOWTO docs
> and didn't see anything about this.

Find a good book on BIND (like the O'Reilly one) and read the chapter on
TTLs.

--
Frank Sweetser fs at wpi.edu
WPI Network Engineer
GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC