Re: Nameserver Problem

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

 



At 4:18 PM +0930 3/30/07, Tim wrote:
>It's nice to be held in such high regard, but I'm not the only one who
>plays with BIND...
>
>On Thu, 2007-03-29 at 17:46 -0400, Tony Nelson wrote:
>> Tim -- is this also a solution for my problem?  I have set up a local
>> server (on CentOS 4.4) to test a replacement for a real server with a
>> domain name (running RH 7.2).  The local server should always resolve
>> that domain name to itself, so as to properly test itself and not the
>> real server.
>
>Once you set up zone records on a machine, it'll use them instead of
>trying externally, as it already has an answer for queries (even if its
>a null answer).  I do this for advert busting.  I have a series of
>configuration entries for annoying domain names that'll return null
>answers for the network.  That gets rid of various web browsing
>annoyances, centrally.
>
>I added a series of lines like the following to my lan.conf file:
>
>zone "adimages.com"             { type master; file  "dead.zone"; };
>zone "admonitor.com"            { type master; file  "dead.zone"; };
>zone "adsfac.net"               { type master; file  "dead.zone"; };
>zone "advertising.com"          { type master; file  "dead.zone"; };
>zone "amazingmedia.com"         { type master; file  "dead.zone"; };
>
>Which causes any queries for those domains to get *MY* answer, not the
>one from their real master servers.  The "dead.zone" file as as follows,
>it produces a "no answer" result, causing instant death for the attempt
>to browse to it.
>
>$TTL 86400
>@       IN      SOA     ns.localdomain.  hostmaster.mail.localdomain. (
>                        200 ; serial
>                        28800 ; refresh
>                        7200 ; retry
>                        604800 ; expire
>                        86400 ; ttl
>                        )
>
>
>        IN      NS      ns.localdomain.
>
>And that's the whole thing, there's no further entries in it.  It works
>better than wildcarding, or playing with hosts files, as that directs
>queries to somewhere else, rather than aborting them.
>
>The same applies if you provide real answers for a domain.  They'll be
>used, instead of going out on the internet to get the records.
 ...

Thanks.  I've installed bind and caching-nameserver.  I put lines like

    zone "mydomain.com" { type master; file "localhost.zone"; };

into named.conf and informed named with a kill SIGHUP.  The computer gets
its IP address via DHCP, so I added a line to /etc/dhclient-the0.conf

    supersede domain-name-servers 127.0.0.1;

and then flapped the interface with

    # ifdown eth0 ; ifup eth0

in order to get /etc/resolv.conf to use the caching nameserver.  I was
reminded that it is important to do both commands on one line if
admistering "remotely".  There might also be a simpler way to do it.

Named is working properly, but I'm a bit uncomfortable about not having
defined any nameservers to use.  Presumably it's just asking the root
nameservers.  I could hard-code what DHCP would return, but I wonder if
there is a way to get that info into named automatically?
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson@xxxxxxxxxxxxxxxxx>
      '                              <http://www.georgeanelson.com/>


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux