CentOS 4.8, BIND 9.2.4, DHCP 3.0.1
Hi All:
I have a rather perplexing problem where the DNS entry in BIND for one of my network printers sporadically "disappears" from our zone file (but not the reverse zone file). We have four Lexmark printers connected locally over our internal LAN using static IP addresses. We have 3 T640n printers and a T642n printer and it is only the T642n printer that this is happening to.
I thought I had it licked when I discovered that both DDNS and mDNS were enabled on this printer but not the others, however disabling those has had no effect.
We do use DHCP for the bulk of our Windows workstations and DHCP is configured to update the DNS server and this appears to work fine (once I disabled all the "Register this connection's address in DNS" options on the workstations).
I have found one suspicious entry in /var/log/messages:
Apr 12 17:34:14 fisds0 named[5210]: client 192.168.2.7#10242: updating zone 'forsoft.com/IN': deleting an RR
This would seem to indicate that the printer itself has issued the request to the DNS server but for the life of me I cannot see what might be doing it.
Has anyone encountered something similar and can point me in the right direction?
TIA
Regards, Hugh
From: Hugh E Cruickshank Sent: April 13, 2010 15:07
I have found one suspicious entry in /var/log/messages:
Apr 12 17:34:14 fisds0 named[5210]: client 192.168.2.7#10242: updating zone 'forsoft.com/IN': deleting an RR
This would seem to indicate that the printer itself has issued the request to the DNS server but for the life of me I cannot see what might be doing it.
One additional piece of information... It appears that I had not set the DNS server and NTP server correctly on all four printers and they were running with a very old date (would you believe 1970?). I have since ensured that all four printers now have the correct DNS server IP address, the host name of our local NTP server, the correct time zone and that they all now have the correct current date and time via NTP.
I am not sure if this would have had anything to do with the DNS issue but it was something that was obviously wrong and needed to be fixed.
Regards, Hugh
On Tue, Apr 13, 2010 at 6:07 PM, Hugh E Cruickshank hugh@forsoft.com wrote:
I have found one suspicious entry in /var/log/messages:
Apr 12 17:34:14 fisds0 named[5210]: client 192.168.2.7#10242: updating zone 'forsoft.com/IN': deleting an RR
This would seem to indicate that the printer itself has issued the request to the DNS server but for the life of me I cannot see what might be doing it.
This means a couple things. First, your zone is configured to allow dynamic DNS updates, which can be okay, but usually you don't want this for a zone containing fixed records.
Second, it means that client updates is allowed. This can be bad, and generally when I set up dynamic DNS zones, I only allow updates from the dhcp server (usually the same box, so it's restricted to localhost doing the updating).
Essentially your printer is trying to update its record and removing the old one, but not publishing the right one, either through permissions or some other reason.
Has anyone encountered something similar and can point me in the right direction?
How do you have your zones and/or dhcp server configured? Can you sanitize them enough to post them?
From: Jim Perrin Sent: April 13, 2010 17:01
This means a couple things. First, your zone is configured to allow dynamic DNS updates, which can be okay, but usually you don't want this for a zone containing fixed records.
That was intentional on my part. We have a small network and I did not see any compelling reason not to do it that way. I will look at separating these out in the future.
Second, it means that client updates is allowed. This can be bad, and generally when I set up dynamic DNS zones, I only allow updates from the dhcp server (usually the same box, so it's restricted to localhost doing the updating).
Again intentional but no longer required. In reviewing the config files in response to your comments I see that had allowed update to the zone file from the entire subnet while only "key rndckey" for the reverse zone files. That would explain why only the zone file was affected and not the reverse files. I have fixed that now and I think that should resolve my problem.
Essentially your printer is trying to update its record and removing the old one, but not publishing the right one, either through permissions or some other reason.
Sounds valid.
How do you have your zones and/or dhcp server configured? Can you sanitize them enough to post them?
I will hold off for now as I believe the change that I have made to named.conf will now avoid the problem. I still do not know why only the one printer was affected but the change should avoid the problem. Some day when I have some free time (yeah right!) I am try to figure what the actual cause is.
Thanks very much for your comments, they are greatly appreciated.
Regards, Hugh
-
Hugh E Cruickshank -
Jim Perrin