I am left scratching my head: DNS server settings for managed domain service IPs 10.0.0.5,10.0.0.4 need to be configured for virtual networks Central US/aadds-vnet

Question

Hi, I am setting up a lab, and I just cannot get this resolved: After I deployed my domain, it picked on my DNS and said " |DNS server settings for managed domain service IPs 10.0.0.5,10.0.0.4 need to be configured for virtual networks Central US/aadds-vnetFix| | -------- | ||

" I did the automatic fix, went to DNS for the affected vnet and saw these two ip addresses listed there. Yet the error persists when I run diagnosis. I tried to move it back to default Azure settings for DNS, then manually back to these two IP addresses, the error persits. My subnets are 10.0.0.0/24 and 10.0.3.0/32. I am somewhat of a noob with networking and not super experienced there. What am I doing wrong here?

Answer 1

@Alistair Ross Follow up question on this. I inherited few clients with AD DS configured under their 'real' domain name. Let's say contoso.com. Problem is that resources inside the Azure network (or users on VPN) can not access their external contoso.com website now. I am not able to configure Forwarder on AD DS DNS because of course contoso.com Zone already exsist. Is there a work around that?

Do people typically configure AD DS as a subdomain instead? Surely this must be pretty common issue. I'd love to know the best practice for this.

Answer 2

When deploying Azure Active Directory Domain Services (AADDS), it deploys managed domain controllers onto your specified virtual network. A key part of Active directory is DNS, which typically the domain controllers would host their zone and each DC must be able to resolve the name of the others. When setting DNS on-prem, you would usually do this directly on the network interface card in the OS. Now when using Azure, the DNS servers are specified in the vNet settings, which requires a restart of all devices connected to the vNet. The .4 and .5 addresses are typically the first two useable addresses in the subnet (depending on your address range) and when you deploy AADDS, they are going to assign the domain controllers these addresses and register it in the vNet DNS settings The error that appears in the diagnostic fix should set this. Now all you need to do is restart any servers on the same vnet that you are trying to join to the domain, if they are in different vNets, just make sure you have the relevant DNS forwarding , vNet peering etc to route traffic to your AADDS instance.

Note: In my testing, the error related to DNS records did not disappear immediately. I went on a VM and ensured I could resolve DNS and could connect to the domain with no issue.