3

We have offices full of Windows & Mac users who obtain IP addresses from a Windows DHCP server, which in turn updates Dynamic DNS entries.

We are noticing major inconsistencies with the entries, and have found that the problem is occurring more on Macs than on windows, and even more when users are frequently switching from wired to wireless adapter, which makes sense, as this sequence occurs:

  1. User enables wired adapter and registers Proper DNS
  2. User enables wireless adapter and registers 2nd proper DNS entry
  3. user switches off wireless manually and 2nd entry remains improperly until scavenge.

Our help desk folks rely heavily (maybe more than they should) on the dynamic entries as part of their business process. For example, the user submits a help desk ticket, and the staff member expects to be able to remote desktop to their machine by hostname, which is hyperlinked in the helpdesk ticketing app.

We have implemented multiple solutions & band-aids to different symptoms of the problems such as:

  • Using DNS Reservations for Macintosh PCs
  • Using DNS Scavenging to remove old records
  • Switching from a Cisco DHCP server to the Windows DHCP Server

But no matter what we do, it seems impossible to maintain perfect records.

Has anyone encountered this problem before? What is industry best practice?

Comments & Suggestions are much appreciated,

/P

Phaedrus
  • 147
  • 1
  • 2
  • 6

3 Answers3

2

You could configure the wireless NIC's to not register in DNS. The only drawback to this would be if the user is connected only via wireless then you wouldn't be able to connect via DNS hostname as that would be tied to the ip address of the wired NIC.

EDIT

As an interesting workaround, here's something you could try:

Configure a sub-domain of your AD DNS zone, called wireless (or whatever you like).

Configure a DNS suffix on the wireless NIC (wireless.domain.tld) and set the options to "register this connection's addresses in DNS" and "Use this connection's DNS suffix in DNS registration"

What you'll wind up with is an A record in your "wireless" sub-domain for the wireless NIC of the client machine. You'll still have both A records in your AD DNS zone but if you can target your helpdesk application on the "wireless" sub-domain then you'll always know which A record corresponds to the wireless NIC.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
1

I'd say industry best practice is not to have an environment like yours. ;)

Seriously, though, AFAICS there isn't much more than what you're already doing. Your biggest issue is probably the frequent switching between wired and wireless connections. In your situation I'd use reservations as much as possible, and make the lease times and scavenging settings rather aggressive, particularly the no-update interval.

See this blog post about scavenging and DHCP lease times.

Ansgar Wiechers
  • 4,197
  • 2
  • 17
  • 26
  • If this is not industry best practice, what is ? Is it unreasonable to use dynamic DNS? –  Sep 05 '12 at 15:12
  • 1
    It's not unreasonable to use dynamic DNS. It's just unreasonable to have devices switch interfaces so frequently. The problem with this is how dynamic DNS and scavenging work. The scavenging settings define two intervals: during the `no-refresh interval` the record can't be updated. during the subsequent `refresh interval` the record can be updated, but remains present. Only after *both* intervals have passed is the record deleted. So you'll have to make these intervals rather short **and** match them with your DHCP lease time. See the link I added to my answer. – Ansgar Wiechers Sep 05 '12 at 23:56
0

I've encountered this situation before.

The solution for us was to look at domain authentications and log the most recent five or so hostnames / IPs for authentications of that user. That nearly always includes a login from their workstation or laptop, or whatever machine they are having trouble with and logged a ticket for. Usually it's the most recent one.

The information is available in the ticketing system on the information page for the user, and hence, is included in the ticket.

Overall, I'd suggest coming at it from a different angle, putting less emphasis on the DHCP addresses, and more on what address you know they are actively using.

Sirex
  • 5,447
  • 2
  • 32
  • 54