Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

named



On 11/30/2010 07:28 AM, Cole Tuininga wrote:
> On 11/29/2010 10:29 PM, Stephen Adler wrote:
>> I've been having trouble with verizon's domain name servers, so I
>> decided to fire up a caching domain name server.
> [snip]
>
>> I then thought I should have my named query the verizon dns servers
>> instead of hitting the root servers and when I did, I got a bunch of the
>> following errors...
> I'm a bit confused what you're trying to accomplish here.  The only
> reason I can imagine for putting your own caching resolver between you
> and the ISP resolver is if you wanted to override the records for a
> particular zone for some reason.
>
> I suggest that if you're going to use a caching resolver (especially one
> with DNSSEC turned on) that you go right to the root servers.
>
> *Puts on his dyn.com employee hat*
>
> However, if you're having trouble with your ISPs resolvers (much like
> Comcast subscribers a couple days ago), I recommend trying out dyn.com's
> Internet Guide service.  Simpler than running your own recursive, and
> you get a few nifty features for free.
>
> http://www.dyndns.com/services/dynguide/
>
It's because Verizon is unreliable with their DNS servers, thus the need 
for some kind of caching dns system. About every couple of months, their 
DNS servers go down or become unresponsive for about 24hrs. Thanks for 
the dyndns.com link. I'll check it out.

Cheers. Steve.






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org