Redhat likes to put your options in named.custom. In your named.conf, you should see a line like:
include "named.custom";
this is the point where that file gets inserted into named.conf - you can merge the two together by copying the contents of named.custom, then pasting the entire contents over that line. Not saying to do that, just giving you an idea of how that works.
In one of these two files you should have a block that states something like:
Code:
controls {
inet 127.0.0.1 allow { localhost; 192.168.1.0/24; } keys {rndckey; };
};
This block states that the nameserver listens on 127.0.0.1 (localhost) and that localhost (or 127.0.0.1) and the entire class C network 192.168.1.xxx (denoted by the 0 on the end) have access to the nameserver using the security key stored in rndckey.
In either your named.conf or, more likely if a RedHat GUI created this, in your named.custom file, you should have an options block such as:
Code:
options {
directory "/var/named/";
listen-on { 127.0.0.1; 192.168.1.1; };
allow-query { 127.0.0.1; 192.168.1.0/24; };
};
From the first line, this states that:
directory "/var/named/"; = Your per-domain configuration files are stored in /var/named/
listen-on { 127.0.0.1; 192.168.1.1/24; }; = The nameserver listens on 127.0.0.1 and 192.168.0.1
allow-query { 127.0.0.1; 192.168.1.0/24; }; = The nameserver will accept queries from the entire 192.168.1.0 class C network as well as localhost (127.0.0.1).
Note that your values for each of these blocks may be different (and probably are) depending on your exact network setup, these are just educated guesses for what should be there.
If all that looks right, open each of your zone files and check the serial numbers - make sure they're all different. RedHat likes to make zone files with serial numbers like "2" but standard practice is to use the date (YYYYMMDD), followed by 2 digits for the number of modifications for that date. So if you rewrote the zone file 8 times today, the serial number would be 2004090808 - this has the added bonus of letting you know the last time you edited a particular zone. More importantly, it increments the serial number, which nameservers will use if there gets to be a cache contest between 2 nameservers with varying records.
Try to ping one of your domain names from the nameserver box. If you can ping a domain that's only specified in that nameserver (ie, not google.com, but perhaps testdomain.cxm - note the "x"). If you can do that, the nameserver is working.
On the client machines (the machines that are supposed to be using this nameserver), be sure you've set that server as it's primary DNS. Use your ISP's nameserver as a secondary just in case yours goes down (so it won't cut out your whole network because nothing resolves). Then try to ping your testdomain.cxm from that machine. If that works, you've got it set up right.
As to nslookup - ignore the statement about it being depreciated. I guess these days you're supposed to use dig instead of nslookup - but I've always gotten everything I've ever needed from nslookup, and you will too if you're configured right.
when you start nslookup from the nameserver box, type in:
server
and hit enter. This will give you your list of nameservers. You can always change servers by doing:
server 192.168.1.1
or
server ns.mynameserver.com
Once you've made sure you're querying your nameserver, do:
set q=ANY
testdomain.cxm
this should spit out a zone transfer - a listing of all of the records within the testdomain.cxm domain that you are authoratative for, ie: mail servers, nameservers, ect.
I got a bit more wordy than I had planned, but perhaps it'll help you (or someone else) out.
This
