Here’s how you can host your public (internet) DNS servers on Windows Azure.
In this example I will be building two public DNS servers (name servers) running Windows Server 2012 on Windows Azure. These name servers will be used to resolve names for internet domain names such as those used for public websites and email.
For those of you who want to run non-Microsoft DNS for your public domains, you can also run Linux versions of DNS software on Windows Azure, as it also supports a host of Linux OS platforms such as Ubuntu, SUSE and CentOS.
Benefits of hosting your DNS servers on Windows Azure:
- Secure: Moving your public DNS server on to the cloud gives you the security assurance that can only be found in the datacenters of a large-scale cloud storage vendor such as Microsoft. In fact it is a best practice, to host your DNS outside your environment.
- Handle demands: You can easily scale up resources or hardware configuration of your servers any time on a pay as you grow model, or even temporarily when you anticipate a large number of DNS requests.
- Hybrid, distributed model: You can even have a few name servers on premises and a few on the cloud to spread them in to hybrid model. It is a best practice to geographically distribute your DNS.
- Increase Uptime: Remove hardware downtime, hardware maintenance contracts, and hardware refresh from the equation.
However, at the time of writing this blog post, there are still major considerations that need to be taken before you decide to move your DNS servers to Windows Azure, owing to the nature of the service.
1. All Windows Azure VMs have dynamic IP addresses with an infinite lease (in other words, no expiry date). Which means the IP addresses will be dynamic but will not change even if you reboot your VM. However, if you redeploy or stop the VM, the IP address will change and your old IP address may be re-assigned, requiring you to update your NS IP address records. I recommend you use availability sets and when you have to restart the VM, use the ‘restart’ option instead of ‘Stop’ followed by ‘Start’.
Part 1: Build your VMs
1. Choose the appropriate OS image from the Gallery and build your VMs. I chose Windows Server 2012.
2. Choose a hostname, VM size, local administrator username and password. (No, you can’t use “P@ssw0rd”. )
3. Choose to create a new cloud service for your first name server. Choose a location, and a storage account (or choose to create a new one). For production servers, I recommend you use Availability Sets to protect against downtime when Microsoft does hardware maintenance.
4. Add the DNS Endpoint to the list of default endpoints. This will allow DNS requests to pass to the VM. The default endpoint in the list only creates a TCP endpoint on Port 53.
5. Important: However, DNS also needs a UDP endpoint on port 53. This is not in the list as of writing this blog entry. So you will need to create it manually. Let’s call this custom endpoint “DNS-U”. Without the UDP endpoint, NSLOOKUP will fail and names cannot be resolved, although a telnet on port 53 will work.
6. Virtual machine will now be created. Create a second virtual machine with similar parameters. This is because most domain name providers will require you to register two name servers if you are using your own custom name server.
What you have now is two VMs, both with private IP addresses behind a NAT, exposed to the internet via public IP addresses.
Part 2: Configure DNS
1. Install DNS role on the servers. Self explanatory. For more information, see TechNet. You might get a warning that the machine doesn’t have a static IP address. You can ignore this for now because Windows Azure DHCP leases are forever (unless you rebuild your VM). Alternately you can change the IP to static and apply exactly same IP that was leased.
2. Make it an authoritative DNS server.
a) Disable Recursion: Right click on the server, choose Properties. Go to the Advanced tab and choose Disable Recursion (also disables forwarders).
b) Create a Forward Lookup Zone named “.” (dot). See steps below.
3. Create the Forward Lookup Zone(s) for your domain(s). Create some records – for example A, MX, CNAME records. In my example, the domain name is iloveazure.net
a) Create the forward lookup zone named yourdomain.com, following the instructions in step 2(c)
b) Right click on the NS (name server) record that was created in the new forward lookup zone for your domain and choose Properties.
Make sure the internet FQDN of the name server is correct and manually change the IP address so that the public IP is listed. This should not have the local (private) IP address of the VM or the local FQDN/hostname. This step is important. If you have two name servers you can add them both.
c) Click on the Start of Authority (SOA) tab. Under primary server put the internet FQDN of your name server. Under Responsible person put your email address but substitute the @ sign with a dot (.)
Click OK. You will notice that the system automatically creates A records for your name servers, pointing to the public internet IP address of your name servers.
d) Create all the DNS records you need for the zone. This could be A records, CNAME records, SRV records, etc.
Part 3: Register your name servers with your domain name provider
The steps for registering your own custom name servers varies from provider to provider. For godaddy.com, see this article. This is a required step, otherwise DNS queries for your domain name will not be forwarded to your name servers. For assistance, contact your domain name provider.
GoDaddy steps shown below.
These changes will take a few hours to propagate. You may not see results immediately.
Part 4: Test your servers
When you’re done use a tool like dnsstuff.com or mxtoolbox.com to run a DNS test. You should get something like this:
On a machine connected to the internet, run NSLOOKUP against the name server you just created.
Websites like WhatsmyDNS.net will help you check if your DNS has propagated throughout the world.