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.
> Just adding lines to /etc/hosts was insufficient, probably because DNS
> queries (dig, nslookup) still see the real server.
Various things will ignore the hosts file, I've it's best to avoid using
it for all but the most basic of things (such as the machine's own
addresses, if they're static, so it can run disconnected from the
network without complaints).
> I'm trying to avoid really understanding BIND at this time, as I have
> plenty of other issues to deal with, and the new server, when
> deployed, won't need this testing DNS configuration.
Understanding DNS is an important part of networking, understanding how
BIND does its tricks, on top of that, is yet another thing worth finding
out about.
--
(This box runs FC5, my others run FC4 & FC6, in case that's
important to the thread.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
