Nameserver Problem

[mike]

I have caching-nameserver running on FC6.  No matter what I do it will 
note recognizea zone set as a Slave.

The whole purpose of this machine is to be a secondary DNS.

Any comments?

Mike Dwiggins

_________________________
This email was transferred using an Office free edition
of AXIGEN Mail Server.

[Ed Greshko]

Mike Dwiggins wrote:
> I have caching-nameserver running on FC6.  No matter what I do it will 
> note recognizea zone set as a Slave.
>
> The whole purpose of this machine is to be a secondary DNS.
>
> Any comments?

Yes, a caching nameserver is not a secondary server.

Go to /usr/share/doc/bind-*/arm and read the documentation.

[mike]

Ed,

Read that.  Now for a newbie how do I go from a caching-nameserver to 
regular bind.

The only way I could get yum to install bind was to call for the 
caching-nameserver.

Mike Dwiggins

Ed Greshko wrote:
> Mike Dwiggins wrote:
> > I have caching-nameserver running on FC6.  No matter what I do it 
> > will note recognizea zone set as a Slave.
> >
> > The whole purpose of this machine is to be a secondary DNS.
> >
> > Any comments?
>
> Yes, a caching nameserver is not a secondary server.
>
> Go to /usr/share/doc/bind-*/arm and read the documentation.

_________________________
This email was transferred using an Office free edition
of AXIGEN Mail Server.

[Kam Leo]

On 3/28/07, Mike Dwiggins  wrote:
> Ed,
>
> Read that.  Now for a newbie how do I go from a caching-nameserver to
> regular bind.
>
> The only way I could get yum to install bind was to call for the
> caching-nameserver.

As I stated in your other thread: `yum install bind`
> Mike Dwiggins
>
> Ed Greshko wrote:
> > Mike Dwiggins wrote:
> > > I have caching-nameserver running on FC6.  No matter what I do it
> > > will note recognizea zone set as a Slave.
> > >
> > > The whole purpose of this machine is to be a secondary DNS.
> > >
> > > Any comments?
> >
> > Yes, a caching nameserver is not a secondary server.
> >
> > Go to /usr/share/doc/bind-*/arm and read the documentation.
>
> This email was transferred using an Office free edition
> of AXIGEN Mail Server.
>
> --
> fedora-list mailing list
> [e-mail]
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

[Ed Greshko]

Mike Dwiggins wrote:
> Read that.  Now for a newbie how do I go from a caching-nameserver to 
> regular bind.
>
> The only way I could get yum to install bind was to call for the 
> caching-nameserver.

If you were to look closely you'd find out that the caching-nameserver 
contains only the following:

/etc/named.caching-nameserver.conf
/etc/named.rfc1912.zones
/usr/share/doc/caching-nameserver-9.3.2
/usr/share/doc/caching-nameserver-9.3.2/Copyright
/usr/share/doc/caching-nameserver-9.3.2/rfc1912.txt
/var/named/localdomain.zone
/var/named/localhost.zone
/var/named/named.broadcast
/var/named/named.ca
/var/named/named.ip6.local
/var/named/named.local
/var/named/named.zero

In other words, the caching-nameserver package contains *only* the 
configuration files used to make bind a "caching nameserver".  In still 
other words, the only difference between a "caching nameserver" and an 
"authoritative nameserver" is the configuration file.

I suspect bind is really installed.

So, go back to the documentation and read the part about setting up the 
configuration file.  I believe there is already an example in the doc that 
has a sample of a server acting as a "slave" server.

Ed

[Tim]

On Wed, 2007-03-28 at 16:46 -0700, Mike Dwiggins wrote:
> I have caching-nameserver running on FC6.  No matter what I do it will
> note recognizea zone set as a Slave.
>
> The whole purpose of this machine is to be a secondary DNS.

I think you'll have to explain what you've tried.  A very brief synopsis
of how I've done what you're trying (run a caching name server, also as
a slave server for local DNS) follows:

I added two configuration files, and left the remaining ones as they
were:

My "/var/named/chroot/etc/named.conf" file:

