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 | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


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

named



On Tue, Nov 30, 2010 at 7:28 AM, Cole Tuininga <colet-KCgK2vT7wad/90uGnh1m2w at public.gmane.org> 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.

Which turns out to be very useful, if you want to assign names to
RFC1918 IP addresses.   I resolve forward lookups for a fake TLD to
10.* IPs,  as well as the matching reverse lookups on my home network.
 On the off chance that my consumer IP provider gives different
answers for requests that trace the chain from the root then they do
from the recursive nameservers I get via DHCP, I elect to forward
requests for all other domains to my provider's nameservers rather
then talking to the root.   If they screw up, I can easily comment out
the forwarders section in my BIND config file and restart
the daemon.

Admittedly I haven't considered how DNSSEC affects this setup.

Bill Bogstad







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