Possibility to set a DNS Suffix on Azure networks (like DNS Servers)
There are many scenarios for Virtual Machines (and Other maybe) where NIC settings are cleared (VM Deallocated). DNS Servers can be set on Azure Network, and this VM will have DNS Servers settings via DHCP. But we have to set DNS Suffix manually each time, or set a script automatically at each boot.
The idea is just to have a way to set a suffix DNS for VM Networks, with the same way as DNS Servers. With this settings, DHCP will assign DNS suffix to all VM automatically.
We understand the need for this capability and are looking at ways to solve this. At this time we do not have any timelines to share however but your comments help raise the priority for getting it done.- Altaf T
Blake Martin commented
Any update on this? This is an important feature that AWS has supported for years.
Pablo Ramos commented
The "internal.cloudapp.net" DNS entry goes away when the VNet is connect to a private DNS zone, but it is substituted by reddog fake zone. Why not configure the Azure DHCP to put my private domain as the primary DNS suffix for my VMs attached to this VNet?
Zachary Bedell commented
This limitation makes installing Puppet complicated. If Puppet agent is registered with its master before the final DNS suffix is applied, the change in FQDN invalidates the host's client certificate requiring re-registration. In order to properly install Puppet, we will need to develop a script that runs as a CustomScriptExtension to start the DNS suffix change, register something to run after reboot, and reboot the VM. Only after the reboot is it safe for the post-reboot script to install and register Puppet.
Ideally we need a way to set the fully qualified domain name including DNS suffix via an ARM template which would ensure any reboots are completed before running additional provisioning extensions such as the CustomScriptExtension. Then the CustomScriptExtension would be able to complete the Puppet install and registration with the correct FQDN.
Ayan Mullick commented
The "internal.cloudapp.net" DNS entry should go away when the VNet is connect to a private DNS zone.
Dave Medvitz commented
Not having this causes a lot of issues with VNet based azure services. DevTest Labs can't use artifacts, Service Fabric (configured for internal only) doesn't install properly, making both less than useful. Manually putting in a DNS suffix does the trick, allowing those machines to get to our internal WPAD file, but we shouldn't need to do this.
Is there any update on this?
Still no resolution - I really need to set arbitrary and specifically DNS suffix via DHCP on Azure DHCP on Linux servers
Setting arbitrary DHCP options would be very useful
and how do I implement this in the Azure VM Scale set, where VMs are provisioned dynamically?
have this been sorted out after two years? can we change DNS Suffix on IaaS v2 ARM based VMs?
here is a workaround by using GPOs: