CODEWITHSUNDEEP
dnsgoogle-compute-enginereverse-dns
Antonis Kouzoupis
Antonis Kouzoupis

Reputation: 83

GCE custom hostname reverse lookup in private DNS zones

I want to create an instance in Google Cloud Engine with a custom (private) hostname. For that reason, when creating the instance from the Console (or from an SDK) I supply the hostname, or example instance0.custom.hostname.

The instance is created and the search domain is set correctly in /etc/resolv.conf For Ubuntu in particular I have to set the hostname with hostnamectl but it is irrelevant to the question.

Forward DNS lookups work as normal for instance0.custom.hostname. The problem comes when I do a reverse lookup for the private IP address of the instace. In that case the answer I get is the GCE "long" name instead of my custom hostname.

How can I make the reverse lookup reply with my custom name instead of the GCE?

I know in Azure you can use a Private DNS Zone with VM auto-registration to handle the "custom hostnames". I tried using a private zone with Google Cloud DNS (PTR records) but with no luck.

Upvotes: 2

Views: 752

Answers (1)

Wojtek_B
Wojtek_B

Reputation: 4443

After some serious digging I found a solution and tested it.

Reverse DNS works even without a "regular" DNS records for your custom.hostname domain.

To get reverse dns working lets assume your VM's in 10.128.0.0/24 network. Their IP's are 24,27,54,55 as in my example.

I created a private dns zone and named it "my-reverse-dns-zone" - the name is just for information and can be anything.

"DNS name" field however is very important. Since my network address starts with 10 I want all the instances that are created in that network segment to be subject to reverse dns. So the DNS name has to be 10.in-addr.arpa in this case. If you're using 192.168.... or 172.16.... then adjust everything accordingly.

If you wanted just 10.128.0 then you can put 0.128.10.in-addr.arpa. Then you select the VPC networks zone has to be visible in and voila:

enter image description here

Then you add the PTR records that will allow this to work. I'm setting all TTL's to 1 minute to shorten the wait :)

enter image description here

After accepting wait a minute (literally) and test it:

dig -x 10.128.0.24

; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> -x 10.128.0.24
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35229
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;24.0.128.10.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
24.0.128.10.in-addr.arpa. 60    IN      PTR     instance0.custom.hostname.

;; Query time: 6 msec
;; SERVER: 169.254.169.254#53(169.254.169.254)
;; WHEN: Mon Jan 31 13:35:57 UTC 2022
;; MSG SIZE  rcvd: 92

Done !

You can even put some completely other domain for one of the IP's. Have a look at my zone configuration:

enter image description here

dig -x 10.128.0.55 | grep PTR
;55.0.128.10.in-addr.arpa.      IN      PTR
55.0.128.10.in-addr.arpa. 60    IN      PTR     b2.example.com.

There's a similar question & answer here.

To have a better (technical) understanding of how this works have a look at PTR records in private zones documenation and about PTR records and how they work in the internal GCP's DNS.

Upvotes: 3

Related Questions