1

I am using a Google Cloud DNS Managed Private Zone, which is unable to be resolved by Compute instances that are within the network permitted by the zone. I am using two Ubuntu 18.04 LTS standard images. The two instances are on two different subnetworks of the same network, which has been permitted to see the Private zone.

I am using GCloud CLI, and I am signed in and verified through gcloud init with a project selected that I am the Owner for.

I have tried adjusting /etc/resolv.conf to point to the metadata server specifically, however this simply stopped resolution altogether. I was originally using A records in the private zone which didn't work; based on this article https://www.jhanley.com/google-cloud-private-dns-zones/ I tried using CNAME for the [INSTANCE_NAME].[ZONE].c.[PROJECT].internal domain which also didn't work.

The setup I am doing is through GCloud CLI and is as follows:

#!/bin/bash

# gcloud init or gcloud auth activate-service-account must have been previously run

CUSTOMER=test
NETWORK=testnetwork

# configure Cloud DNS - create customer.workshop.local

gcloud dns managed-zones create "${CUSTOMER}internal" \
--dns-name="${CUSTOMER}.workshop.local" --description="A zone" \
--visibility=private --networks="$NETWORK"

# IP is derived through a gcloud compute call but presume it is:
IP=10.10.0.4

gcloud dns record-sets transaction start --zone="${CUSTOMER}internal"
gcloud dns record-sets transaction add "$IP" \
  --name="server.${CUSTOMER}.workshop.local." \
  --ttl=300 \
  --type=A \
  --zone="${CUSTOMER}internal"

gcloud dns record-sets transaction execute --zone="${CUSTOMER}internal"

When pinging from my Ubuntu 18.04 LTS machine in a subnetwork 10.10.1.0/24, I get:

david.alexander@jump-ubuntu-01:~$ ping server.test.workshop.local
ping: server.test.workshop.local: Temporary failure in name resolution

Has anyone got any ideas? Cheers!

David Alexander
  • 31
  • 4
  • I do not see the command in your script to make the private zone visible to the network $NETWORK. `gcloud dns managed-zones update private --networks $NETWORK`. Do not modify /etc/resolv.conf. Google overwrites this file on a regular basis (DHCP lease expiration or about every 60 minutes). – John Hanley Jul 16 '19 at 06:36
  • Note: `[INSTANCE_NAME].[ZONE].c.[PROJECT].internal` is an example and not the actual name. the `.c.` part will be different (a, b, c ....). Get the hostname from this instance `hostname -f`. – John Hanley Jul 16 '19 at 06:40
  • Thanks John. I thought the last two options of the creation command set the network visibility? `gcloud dns managed-zones create "${CUSTOMER}internal" \ --dns-name="${CUSTOMER}.workshop.local" --description="A zone" \ --visibility=private --networks="$NETWORK"` – David Alexander Jul 16 '19 at 20:42
  • On the second point - I create my VM with `hostname=server.test.workshop.local`, but `hostname -f` just returns `server`, rather than the FQDN. – David Alexander Jul 16 '19 at 20:52
  • Thanks for your assistance so far! – David Alexander Jul 16 '19 at 20:52
  • The command line options for `hostname` vary among OS versions, etc. Look up what option returns the long hostname for your OS. Usually `man hostname` will do the trick if you have the help packages installed. – John Hanley Jul 16 '19 at 20:57
  • Creating a private zone is not the same thing as making it visible (active) in a VPC. – John Hanley Jul 16 '19 at 20:58
  • I'm getting `ERROR: (gcloud.dns.managed-zones.update) HTTPError 403: Forbidden` when I run `gcloud dns managed-zones update testinternal --networks testnetwork` - gcloud init says I'm still the Project Owner though. – David Alexander Jul 16 '19 at 21:05
  • Just because you are a "Project Owner" does not mean you have permission to all actions. Project Owner does have access to all resources. It does mean that you can grant yourself permission by adding a role to your IAM member account. Add the role `Service Networking/Service Networking Admin`. There are other roles that you can also use: https://cloud.google.com/iam/docs/job-functions/networking – John Hanley Jul 16 '19 at 21:58

2 Answers2

1

This has turned out to be an issue only with Ubuntu 18.04. Windows doesn't replicate this issue. Edit - CentOS has also been tested and not replicated this issue.

When I created a Windows server in this network and tried name resolution, it worked fine. The Canonical image for Ubuntu 18.04 (i.e. not a custom image) has name resolution to 127.0.0.53 through Netplan by default, and it can't query the Google Metadata server. Dig shows this on a default image - if you specify the metadata server, you are able to resolve the name.

I will log a bug with Canonical about this. Thanks John Hanley, I can't upvote you because you commented rather than answered - if you can ping me about how to do this I can do it.

Cheers!

David Alexander
  • 31
  • 4
0

Did you already try to do it following the official guide from Google Public documentation:

Creating a private zone through GCloud CLI

Creating a private zone through GUI

Just, I am seeing you missed the project:

gcloud dns --project=test record-sets transaction start --zone=testinternal
gcloud dns --project=test record-sets transaction add 10.10.0.4 --name=test.workshop.local. --ttl=300 --type=A --zone=testinternal
gcloud dns --project=test record-sets transaction execute --zone=testinternal
Chrisvin Jem
  • 3,940
  • 1
  • 8
  • 24
Agustin E.
  • 56
  • 4
  • Thanks Agustin. Yes, I followed the documentation to the letter; and you don't need to specify a project when you use gcloud init/gcloud auth activate-service-account and have already specified a project context :) – David Alexander Jul 16 '19 at 21:28