in a GCP Redhat VM, I added one of our on-premises DNS host to /etc/resolv.conf. I added the DNS IP after 169.254.169.254.
When I try nslookup/ping a host that belongs to on-premises DNS, it does not resolve the hostname. Wireshark shows that it does not lookup beyond 169.254.169.254.
When I switch the IPs in /etc/resolv.conf and put my IP first, then the host on prem works, but GCP VM host name don't. In this case, 169.254.169.254 is used, but none of the domains in the search list is used.
my understanding is that every DNS ip will be used to resolve the hostname, also every domain in the search list will be used in the process. but this does not seem to be the case here.
Related
I have created an Azure DNS Zone that is acting as the public resolver for hostname resolution. For example, bash $> nslookup myhost.mydomain.com will resolve to xx.yy.zz.aa via Azure name servers when called by an external non-azure host.
The domain mydomain.com is obtained from Google Domains where I have delegated all 4 name servers over to Azure servers. The Google Domain DNS recordset is otherwise empty.
In Azure, The DNS Zone includes an "A" RecordSet that is an Azure Alias to the public IP of the internal VM that is externally known as myhost.
Working well for external hosts, the lookups (and other usages) fail if called from an internal host. For example, on myhost itself or on a peer host in the same internal subnet, the nslookups fail (don't resolve) and the nslookup mydomain.com request retrieves only the internal private IP for the virtual network, the 10. one.
What am I failing to do in order to get internal hosts to resolve FQDNs like the external ones can?
After my validation, the Azure host does work the same as the external clients:
You could verify if the DNS servers on the Azure virtual network set the default azure provided DNS or a Custom DNS server 168.63.129.16. Once you change it, you may restart your azure VM to make this effect.
Please let me know if you have any questions or show the output when you run nslookup myhost.mydomain.com on the internal hosts.
I'm trying to use Google Cloud Platform's Cloud DNS to resolve internal IPs of Compute Engine instances by DNS from my local machine. I was able to setup an OpenVPN server on an instance by following this guide: https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-16-04
My VPN configuration successfully connects to the OpenVPN server, and allows me to ping internal IPs of my GCE instances. The instance hosting my OpenVPN server is able to resolve and ping cloud DNS entries, but my client local machine is unable to do the same.
Here's the content of my /etc/resolve.conf file after connecting to the VPN server.
search openvpn
nameserver 169.254.169.254
What additional configuration do I need to do to allow my local machine to resolve Cloud DNS addresses?
In Compute Engine, DNS resolution is performed against the metadata server, which always has IP 169.254.169.254. The issue arises from the fact that this IP is link-local and is non-routable, thus will not work over VPN/IPSEC.
There are a few solutions/workarounds for it:
You could map all internal GCE instances IPs in the hosts files of the servers in your private network - the drawback is that the process is manual and time-consuming depending on how many instances you have.
The second option would be an internal GCE server (internal resolver) running a DNS server which could cross networks. More information on this is available in this documentation.
I attempting to deploy a Windows VM in Azure that will be running DNS for resolving a private zone in my VNet. I have created the VNet and set the IP address of the VM as the DNS server for the VNet. Since I have configured the VNet with a private DNS server, the VM gets the placeholder suffix of reddog.microsoft.com. I install DNS on the VM and create my forward and reverse zones. Since the VMs in the VNet will not be domain joined, I configure DDNS to allow unsecure updates. Outside of manually registering a record for the VM running DNS, I am unable to get it to register records. When I try to change the DNS suffix on the NIC, as soon as I click OK on the NIC properties window, my connection is killed and I am no longer able to get back into the VM. The only thing I can do at this point is to destroy it and start over. What am I missing here? Will I have to manually register records for anything I put into the VNet?
Update
From this document about Name resolution that uses your own DNS server:
When you are using Azure-provided name resolution, Azure Dynamic Host
Configuration Protocol (DHCP) provides an internal DNS suffix
(.internal.cloudapp.net) to each VM. This suffix enables hostname
resolution because the hostname records are in the
internal.cloudapp.net zone. When you are using your own name
resolution solution, this suffix is not supplied to VMs because it
interferes with other DNS architectures (like domain-joined
scenarios). Instead, Azure provides a non-functioning placeholder
(reddog.microsoft.com).
It says that your custom DNS suffix is not supplied to VMs because it interferes with other DNS architectures (like domain-joined scenarios). Moreover, Azure doesn't have the credentials to directly create records in your DNS servers. Azure leaves the primary DNS suffix blank, and you can set the suffix in the VM as the picture below:
After changing the DNS suffix, you will restart the VM, then you will see a new DNS suffix in the DNS Suffix Search List in the output of prompt commands.
Go to the DNS server, you will see the DNS records updated. Before this, make sure you have enabled the Nonsecure and secure of the Dynamic updates in the zone properties.
Is there a way to point an Azure NIC to the records one created in an Azure DNS zone?
At present Azure DNS doesn't support private DNS zones, i.e. those only available to your vnet. Also, the DNS servers specified in the "Add DNS server" box needs to be a recursive resolver, Azure DNS is an Authoritative DNS service, i.e. it will only serve answers for the zones it hosts.
We can't add Azure DNS zone to NIC custom DNS. The custom DNS required IP address, we can add the DNS server IP address to it.
For example, we can add 8.8.8.8 to it, also we can add local DNS server IP address to it(need VPN). Or create a Azure windows VM and install DNS role on it, and add this VM ip address to it.
If you want to use Azure DNS zone to manage your records, we can map your own domain name to DNS zone, and add name servers to your domain name(add this by domain name registrar manage webpage).
The following image shows an example DNS query about Azure DNS zone:
If you want to add record to DNS zone, and you want to map your 3rd party domain name map to Azure DNS zone, we can follow those steps in that answer.
Note:
Keep in mind Azure DNS is not the domain registrar, we should buy domain name from domain registrar(like godaddy, register.com).
Update:
If you just want to use domain name in your virtual network, there is no need to buy a domain, we can use AAD DS in our virtual network. Or we can deploy a VM and install DC on it, work as on-prem.
By the way, in the same virtual network, we can ping VM's name by default.
I have an Azure virtual machine with multiple web sites on it that I would like to expose to the Internet. The VM has Active Directory and DNS installed on it. I created the forward zone (xxx.cloudapp.net) on my server, and added the two web site names to the zone. On the Networks in the Management Portal, I added a DNS server(xxx.cloudapp.net) and gave it the public IP for my server.
So when I try a nslookup from outside of the VM, the names will not resolve. I set the server in nslookup to either the public IP or the name, and it does not resolve. I have logging turned on in the DNS server, but it does not seem to show any requests from my computer.
I must be doing something wrong. Any suggestions? This server is for a demo next week, and worst case, I can buy a couple of domain names.
Try the instance level public-ip address, you will get an ip address per virtual server: https://azure.microsoft.com/documentation/articles/virtual-networks-instance-level-public-ip/