A Deep Dive into the Google Cloud DNS
What is Cloud DNS: Cloud DNS is a high-performance, resilient global domain Name system service that publishes your domain names to the Global DNS. Google Cloud DNS is a global service that lets you publish your zones and records in DNS and simplify your life without managing your own server and software. Cloud DNS offers both public and Private Zones
Public Zones: Public Zone is visible on the internet. if you already purchased a public domain from the external domain service provider, you can create a public Zone in Google Cloud. The only thing you need to copy the Name Servers records from google cloud to your third-party domain provider. Also, remember that public-hosted zones are not free. you have to pay for the domain of your choice. Examples: linkedin.com, Youtube.com, google.com, facebook.com, etc.
Private Zones: Private Zones are visible to your internal Network or VPC. you can create a zone of your choice and attach it to your VPC. Examples: your business team has a domain uat.example.com, dev.example.com, prd.example.com, etc. These zones are visible only within your company’s internal network. you can not expose them on the Internet.
What is DNS peering?
DNS peering is a feature of Google Cloud DNS that allows you to send DNS queries to other VPC networks for resolution. This can be useful in a number of scenarios, such as:
- To improve the performance of DNS queries
- To improve the availability of DNS queries.
- To reduce the cost of DNS queries
How does Google Cloud DNS peering work?
Once the DNS request is received, a final resolution is done via a private zone, forwarding zone, or ANS attached to the targeted(provider network)
When you create a peering zone, you specify the VPC network that will be the peer network. Cloud DNS then creates a peering connection between the two VPC networks. This peering connection allows DNS queries to be sent between the two networks. When a DNS query is sent from a VM in the peer VPC network, it is first routed to Cloud DNS. Cloud DNS then forwards the query to the peering zone. The peering zone then resolves the query and returns the results to Cloud DNS. Cloud DNS then returns the results to the VM.
Please note that: DNS peering and VPC network Peering are different services. DNS peering can be used with VPC network Peering, but VPC network peering is not required for DNS peering.
Scenario 1: Google DNS peering between VPCs.
In this case, you have a zone somewhere else in GCP. You can think of two VPCs. Let’s say you have VPC-A(Consumer) and I am telling you that I don’t want to resolve my DNS query this VPC-A, but I have a Zone in VPC-H (Producer), and I want to forward the request to VPC H. So we are doing the query resolution from VPC to VPC. That’s called DNS peering. Sometimes people get a little confused like when do I use peering and when do I use forwarding because peering seems like it just forwards the requests but it’s not.
Still confused 🤷♀️ ? Don’t worry, Let’s take a look at the demo, things will be more clear as you follow along.
Pre-requisite:
- Two Projects. One is for Consumers and the other is Producer, where DNS records will be stored. it’s more like hub-and-spoke terminology that we can relate to.
- Two VPC networks. ( I will use the default network for the demo just to save my time, but you can also use custom VPC.)
- Cloud DNS API must be enabled in each project.
Step1. The First thing we are going to do is to create a Private DNS Zone in the Consumer project. Log into Google Cloud Console and select the first project (This is the consumer project “My Project 11118”). Go to Network Services →Cloud DNS →Create Zone.
Give your private zone a name. I named mine dev-techedge-com. In the DNS name field, enter the fully qualified domain name (FQDN) dev.techedge.com. Select the default network for this project. Next, select the peer project and its default network. Please note that you can use the same project, but in that case, you must create a different VPC. I chose a peer project to replicate the demo of a real-world scenario. Here is what your screen should look like.
Once created, your private zone is peered.
Step2. Create two sample VMs for testing within the first project (consumer). I have already created them in the default network. You can select any region. I am running them in the Delhi and Mumbai regions, as they are closest to my geographic location.
Setp3. Next, Go to Producer Project, here we need to create a private zone with the same name as used in our consumer project. This project is going to contain all your DNS records. This step is necessary because when a virtual machine (VM) sends a DNS request within the Virtual Private Cloud (VPC), Cloud DNS forwards this request to the peer network to resolve the query. By creating the private zone, we can observe how the DNS request gets resolved and ensure proper connectivity and functionality within our network environment. This is what it looks like if you are following along.
Step4. Create DNS records in the producer VPC’s Cloud DNS zone. These records will be used to resolve the names of the compute VMs.
Once records are created, we are all set to test the VMs to send the DNS queries to see if these VMs are able to resolve and ping each other with their FQDN.
Step5. If everything sets correctly, it should work as expected. SSH to Web1, and try to ping web2.dev.techedge.com you would get a ping response. Congratulations! your DNS peering is perfectly working.
Let’s also run nslookupor dig
Scenario 2: Establishing DNS Peering with Multiple VPCs.
By establishing DNS peering with multiple VPCs sending DNS queries to a central “producer” VPC, Organization can achieve efficient and streamlined DNS query resolution across its cloud-based infrastructure. This eliminates the need to create and maintain separate DNS records for each VPC.
To simulate this scenario, Add another VPC (VPC-B) in the consumer project. you need to attach this new network to your Private DNS Zone so that it can also send DNS queries to the peered project/network. Apart from this, VPC peering is a must to establish network connectivity between these two networks along with some firewall rules to open in each network. This allows VMs to cross-communicate and sends a successful ping to each other. Keep in mind, you don’t need to do anything in the peered project. Follow the steps below.
Step1. Login to Google Console, Select your consumer project and Create a custom VPC/subnet. I already created and named it vpc-b.
Step 2. Go to Cloud DNS, Select the DNS zone → Edit →Attach this new VPC from the drop-down and →Save it. Sorry, I forgot to capture the snippet. 😔
Step3. Create Peering between the VPCs. (default ← → vpc-b). Please keep in mind, Peering is required to just establish connectivity. It’s a simple task, click here to know how to set up VPC peering.
Step4. Deploy a new VM named web3 in VPC-b for testing in the later steps.
Step4. Register a DNS record in Producer projects, where your DNS was peered.
Ste5. Create a firewall rule in both networks to allow ICMP connectivity. In GCP, to enable communication between two VPC networks, a firewall rule is needed. By default, all ingress traffic is blocked, so we must create an ingress firewall rule in both networks to allow ICMP traffic. This rule permits ping requests between the two networks, ensuring VMs can communicate effectively.
Step6. Finally, Register a DNS record of the newly created VM web3 in Producer projects, where your DNS peered.
Step7. Testing. Let’s test if VMs can ping each other on fully qualified domain names. SSH to Web1 (default VPC) and send a ping request to Web3 (VPC-B). you can see that successful ping response. Now test in reverse order, it works as well.
This concludes our second demo of having multiple consumers or multi-VPC DNS peering. Multi-VPC DNS peering allows you to manage DNS records from a central project or VPC. This can be helpful for organizations that have multiple VPCs and want to simplify the management of their DNS records. If you are looking for a way to simplify the management of your DNS records and improve the performance of your DNS queries, then you should consider using multi-VPC DNS peering.
What is DNS Forwarding:
DNS forwarding is the process by which particular sets of DNS queries are handled by a designated server, rather than being handled by the initial server contacted by the client. This can be useful if you have a hybrid cloud environment and want to keep your DNS records in one place, even though your resources are hosted in two different locations.
Two types of DNS Forwarding
- Outbound Zone: from GCP to on-prem
- Inbound Policy: from on-prem to GCP
Outbound forwarding with an example: Outbound forwarding is where you have a subdomain, let’s say uat.techedge.com. If I am doing outbound forwarding, I am basically saying, for uat.techedge.com, I don’t want to resolve within the cloud, I want it to resolve, say, on-prem. So I am telling the DNS in the private environment, to go to on-Prem to resolve the IP address for let’s say vm.uat.techedge.com. That is called outbound forwarding where I am forwarding requests out of GCP to my on-Prem environment.
Hybrid Cloud is one of the use cases that use this sort of architecture. Let’s say your hybrid organization running a Dev environment on-Prem and a production environment in the cloud or maybe vice versa. so you have an authoritative server or zones created on-Prem, So in this case, you don’t want to create a whole setup in GCP but you want to tell GCP to come to the on-Prem DNS server and resolve your query right? That is the most common use case
Inbound forwarding is the exact opposite of that. Let’s say you go on-Prem and you are running dev.techedge.com in GCP. So in your on-Prem environment, you are saying, I don’t want to resolve my query in my on-Prem DNS infrastructure rather I want to actually forward that request to GCP. So From the GCP side, that request is coming in the cloud. That is called Inbound forwarding where I am forwarding requests out of on-Prem to my GCP environment. Hope this clears.
Please be mindful, The big thing to know about forwarding as we talked about that you forwarding in and out of GCP however if you are trying to forward to another VPC, you don’t use forwarding to that, and you use something called DNS peering as we have covered in our previous demo. The key takeaway from this article is to understand the clear difference between Peering and forwarding.
The other thing to keep in mind is when we do forwarding, we use proxies. You must configure your on-premises routes and firewalls to permit traffic from Google’s 35.199.192.0/19 IP address range. These IP ranges are used for Google DNS proxies. This has to be set up so that when the request is coming in from the proxy IP, you are not sort of blocking it on-prem firewall and make that IP range is allowed. I will show this in the architecture. One thing to keep in mind is that it’s a Google Public IP but it’s not something that is routable on the internet. Google owns this IP range and does not advertise on the internet and they are not reachable via the internet and they are only reachable via the cloud environment. I will not deep dive into it since this is quite complex when you implement this in your organization. Just take a basic idea of routing stuff plays a crucial role in setting up infrastructure.
Let’s talk a little bit about inbound forwarding architecture. In inbound forwarding, we are setting up an inbound policy and we also need to set up some routing stuff. here on the GCP side, you need to assign an IP address (10.148.0.0/24) that will be used for inbound forwarding. The On-prem IP ranges 192.168.0.0/24 need to be advertised to the cloud router. Also, make sure no firewall rules block the request in GCP coming from on-prem. so basically allow on-prem IP ranges as a source in your GCP firewall to talk to your cloud. Again DNS has a lot of stuff in the parallel, there are a lot of routing constructs that need have to be set up in order to make this work.
How to configure inbound DNS server policy for your Private Zone?
To configure DNS Inbound forwarding in GCP, log into Google Console, Network Service →CloudDNS →Create DNS Policy.
For Outbound forwarding, Let’s reverse it, Instead of inbound architecture, We will be forwarding outbound to something on-prem. So in this case same general setup. here you create a Zone ( Remember, in inbound, we are creating policy) but here we are actually creating a Zone. Which is an outbound zone, which is pointing to an on-Prem DNS server. Similar setup like inbound and you have to advertise the proxy range because something in GCP is going to talk to our proxies and the proxy is going to push it to outbound. Lastly, you have to do a custom route advertisement set so that the cloud router advertises 35 blocks outbound
To configure DNS Outbound forwarding in GCP, log into Google Console, Network Service →CloudDNS →Create DNS Zone and you must select Destination server which is the IP address of my on-Prem DNS server.
I will not cover the demo here since it requires a hell lot of effort to setup some sort of connections like VPN tunnels or interconnects and by the way I don’t have an on-Prem data center 😂😂 I just wanted to give you an idea and touch-up for DNS forwarding.
Multiple VPCs Resolving on On-Premise
A typical use case is that we can separate Zone and the Records in a separate network. Whatever we have read so far, we can combine and lay a whole bunch of stuff on top of each scenario to make this more complex.
Configuration Notes:
- Setup DNS Forwarding Zone in VPC Network H
- Setup DNS Peering Zones in Networks A, B, and C to point to Network H
- Google Cloud Router in Network H should be learning
192.168.0.0/24route from the on-Prem router - verify no firewall rules are blocking the
35.199.192.0/19IP block at your on-Prem environment - Set up a custom route advertisement in Network H for
35.199.192.0/19advertising to on-Prem router.
In this case, Network H on the right side as shown in the architecture diagram is the place where the Zone file are exist. This is also the place where policy exists to forward things right! so to resolve your DNS query from Network A, B, and C, we use peering to be set up from A-to-H, B-to-H, and C-to-H. Once done, Network H will handle whatever requests. Now let’s say, I want to forward a bunch of stuff to on-Prem, in this case, VPC H which is a forwarding zone, All the peering requests come into the VPC H forwarding Zone and it forwards those requests to on-Prem for resolution, and then comes back to H and then H will fan it back out. So this makes your peering architecture a centralized DNS management kind of topology.
Please note that you always have a single forwarding zone to forward out of GCP to your on-Prem, because Proxy Ranges (35.199.192.0/19) can not be distributed in the consumer or individual VPCs. Forwarding Zone has to one and that's where that proxy ranges setup and lives. So any request coming from on-premise always goes back to the Forwarding Zone network and then it further fanning everything out. Hope this makes sense. This is a very thing when you design such a type of complex DNS infrastructure in your organization.
So that is pretty much what DNS is all about. We have covered a lot and I tried to explain things a little deeper. DNS becomes complex when your organization grows, especially in a large hybrid infrastructure. To ensure that your users can access your resources quickly and reliably, you must have a good understanding of DNS peering, DNS forwarding, inbound and outbound forwarding, DNS record sets, and other DNS concepts.
I hope this article has given you a better understanding of DNS and how it works in multi-projects/VPCs and hybrid cloud infrastructures. If you have any questions, please feel free to ask in the comments. If you like this article, feel free to share and comment with any queries. I will be happy to help.
Thanks for Reading!!
Book a call for consulting/assistance: https://topmate.io/sumit_kumar40
