Use dynamic DNS to register hostnames in your own DNS server

Azure provides name resolution for virtual machines (VM) and role instances. When your name resolution needs exceed the capabilities provided by Azure's default DNS, you can provide your own DNS servers. Using your own DNS servers gives you the ability to tailor your DNS solution to suit your own specific needs. For example, you may need to access on-premises resources via your Active Directory domain controller.

When your custom DNS servers are hosted as Azure VMs, you can forward hostname queries for the same virtual network to Azure to resolve hostnames. If you don't wish to use this option, you can register your VM hostnames in your DNS server using dynamic DNS (DDNS). Azure doesn't have the credentials to directly create records in your DNS servers, so alternative arrangements are often needed. Some common scenarios, with alternatives follow:

Windows clients

Non-domain-joined Windows clients attempt unsecured DDNS updates when they boot, or when their IP address changes. The DNS name is the hostname plus the primary DNS suffix. Azure leaves the primary DNS suffix blank, but you can set the suffix in the VM, via the user interface or PowerShell.

Domain-joined Windows clients register their IP addresses with the domain controller by using secure DDNS. The domain-join process sets the primary DNS suffix on the client and creates and maintains the trust relationship.

Linux clients

Linux clients generally don't register themselves with the DNS server on startup, they assume the DHCP server does it. Azure's DHCP servers don't have the credentials to register records in your DNS server. You can use a tool called nsupdate, which is included in the Bind package, to send DDNS updates. Because the DDNS protocol is standardized, you can use nsupdate even when you're not using Bind on the DNS server.

You can use the hooks that are provided by the DHCP client to create and maintain the hostname entry in the DNS server. During the DHCP cycle, the client executes the scripts in /etc/dhcp/dhclient-exit-hooks.d/. You can use the hooks to register the new IP address using nsupdate. For example:

#!/bin/sh
requireddomain=mydomain.local

# only execute on the primary nic
if [ "$interface" != "eth0" ]
then
    return
fi

# When you have a new IP, perform nsupdate
if [ "$reason" = BOUND ] || [ "$reason" = RENEW ] ||
   [ "$reason" = REBIND ] || [ "$reason" = REBOOT ]
then
   host=`hostname`
   nsupdatecmds=/var/tmp/nsupdatecmds
     echo "update delete $host.$requireddomain a" > $nsupdatecmds
     echo "update add $host.$requireddomain 3600 a $new_ip_address" >> $nsupdatecmds
     echo "send" >> $nsupdatecmds

     nsupdate $nsupdatecmds
fi

You can also use the nsupdate command to perform secure DDNS updates. For example, when you're using a Bind DNS server, a public-private key pair is generated (http://linux.yyz.us/nsupdate/). The DNS server is configured (http://linux.yyz.us/dns/ddns-server.html) with the public part of the key, so that it can verify the signature on the request. To provide the key-pair to nsupdate, use the -k option, for the DDNS update request to be signed.

When you're using a Windows DNS server, you can use Kerberos authentication with the -g parameter in nsupdate, but it's not available in the Windows version of nsupdate. To use Kerberos, use kinit to load the credentials. For example, you can load credentials from a keytab file), then nsupdate -g picks up the credentials, from the cache.

If needed, you can add a DNS search suffix to your VMs. The DNS suffix is specified in the /etc/resolv.conf file. Most Linux distros automatically manage the content of this file, so usually you can't edit it. However, you can override the suffix by using the DHCP client's supersede command. To override the suffix, add the following line to the /etc/dhcp/dhclient.conf file:

supersede domain-name <required-dns-suffix>;