Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

HP Printer Drops Out Of DNS

Status
Not open for further replies.

iainwatt

MIS
Feb 25, 2002
58
GB
Hello all,

I have a strange issue that is causing me some grief.

First off before I go any further my background is in networking and not servers. In fact I don't have access to the DNS servers or DHCP servers I'm about to ask about but my server team are pointing their fingers at the network for the problem I am about to describe. I just wanted anyone some advice or a solution to the problem if anyone has it.

The issue:
Some of our HP printers (various models) are dropping out of DNS. They obtain a DHCP address that has been reserved by MAC address from a Windows 2008 R2 server. The lease is 8 days and is active as the printer is responsive.

DNS is updated via DHCP as you would expect as this is how it is setup. DNS is on seperate servers from DHCP. However, without rhyme or reason the DNS entry gets lost by DNS randomly, sometimes over night sometimes during the day, well within the DHCP lease time. Once this happens people that print to the DNS name are left wanting. A reboot of the printer or shutdown of the switchport forces DHCP process to happen and the of course updates DNS and all is good again.

So the question is why is DNS dropping the record even though DHCP has an active lease and the client is indeed active?
 
The DNS and DHCP servers will both have their own time to live values. If the DNS server is set to expire registrations in less time than the DHCP lease it could explain why these entries are getting flushed.

Take a look at your DNS and check the SOA record. You should see something like this:
Code:
 IN SOA  machine.domain. (
                                20100628100 ; serial
                                4800       ; refresh (1 hour 20 minutes)
                                86400      ; retry (1 day)
                                2419200    ; expire (4 weeks)
                                604800     ; minimum (1 week)
                                )

Make sure the values, which are defined in seconds, are sane compared to the DHCP lease.
 
Hello Noway2,

Thanks for your reply, I'll try and get the server guys to look at this. Before I do though what would you say would be sane times for an 8 day lease?
 
That is a really good question. My experience with the DHCP and DNS is limited to my own system and I use the values posted in my earlier message.

In my case, I have multiple machines, many of which are on 24/7/365. I have recently been upgrading my configurations as I obtained a set of static IP addresses and implemented a couple of public facing servers, including hosting my own DNS for the zone.

The only problem that I have had is that I changed the IP address of one of the servers recently and the name server at work cached the old address for a few days. All other public queries gave the new result almost immediately.

According to wikipedia:
A common TTL value for DNS is 86400 seconds, which is 24 hours. A TTL value of 86400 would mean that if a DNS record was changed, DNS servers around the world could still be showing the old value from their cache for up to 24 hours after the change.

The registrar that I used, which also hosts my original dynamic domains that I am phasing out sets their TTL value at 1 minute. Obviously this is done so that dynamic updates will propagate quickly. If your system is normally stable, a 24 hour period will probably be good.

What I failed to show in my original post was that above the SOA record is the TTL value. It looks like this:$TTL 604800 ; 1 week

This page: has a really good explanation of the values that go into the SOA record in case you need one.
 
Hello Noway2,

Just had the server guys get me the information. I'm not sure that they have "sane" times for an 8 day lease but I might be wrong.

Refresh Interval = 15 minutes
Retry Interval = 10 minutes
Expires after = 1 day
Minimum(default) TTL 1 hour

It all looks a bit short to me but I'm a bit in the dark when it comes to DNS.

I'm going to see if I can find some best practice guides on the timers.
 
The values may be a little short. I have been thinking over this issue and it seems key to me that you said that a DHCP lease renewal causes the DNS to come back. This makes sense with dynamic DNS that is updated by the DHCP. I suspect that some sort of expiration value is causing the DNS to purge the entries, but I was wondering today why they would do this if the binding state were active.

If possible, I would also suggest that grab a snap shot of the DHCP leases and the DNS leases. Then when the problem occurs, look at these logs and see what has changed.

By the way, what are you using for a DHCP and DNS? There may be something application specific.

Another thing I was wondering is if there is any reason that the DHCP lease needs to be so long. If a device is still connected, a lease renewal will give it the same address and this may cause a re-binding of the DNS. Just a thought.


 
Sorry for the lack of update on this. Without having access to the DNS and DHCP servers this is very difficult for me.

However, I am convinced that the problem lies between the DHCP and DNS server as the printer cannot update DNS directly. Only when it is turned on or off does it have an affect on the DNS entry. Obvously if it is turned on it will get a DHCP reservation and DHCP will update DNS. If it is turned off the DHCP lease will become inactive and then DNS should scavange its own record. As long as the printer is on and renewing its lease, which it does, I don't see what else I can offer them.

The seem convinced that DHCP snooping is to blame, even though we have had it on for over 2 years without any trouble. They have recently split the DHCP and DNS servers from being on the same server and upgraded from 2003 to 2008. This on its own must raise alarm bells. I have pushed it back in their court for the moment so I'll let you know the outcome if there is ever one.

If anyone has any comments about this please let me have them.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top