1

Backstory
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.

Problem
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.

Tariq
  • 30
  • 4
r2t2
  • 23
  • 1
  • 6
  • 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 04 '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 169.254.169.254` 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 04 '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 169.254.169.254 to something more meaningful, e.g. google DNS 8.8.8.8 https://en.wikipedia.org/wiki/Link-local_address – Dmitriy Kupch Dec 04 '18 at 20:23
  • Yes, the machine IP is correct. `ip a` returns `inet 192.168.48.4/32` 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 04 '18 at 20:48
  • Can you ping ip address of your DNS server? – Dmitriy Kupch Dec 04 '18 at 20:52
  • We don't have a separate DNS server. We are using the Google Cloud DNS service within the console. – r2t2 Dec 04 '18 at 21:24

2 Answers2

1

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.

r2t2
  • 23
  • 1
  • 6
1

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.

Tariq
  • 30
  • 4