---------------[begin paste]------------------
## LAN:

view  lan_resolver {
        match-clients      { localhost; };
        match-destinations { localhost; };
        include "/etc/lan.conf";
        include "/etc/rndc.key";
};

include "/etc/named.caching-nameserver.conf";

## end of file
---------------[end paste]------------------

You'd want to customise where my example uses "localhost" to suit the
networks you're going to allow to query the server.

And my "/var/named/chroot/etc/lan.conf" file:

---------------[begin paste]------------------
## LAN:

zone "lan.example.com" {
        type slave;
        file  "slaves/lan.example.com.zone";
        masters { 192.168.1.2; };
};

zone "1.168.192.in-addr.arpa" {
        type slave;
        file  "slaves/1.168.192.in-addr.arpa.zone";
        masters { 192.168.1.2; };
};

---------------[end paste]------------------

Then my slave zone files get created, automatically in
"/var/named/chroot/var/named/slaves".  And that's it...

[Tony Nelson]

At 2:25 PM +0930 3/29/07, Tim wrote:
> On Wed, 2007-03-28 at 16:46 -0700, Mike Dwiggins wrote:
> > I have caching-nameserver running on FC6.  No matter what I do it will
> > note recognizea zone set as a Slave.
> >
> > The whole purpose of this machine is to be a secondary DNS.
>
> I think you'll have to explain what you've tried.  A very brief synopsis
> of how I've done what you're trying (run a caching name server, also as
> a slave server for local DNS) follows:
>
> I added two configuration files, and left the remaining ones as they
> were:
>
> My "/var/named/chroot/etc/named.conf" file:
>
> ---------------[begin paste]------------------
> ## LAN:
>
> view  lan_resolver {
>        match-clients      { localhost; };
>        match-destinations { localhost; };
>        include "/etc/lan.conf";
>        include "/etc/rndc.key";
> };
>
> include "/etc/named.caching-nameserver.conf";
>
> ## end of file
> ---------------[end paste]------------------
>
> You'd want to customise where my example uses "localhost" to suit the
> networks you're going to allow to query the server.
>
> And my "/var/named/chroot/etc/lan.conf" file:
>
> ---------------[begin paste]------------------
> ## LAN:
>
> zone "lan.example.com" {
>        type slave;
>        file  "slaves/lan.example.com.zone";
>        masters { 192.168.1.2; };
> };
>
> zone "1.168.192.in-addr.arpa" {
>        type slave;
>        file  "slaves/1.168.192.in-addr.arpa.zone";
>        masters { 192.168.1.2; };
> };
>
> ---------------[end paste]------------------
>
> Then my slave zone files get created, automatically in
> "/var/named/chroot/var/named/slaves".  And that's it...

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.  Just adding lines to /etc/hosts was insufficient, probably because
DNS queries (dig, nslookup) still see the real server.  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.

[Ed Greshko]

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.  Just adding lines to /etc/hosts was insufficient, probably because
> DNS queries (dig, nslookup) still see the real server.  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.

If you don't want to understand named and how to configure it then try the 
following.

1.  Remove the /etc/resolv.conf
2.  Create a /etc/hosts file that contains all of the information needed and 
that includes all of the servers that host may need to contact for testing 
purposes.
3.  Edit the /etc/nsswitch and change the "hosts" line to have "files" only.

[Tony Nelson]

At 6:31 AM +0800 3/30/07, Ed Greshko wrote:
> 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.  Just adding lines to /etc/hosts was insufficient, probably because
> > DNS queries (dig, nslookup) still see the real server.  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.
>
> If you don't want to understand named and how to configure it then try the
> following.
> Remove the /etc/resolv.conf
> Create a /etc/hosts file that contains all of the information needed and
>
> that includes all of the servers that host may need to contact for testing
> purposes.
> 3.  Edit the /etc/nsswitch and change the "hosts" line to have "files" only.

Thanks, but that wasn't the question, and it raises its own difficult
questions.  I'll wait for Tim.

[Ed Greshko]

