enable DNS

Don Dupy fedora at maxxrad.net
Sun Jun 13 16:17:02 UTC 2004


I guess everyone looks at it different.

I for one query the root name servers for my network
I have 1 PC that uses dns at any one time.

I guess I can see the point if you have a 2,000 PC network, you should do
caching dns, and at least take some of the load off the root
servers. Good point there.

I work for an ISP, and I am sure they do a boatload of caching for our
customers before querying the root servers.

But, if your ISP's DNS servers go down, its nice to know you can query the
root servers. Alot of ISP's probably use M$ servers, and we know they
never go down........ HAHA.

I have worked for this ISP for 4 yrs and I don't think the DNS servers
have ever went down. (Linux of course)  ;-)

Don Dupy
Systems Administrator
Maxxrad PC Services
http://www.maxxrad.net
email: fedora at maxxrad.net

On Sat, 12 Jun 2004, Mark Mielke wrote:

> On Sat, Jun 12, 2004 at 07:16:16PM -0600, Rodolfo J. Paiz wrote:
> > Kenneth, while your comment is technically correct, in my not-so-humble
> > opinion it is a very poor recommendation to give others. Having every
> > nickel-and-dime home network go straight to the root servers is going to
> > create exponential growth of the load on those servers; the fact that large
> > backbone providers serve ISP's who in turn serve their customers is one of
> > the things that helps make the Internet scalable.
>
> > For the huge majority of people, the *proper* way to configure a
> > caching-nameserver is to set up one or two forwarders to be checked first
> > before going to the root servers. The additional penalty in speed is in
> > milliseconds (which those small networks won't even notice), and the
> > potential for cache poisoning, while real, is also tiny. I very, very
> > strongly disagree with your advice: it is technically correct and valid,
> > but sadly lacking in netiquette and good network design.
>
> I believe you are exaggerating the case. Anybody who uses DHCP (I
> expect this to be the strong majority of all users, even once IPv6
> becomes common) will use the settings defined by their ISP. The
> people who are left, are a minority.
>
> The perceived benefit of directing this minority of people through an ISP's
> name server is the assumption that DNS queries performed have a chance of
> already being in the ISP's name server cache.
>
> In my case, most of my DNS lookups are DNSBL failures. These are not
> likely to be cached by the ISP's name server cache, nor perhaps,
> should they be.
>
> For the rest of us with broadband access, the time saved doing the lookups
> directly *is* noticable. In fact, in my case, I am actually located
> network-closer to the root domains severs, than my ISP's domain name
> server is (this is something that they may fix in the future).
>
> More recently, I've experienced the problem that my ISP's domain name
> server was down (no route to host). I had thought I could handle this
> case. My name server would fallback to the root domain servers for
> resolution. It doesn't work. My DNS clients time out before my name
> servers times out doing a recursive lookup through the ISP's domain
> name server (that it cannot contact).
>
> Using the ISP's domain name server for networks such as mine are asking
> for trouble.
>
> In terms of a recommendation, I would recommend that any users who don't
> know what they are doing, should use DHCP, and allow the ISP to configure
> /etc/resolv.conf for them. For the rest of us, using the ISP's name server
> is not going to save anybody anything. Sure, common queries such as
> yahoo.com or google.com are going to be cached. Big deal.
>
> mark
>
> --
> mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________
> .  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
> |\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   |
> |  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
>
>   One ring to rule them all, one ring to find them, one ring to bring them all
>                        and in the darkness bind them...
>
>                            http://mark.mielke.cc/
>
>
> --
> fedora-list mailing list
> fedora-list at redhat.com
> To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
>





More information about the fedora-list mailing list