Your on-premises AD domain (syncs to Azure AD) has the domain controllers listed. DNS servers forward to an external DNS service. You create VNET2 peered to VNET1 with gateway transit and will place an Azure Virtual Desktop host pool in VNET2; session hosts will join the AD domain. To ensure AVD users can resolve on-premises and Azure resources, maintain operation if a DNS server fails, and minimize admin effort, what should you configure?

Configuring VNET2's DNS settings to use Server2 and Server1 ensures that Azure Virtual Desktop session hosts, which will join the AD domain, can resolve both on-premises resources (via the domain controllers) and Azure resources. This setup provides high availability; if one DNS server fails, the other can still resolve queries. It also minimizes administrative effort because you configure DNS once at the VNet level, and all VMs subsequently deployed in that VNet automatically inherit these settings. Using the Azure DNS service for VNET2 would prevent resolution of on-premises resources since the Azure DNS service cannot resolve private IP addresses within your on-premises network. Configuring DNS settings on individual virtual machines is less efficient and harder to manage at scale compared to VNet-level configuration, and it doesn't provide the same level of automatic inheritance for new VMs.