Tony Nelson wrote:
> > Remove the /etc/resolv.conf
> > Create a /etc/hosts file that contains all of the information needed and
> >
> > that includes all of the servers that host may need to contact for testing
> > purposes.
> > 3.  Edit the /etc/nsswitch and change the "hosts" line to have "files" only.
>
> Thanks, but that wasn't the question, and it raises its own difficult
> questions.  I'll wait for Tim.

Gee....

OK, the question was how can I set up a nameserver without knowing or 
wanting to know anything about a nameserver and without reading and 
understanding the documentation.

Then, yes, please wait for someone to do it for you.

[Tim]

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.

[Bob Goodwin]

Tim wrote:
> 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.

I don't find a "lan.conf" file but I do have the following.  Which one, 
if any, can I operate on to eliminate the loading of those darned 
links?  My satellite connection has an inherent delay and waiting for 
six or eight ad links to be dealt with that I never view is maddening!  
The caching-nameserver works well enough once it looks up an address but 
there's still the time wasted collecting data that is never displayed, 
eliminated from Firefox by 'Adblock' and 'Flashblock.'

/etc/named.rfc1912.zones
        /usr/share/doc/bind-9.3.4/sample/etc/named.rfc1912.zones
        /usr/share/doc/bind-9.3.4/sample/var/named/localdomain.zone
        /usr/share/doc/bind-9.3.4/sample/var/named/localhost.zone
        /usr/share/doc/bind-9.3.4/sample/var/named/my.external.zone.db
        /usr/share/doc/bind-9.3.4/sample/var/named/my.internal.zone.db
        /usr/share/doc/bind-9.3.4/sample/var/named/slaves/my.ddns.internal.zone.db
        /usr/share/doc/bind-9.3.4/sample/var/named/slaves/my.slave.internal.zone.db
        /var/named/localdomain.zone
        /var/named/localhost.zone
        /var/named/chroot/etc/named.rfc1912.zones
        /var/named/chroot/var/named/localdomain.zone
        /var/named/chroot/var/named/localhost.zone

Thanks.

Bob Goodwin   Zuni, Virginia

[Tony Nelson]

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?

[Tim]

On Sat, 2007-03-31 at 13:31 -0400, Bob Goodwin - W2BOD wrote:
> I don't find a "lan.conf" file but I do have the following.  Which
> one, if any, can I operate on to eliminate the loading of those darned
> links?

Go back into this thread to my posting before that one, and see the two
custom files of mine.  That lan.conf is something I put in there,
myself.  The reason being that modifying original files can cause you
problems when you update bind.  Your modifications may disappear.
Writing them externally means that the most you have to do to get them
back is insert an include line, rather than redo all the other things
you did.

With the current version of BIND, it looks like it doesn't come with the
default named.conf file, and will start off using the other ones it
comes with, if it doesn't find one.  I put in a named.conf file, and
make it refer to the other files (with an include).

[Tim]

On Sat, 2007-03-31 at 23:39 -0400, Tony Nelson wrote:
> 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.

Yes, it's acting as a stand-alone name server.  Probably the best way to
use it, for simplicity's sake.
> I could hard-code what DHCP would return, but I wonder if there is a
> way to get that info into named automatically?

I wouldn't bother, nor would I recommend changing named.conf all the
time.  If you really wanted, you could play with adding forwarders to
your configuration file, either to always be used for looking up
external addresses, or for when it can't find an answer by itself.

[Tony Nelson]

At 3:14 PM +0930 4/1/07, Tim wrote:
> On Sat, 2007-03-31 at 23:39 -0400, Tony Nelson wrote:
> > 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.
>
> Yes, it's acting as a stand-alone name server.  Probably the best way to
> use it, for simplicity's sake.

Certainly it is good enough for the present use.
> > I could hard-code what DHCP would return, but I wonder if there is a
> > way to get that info into named automatically?
>
> I wouldn't bother, nor would I recommend changing named.conf all the
> time.  If you really wanted, you could play with adding forwarders to
> your configuration file, either to always be used for looking up
> external addresses, or for when it can't find an answer by itself.

OK.  Maybe when I understand about forwarders.