We've just set up our GCP project. We've got several Compute Engine VMs (centOS) running. We've set up a VPN between our production co-lo and GCP. All appears to be working fine.
We do have the networking (VPC) set up in one project and it is shared with the project that has the VMs.

I've set up Private DNS using the Cloud DNS and added in a test A record that has one of our co-lo IP addresses. The NS IP in the DNS matches the nameserver in the resolv.conf file.
When I try to ping the DNS record, I get "Name or service not known".
I believe that we've got everything set correctly, but we are not getting the name resolution.

Any help would be appreciated. Thanks!

Update 12/4/2018
Added the DNS to both projects and DNS resolves. If we remove it from either, then it doesn't work. Still doesn't sound right, but whatever.

  • It really depends on a few things. 1) What order of DNS servers you are using in your resolv.conf? 2) Why are you trying to use your authoritative DNS server as a resolver? Does your server configured to be an authoritative as well as recursive DNS, if so it might be a bad idea? What happens when you try to resolv that hostaname using the following command: dig +trace hostname ; dig @yourDNSserver hostname – Dmitriy Kupch Dec 4 '18 at 14:39
  • Thanks for your response Dmitriy. The resolv.conf file only has the Google NS in it. # Generated by NetworkManager search c.mgcp-1158273-learning-platform.internal google.internal nameserver That IP is the same as the Cloud DNS service provided by google in the console of GCP. Does the search part need to changed? – r2t2 Dec 4 '18 at 16:27
  • I would be more concerned about the IP address that is used in nameserver section. Are you sure you have a proper ip address on your machine? ip a 169.254/16 meaning that you did not get proper IP from DHCP. Check your IP configuration and then change to something more meaningful, e.g. google DNS en.wikipedia.org/wiki/Link-local_address – Dmitriy Kupch Dec 4 '18 at 20:23
  • Yes, the machine IP is correct. ip a returns inet which is the same as reflected in the cloud console. The nameserver IP is the IP for the the cloud DNS service and matches what I find in the console. This all needs to remain internal, and not exposed to the outside world. – r2t2 Dec 4 '18 at 20:48
  • Can you ping ip address of your DNS server? – Dmitriy Kupch Dec 4 '18 at 20:52

You will find this Cloud DNS documentation useful which explains the prerequisite of using private zones with Shared VPC.

  • You must create your private zone in the host project, and you must add the appropriate Shared VPC network to the list of authorized networks for that zone.

  • You must activate private zone support in each service project. Even though the host project contains your private zone, and VMs in your service projects use your Shared VPC network (also in the host project), you must activate private zone support on a per-project basis, including for service projects. To activate private zone support for a project, you can manually create at least one private zone in it. Repeat this step for each service project to ensure you have activated private zone support in each one. The private zone you create in each service project does not need to have any resource records; you can leave it blank. Simply creating the private zone is sufficient to enable private zone support.


Working with Rackspace in getting this fixed. This is the answer I got from them:

Ok, final word from google shows that we will need to create the private zone and the records on the Host project (Shared VPC) and duplicate the zone only on the service project.
So, I have the full DNS with the A records in the Shared VPC project and just the zone defined in the project with the VMs.
All is working properly now. So strange.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.