In this video, Sharon will explain the differences between on-premises DNS and DHCP implementations and how these two critical on-premises components are handled in the Azure environment.
- [Instructor] Two critical components in our on-premise infrastructure are DNS and DHCP. In this lesson, we are going to explore how we handle DNS and DHCP in Azure as there are some differences that you need to be aware of. In Azure, we have three DNS options to choose from. The first one we'll explore is the Azure Provided Name Resolution Service. This service will resolve the virtual machines within the same virtual network, it's easy to use and is highly available.
And because Azure provides a service, you never have to worry about configuring or setting up DNS servers. In the new Azure Resource Manager portal or ARM, FQDN is not required. And you can use hostnames that are descriptive for your services. But there are a few things you need to be aware of. First, DNS suffix cannot be modified, WINS and NetBIOS are not supported, and you cannot manually register any of your records.
This service is fantastic for testing dev or simple cloud-only deployments. The next option we have is to bring our own DNS. Typically, you'll want to bring in your own DNS for hybrid connectivity, and this could include Azure virtual machines and your on-premise environment or if you have Azure virtual machines in different networks. If you need to authenticate to a DC or domain controller, you'll definitely require your own DNS server. Or, if you require reverse lookup of internal IPs, you'll need to bring your own DNS.
Very important point here is you must configure your DNS server IP in Azure networking. If you do not configure it in Azure networking, your virtual machines will not be able to find your DNS server. And if you are going to bring your own DNS, there are a few things you need to be aware of. First, you must turn off scavenging. As a quick refresher, scavenging automates the deletion of stale or outdated DNS records, as your DHCP leases are very long, and the scavenging could remove the DNS records.
Next, you must enable DNS recursion. This allows resolution of external domain names. Your DNS server must be accessible on TCP and UDP port 53 from all your clients, and just as we secure our DNS serve on-premise, you'll need to secure it in Azure as well. And finally, do not set the DNS server IP in Windows. In Azure, the network interface cards may be replaced, and if that is the case, then that DNS setting will be erased.
So please, don't ever set it here. Let's go ahead and take a look at an example, combining these two DNS services. In our example here, you'll notice we have our on-premise environment, and it has a local or recursive DNS. Our on-premise is connected to VNet one via express route. Within VNet one, we have a local DNS server, and we also have an Azure recursive DNS service. This provides the Azure name resolution for our virtual machines within that virtual network.
Next, we have virtual network two, which also has a local DNS server as well as the Azure recursive DNS service. Now that we understand our layout, let's go ahead and take a look at how DNS would resolve queries. First, DNS queries from our on-premise to the local or recursive DNS server. The query would then be passed to our local DNS server on VNet one. The local DNS server in VNet one can then forward the query to the DNS server in VNet two for further name resolution for virtual machines within VNet two.
Or, it can pass the query to the Azure recursive DNS service for the virtual machine VNet name resolution within VNet one. And virtual machines within VNet one would pass their queries to our local DNS server, and that query could be sent to virtual network two. It could be sent to DNS on-premise, or the Azure recursive DNS service. And the same process would happen in virtual network two. Finally, we have DNS hosting, which allows us to actually host DNS domains, and it provides the name resolution using the Microsoft global servers.
You must already own the domain name in order to use this. And keep in mind that the Azure DNS hosting service only provides an authoritative DNS service. The one thing I haven't touched on yet is DHCP. Azure controls the IP addressing, and the addresses are assigned from the IP addressing scheme that you create. And you cannot reserve an IP address, but you can use a static IP. Also, keep in mind that the IP address lease is for the lifetime of the virtual machine.
Or, if you stop and deallocate it. If you stop and deallocate the virtual machine when it restarts, it could have a different IP address. To quickly recap, you can use the Azure-provided name resolution service for your simple cloud-only deployments, and you can bring your own DNS for hybrid deployments, and finally, you can leverage Azure DNS if you wish to host your domain names with Microsoft. And no matter how hard you try, you can't do DHCP in Azure.
- Designing virtual machines
- Selecting appropriate VM SKUs
- Designing template deployment
- Deploying ARM templates via PowerShell and CLI
- Designing for availability
- Designing Azure Virtual Networks
- Azure VPN and ExpressRoute architecture and design