browse
Introduction
Some customers have reported issues with Microsoft Dynamic Updates after installing virtual appliances (VAs) in their environment or installing the Umbrella Roaming Client on some machines. The most commonly reported symptom is that clients cannot resolve A or PTR records for other client machines while using the VAs or the Roaming Client for DNS resolution.
MS Dynamic Updates Overview
Microsoft Dynamic Updates utilize both DNS and DHCP in order to dynamically update client DNS records.
Clients may initiate a dynamic DNS update with either the DNS server or the DNS + DHCP servers, depending on how the client’s network connection is set.
Statically-set clients (static clients) that perform dynamic updates will send updates for both its A record (forward lookup record) and its PTR record (reverse lookup record) to the authoritative DNS server.
Clients with dynamically-set network connections (DHCP clients) will communicate with both the authoritative DNS server and the DHCP server for updating A and PTR records. The DHCP client will communicate with the authoritative DNS server directly for updating its A record, but the DHCP server updates the DNS server with the client’s PTR record on behalf of the DHCP client.
Depending on how the DHCP server is configured, it may perform both A and PTR record updates on behalf of all DHCP clients.
In some cases, a DHCP server may update a client's A record on its behalf, even if the client did not specifically request this. This can occur with non-Windows machines that may not be able to request dynamic updates.
A record (forward lookup entry) updates
When either type of client (static or DHCP client) initiates an A record update with its authoritative DNS server, it will first start by performing an SOA query for the FQDN of the client in question:
nslookup -type=SOA test-client-PC.domain.local.
The client then receives a response from the authoritative DNS server containing information about the server that is to process the dynamic update. From there, the client continues communicating with the primary DNS server that accepted the A record update. Please see this TechNet article for more information on how a dynamic update is initiated.
PTR record (reverse lookup entry) updates
How a dynamic update for a PTR record update is initiated depends on the type of network connection the client has.
For a static client, the client will communicate directly with the authoritative DNS server to update its PTR record. It will first start by performing an SOA query for the reverse lookup name for the client in question:
nslookup -type=SOA 78.128.23.172.in-addr.arpa.
The client then receives a response from the authoritative DNS server containing information about the server that is to process the dynamic update. From there, the client continues communicating with the primary DNS server that is accepting the PTR record update. Please see this TechNet article for more information on how a dynamic update is initiated.
For a DHCP client, when some particular action causes its IP address to change, such as a DHCP lease renewal, if the client supports it, it will send Client FQDN information (DHCP option 81 flags) to the DHCP server. The DHCP server will use this information, along with its dynamic update configuration, to determine whether or not the DHCP server will perform the PTR record update against the authoritative DNS server on behalf of the client, or if the client will perform the PTR update against the authoritative DNS server on its own.
More information on how Microsoft DNS dynamic update and DHCP updates interact is found in this article.
Secure Dynamic Updates
This article describes how Secure Dynamic Updates take place. The first step of this process still involves the client machine sending an SOA-type query to the configured DNS server. The client then receives information from the authoritative DNS server indicating which server will be processing the update.
Secure Dynamic Updates currently do not function on the AnyConnect Roaming Security Module. Please contact umbrella-support@cisco.com to file a request.
Dynamic Updates and the Virtual Appliance
The VA is a non-caching, conditional DNS forwarder, with emphasis on conditional. The VA forwards DNS queries listed in Internal Domains to the local authoritative DNS servers configured in the VA’s local DNS list.
As long as the Internal Domains are correctly populated, then any SOA queries for any internal-facing domains will be sent to the local DNS server.
Dynamic Updates and the Roaming Client
The roaming client is lightweight software installed on Windows machines which takes in the client’s DNS queries and conditionally forwards them to Umbrella anycast resolvers. The roaming client forwards DNS queries listed in Internal Domains to the local DNS servers on the network. As long as the Internal Domains are correctly populated, then any SOA queries for any internal-facing domains will be sent to the local DNS server.
Troubleshooting
If you are having trouble with MS Dynamic Updates after deploying either the VA or the roaming client, please see the following troubleshooting steps:
- Install MS Hotfix 2520155, which resolves an issue where the DNS host record of a computer is deleted after the computer’s DNS server assignment changes
- Ascertain whether it is the computer’s A record (forward lookup entry) or its PTR record (reverse lookup entry) that is affected
- If the A record lookup is affected, ensure that the forward lookup zone in question is replicated across all DNS servers
- If the PTR record lookup is affected, ensure that the reverse lookup zone exists on the DNS server for the IP scope in question and is replicated across all DNS servers
- If you are using Secure Dynamic Updates only in your environment, verify that all DHCP servers in the environment are authorized to update the DNS server on the client's behalf. See DNS Record Ownership and the DnsUpdateProxy Group for more information in this regard
If you have performed these steps and are still having trouble, please open a ticket with Umbrella Support with the following information:
- The operating systems of the affected machines
- Whether or not the affected machines are joined to an Active Directory domain
- If you’re using virtual appliances, please run the following commands on an affected machine and send in that information:
nslookup -type=SOA <FQDN of host> <VA IP address>
nslookup -type=SOA <FQDN of host> <internal DNS server IP address>
nslookup -type=SOA <reverse lookup entry> <VA IP address>
nslookup -type=SOA <reverse lookup entry> <internal DNS server IP address>
- If you’re using the roaming client, please run the following commands on an affected machine and send in that information:
nslookup -type=SOA <FQDN of host> 127.0.0.1
nslookup -type=SOA <FQDN of host> <internal DNS server IP address>
nslookup -type=SOA <reverse lookup entry> 127.0.0.1
nslookup -type=SOA <reverse lookup entry> <internal DNS server IP address>
Further Information
- Dynamic Update: https://technet.microsoft.com/en-us/library/cc959284.aspx
- Understanding Dynamic Update: https://technet.microsoft.com/en-us/library/cc771255%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396
- DHCP Processes and Interaction: https://technet.microsoft.com/en-us/library/dd183657(v=ws.10).aspx
- Secure Dynamic Update: https://technet.microsoft.com/en-us/library/cc961412.aspx
- Is there a downside to always updating DNS from DHCP?: https://serverfault.com/questions/634684/is-there-a-downside-to-always-updating-dns-from-dhcp