Hello all,

I am posting this thread as a last step. I have searched the internet for the answer, but it seems that I have a unique issue.
I have a name caching/internal/DHCP dynamically updating DNS server that is using BIND 9.3.2 on fc5. The hosts are configured with the primary DNS server as their DNS caching server on the linux box. The DHCP server is updating the DNS. When I ping from a host to a website I get the response that I would except. (Host gets DNS query answer from the linux box) Here is where it gets odd, the results never actually come from the linux box, there are coming from my ISP dns servers. (Confirmed using wireshark) Here is another good one, if I ping an internal host from the linux box, it goes for the root servers, and I get flooded with black hole responses. I have played with several forwarder options, but none seem to work, its goes to the root servers to resolve internal IPs. Also none of the dump files and stats files or being created or used by the named service.(ie dump-file var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt" The /var/named dir only has the root hints, and the three zone files. If I dig myself I get the root hints response.

Any ideas?

Thank everyone!!

Here are the conf files.....

resolv.conf

search mydomain.local
nameserver 192.168.1.254
nameserver 127.0.0.1

dhcpd.conf

default-lease-time 86400;
max-lease-time 604800;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option netbios-name-servers 192.168.1.254;
option domain-name "mydomain.local";
ddns-updates on;
ddns-update-style interim;
ddns-domainname "mydomain.local.";
ddns-rev-domainname "0.0.127.in-addr.arp";

key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret my_key_here;
};

zone mydomain.local. {
primary 127.0.0.1;
key DHCP_UPDATER;
}

zone 0.0.127.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
allow client-updates;
range 192.168.1.10 192.168.1.50;
option domain-name-servers 192.168.1.254;
}

named.conf

options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
forwarders {68.9.16.30;68.9.16.25; };
#forward first;

controls {
inet 127.0.0.1 allow { localhost; };
};

zone "." IN {
type hint;
file "named.ca";
};
key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret my_key_here;
};

zone "mydomain.local" {
type master;
file "mydomain.local";
allow-update { key DHCP_UPDATER; };
};

zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
allow-update { key DHCP_UPDATER; };
};

I truely hope I didnt stump everyone, there are the best forums that I know of! I really could use a hand, no thoughts??

1) We need to see the zone file for mydomain.local. In particular, have you specified the SOA and NS records for mydomain.local.

2) Are you sure the zone file mydomain.local is loading when named is started? i.e. check /var/log/messages

3) Since you are using DHCP (nsupdate) to update mydomain.local, is the journal file being created for mydomain.local

4) Why are you using DHCP to update 127.0.0?

5) Where is the in-addr.arpa zone for 192.168.1.0/24 network? Without this zone, all reverse lookup queries would go to roots which would return the standard prisoner.iana,org replies.

6) Have you run rndc to create the dump and stats file?

Hint: If named does not think its authoritative for a zone (mydoamin.local), then it would query the forwarders or roots for name resolution. At the very least, the zone file for mydomain.local needs an SOA, NS rand glue ecords defined that point to your server. Then named (nsupdate) can maintain the zone file dynamically.

Thank you for your reply scowles!!

1. Here are the zones files.

"mydomain.local" zone file

$ORIGIN .
$TTL 86400 ; 1 day
mydomain.local IN SOA Mulletkiller.mydomain.local. root.mydomain.local. (
55 ; serial
10800 ; refresh (3 hours)
900 ; retry (15 minutes)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS localhost.mydomain.local.
$ORIGIN mydomain.local.
$TTL 3600 ; 1 hour
Host1 A 192.168.1.48
TXT "SerailizedTxtFileName"
$TTL 300 ; 5 minutes
Host2 A 192.168.1.49
TXT "SerailizedTxtFileName"
$TTL 86400 ; 1 day
localhost A 127.0.0.1
$TTL 300 ; 5 minutes
Host4 A 192.168.1.46
TXT "SerailizedTxtFileName"
Host5 A 192.168.1.20
TXT "SerailizedTxtFileName"

"named.local" zone file

cat named.local
$TTL 86400
@ IN SOA localhost. root.localhost. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.


2. Yes the "mydomain.local zone file is loading.
Output from messages
Oct 8 13:17:19 Mulletkiller named[1690]: command channel listening on 127.0.0.1#953
Oct 8 13:17:19 Mulletkiller named[1690]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
Oct 8 13:17:19 Mulletkiller named[1690]: zone mydomain.local/IN: loaded serial 55
Oct 8 13:17:19 Mulletkiller named[1690]: running

3.Yes the journal file is created and is being updated.

4.Loopback for reverse lookup? (maybe a issue...)

5.No, I have not run rndc to create the dump and stats file. Just "touch"ing a file with that name doesnt do it?

Your hint I think is another point of my confusion. I have not read any dns option command that would make it authoritative for a zone, So, I assumed it was a default behavior.

Once again thank you for your reply.

'type master;' in the zone definition makes it authoritative.

For DHCP (or anything) to update a reverse lookup zone it has to get the zone from the IP address. Therefore if you are allocating DHCP addresses in the 192.168.1.xxx range and want them added to a reverse lookup zone file that zone file has to exist and be defined in named.conf (1.168.192.in-addra.arpa)

Rather than mucking about with the localhost zones I'd set up new forward and reverse zones and check your logs to make sure DHCP is updating DNS correctly.