question

Hi there,

The DNS server will respond to the query in a round-robin fashion if the DC has multiple NICs registered in DNS. The DNS will serve the client with all the records available for that DC. To prevent this issue, we need to make sure the unwanted NIC address isn't registered in DNS.

Steps to avoid registering unwanted NICs in DNS on a multihomed domain controller
https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/unwanted-nic-registered-dns-mulithomed-dc

---

If the reply is helpful, please Upvote and Accept it as an answer

Hi @tonitodux

The metric will not fix the issue, this is used to define the routing table order, so the LAN interface take prescedence over the WiFi are both are connected.

There are number of reasons why a clients might not be registering the IP address of their connection. First I would check that the register this connection option is enabled on all the network cards. This is causes the OS to send an DNS update command to the DNS server.

Check that the DHCP to providing the same DNS server on both LAN and WiFi connections.

Also check the configuration the forward DNS zone to ensure that it has updates enabled and set to either 'secure only', or 'non-secure or secure'

From a workstation that has the wifi IP address in DNS, connect it to the LAN and run the following command:

 ipconfig /registerdns

This is will force the network to register it IP address with DNS. Check if the DNS entry is updated, if not delete the record in DNS and run the command again, and see if the record is created.

Gary.

Hi Gary,

thank you for your answer. This seems like a good suggestion to try out, but I have one question. If the laptops are outside of the company, and they connect over VPN which gives them the 3.0 subnet, and company Wi-Fi subnet is 4.0 - what happens then? Will they be registered assuming they connect over a Wi-Fi connection? What could be the possible ramification, not sure.

Dynamic updates was always set to "Secure only", but another thing I have to share is that our aging/scavenging is set to 1 day on both settings, this was set on purpose but I am not sure if this is helping or dragging some other issues along with it. Our dyn. DNS update credentials were not set on all DCs for over a year now, I manage to see this issue but I am still receiving receiving " error 9005 (DNS operation refused.)". I have lots of things to try out and bring this DNS infrastructure to work flawlessly. I will report back here but it will take a while.

Cheers

Hi @tonitodux

You have a couple of things in the mix here, and you might need to break each one down to determine how things are currently work, but more importantly I think you need to define what good looks like.

I'm assuming the primary objective here are the backups. Based on this I think you need to define what are your requirements for backups, in terms of frequency, scope, valid connection, etc. This will provide a starting point to test from and confirm that the backup solution, network configuration, mode of use can meet these requirements, or you need to change the requirements\expectation to align with the current solution and configuration.

A couple of things to consider:

Transport medium for the backup: do you want to backup machines over the LAN, WiFi, or VPN connections, LAN is best as it provides a reliable two way connection and typically can handle the additional bandwidth of the backup traffic. Wifi is typically best for client initiated traffic, and due power saving features, it can be unreliable for server initiated traffic, also wifi has limited shared bandwidth, so using it for backup traffic could significantly impact the usability for other users, i.e. if you have a client at the limits of AP range, and the client is using a low encoding method and this will consume more bandwidth, and increase backup time. VPN, has a different set of limitation, the user's internet connection and fixed bandwidth of the VPN terminator, software capability. The scope of the backups, frequency, number of users will be factors in deciding which transports will be supported, or limitation will be understood.

Both I and LimitlessTechnology-2700 have suggested way to force or limit which network card in the clients are registering their IP address, two different approaches, but you need to define your requirements to decide which approach is correct, i.e. if backups are only to be completed on the LAN, stop the wifi card from registering, or both cards register if both transports are supported. Note: to answer your other question: You only need to do LimitlessTechnology-2700 suggestion on the DCs if you have multiple NICs in the DCs, if you only have single NICs please ignore, or your DC will not be discoverable.

DNS updates, this is a big one, and is probably the root cause of your problem. There are two options here, let the clients manage their own registrations, or central manage them from the DHCP server. It sounds like you might have a bit of both at the moment. The suggestion here is understand how all these components work together, there are few and its not immediately obvious how they interact, and then test to confirm your understanding is correct. Here are few article to get you started 51810.windows-server-integration-between-dns-and-dhcp.aspx, dd145315(v=ws.10), dd334715(v=ws.10), configure-dns-dynamic-updates-windows-server-2003, and 21724.how-dns-aging-and-scavenging-works.aspx

Once you have stable name resolution, you can look at the backup and if your requirements can be supported by the various network transport type, and if you limit or change the scope of the backups.

I hope that helps.

Gary.