Google Cloud DNS is better known as Domain Name System service. It has a job to publish the domain names to the global platform or DNS with a cost-effective approach. Cloud DNS helps organizations and IT developers to publish the zones within DNS without the efforts of managing their own software and DNS servers.
Cloud DNS has the potential to do that for them! Google Cloud DNS offers public as well as privately managed zones under DNS. The public zone is set to be visible over the public internet, but the private zone is considered to be visible only from the specified VPC networks.
Interested in Google Cloud Certifications? Whizlab provides high class online courses, practice tests and free tests. Check them out here!
With the implementation of shared VPC, Cloud DNS-managed zones, such as private zone, DNS forwarding zone, and DNS peering zone, will be created within the host project. In case of the private zones, Google Cloud takes the load of providing inbound & outbound DNS. Apart from all of it, Cloud DNS is also offering DNS server policies and forwarding zones to permit the lookup sessions for special DNS names between the Google Cloud environment and on-premises cloud environment.
Cloud DNS intends to offer you service proficiency! Therefore, if you intend to learn more about this service by Google, you should put your efforts into finishing off this article! In this article, you will intend to get clarity upon how Cloud DNS service does its part in helping businesses and organizations thrive.
Working Overview of Cloud DNS
Domain Name System (DNS) is termed to be a distributed database that operates upon a specified hierarchy. It allows you to store IP addresses over its server, along with all of the other important data. Along with that, DNS also allows you to look and assess that data by searching it as per the names that you used to store it. Google Cloud has stacked up inbound & outbound DNS forwarding methods for the private zones. You have the potential to configure the DNS forwarding aspects by creating a respective zone or a DNS server policy.
Click Here to read more about Introduction to Google Cloud Platform!
Under the inbound forwarding method for the private zones, you are demanded to create a server policy, especially for inbound implementation. It is to enable the on-premises server or client for DNS to send the requests to Google Cloud DNS. As a result, the DNS server or client will be able to resolve the records as per the name-resolution order of the VPC network. The clients over the on-premises DNS servers have the potential to resolve records within forwarding, peering, and private zones. The VPC network is authorized for the same!
For outbound DNS forwarding methods, you are allowed to configure the VMs in a specific VPC network for different service aspects. You can configure the virtual machines for sending DNS requests to the specific DNS servers, as per your choice. You will be able to locate the name servers within the same VPC network. When you locate the same, it can be either over the internet or any on-premise network. Not just that, but the VMs you create can help you resolve the records that are being hosted over the name servers.
All of the resolved records are under the configuration of forwarding targets of a specific forwarding zone. It has the authorization for use by the specified VPC network. If you intend to learn more about the forwarding targets and the routing methods, then you can refer to this official documentation by Google.
With Cloud DNS, you have the liberty to put up the configuration of inbound & outbound DNS forwarding for the VPC network. There is a bi-directional forwarding potential that allows the Virtual Machines (VMs) within the VPC network, resolves the records upon the on-premise network or other networks that are hosted or carried out by diverse cloud providers. Hence, this kind of forwarding method gives potential to the hosts over the on-premise network to resolve the records for all of your resources within Google Cloud.
The control plane of Cloud DNS makes use of an algorithm for determining the responsiveness of any forwarding target. The outbound queries that are forwarded might experience certain server failure errors during their execution. There is a specific approach towards rectifying and managing it. Check out this documentation to understand more about server failure or SERVFAIL errors upon outbound forward queries.
Pricing for Cloud DNS
The pricing associated with Cloud DNS is based upon per zone per month aspects. It doesn’t matter whether you are using your zone or not, but you have to pay for it every month. Apart from that, you are also liable to pay for the queries that are present within your zone.
The pricing is uniform for all the zones, public, forwarding, or private. It means that if you have 10 zones of each, then your overall billing will be upon 30 zones uniformly. All of the queries are also aggregates, without concern upon the zone type. The pricing list for Cloud DNS is as follows:
1. Query Pricing
- For the number of queries, ranging between 0 to 1 billion, you will have to pay $0.40 per million queries/month.
- When the number of queries crosses the 1 billion mark, then you will have to pay $0.20 per million queries/month.
2. Zone Pricing (Managed)
- If you have a total of 0 to 25 zones, then you will have to pay $0.20 per managed zone/month.
- If you have a total of 26 to 10,000 zones, then you will have to pay $0.10 per managed zone/month.
- If you have a total of over 10,000 zones, then you will have to pay $0.03 per managed zone/month.
Server Types and Routing Methods within Cloud DNS
The DNS server policies have the potential to specify inbound and outbound DNS forwarding. Not just that, but by specifying the server policies in an ideal manner, you can specify both of these forwarding methods at once. A DNS server takes the mantle of storing the database of the domain names and then processes them, as per the DNS queries, that come from any of the clients within a network.
There are two types of servers available over Google Cloud DNS, that includes Authoritative server and Recursive resolver. Here is a brief description for both of them:
1. Authoritative Server
Authoritative server takes the responsibility of holding the DNS name records, which involves CNAME, A, AAAA. Any of the DNS servers that are non-authoritative tends to construct cache files, with resemblance to the past queries for domains. There is no option for holding out original name records.
2. Recursive Resolver
It is the DNS server that sends out queries to both authoritative & non-authoritative servers for resolution. The name of this server intends that it has the potential of performing each of the queries for the name provided and returns the final output.
Supported DNS record types
Cloud DNS supports the following types of records
|Address record, which maps host names to their IPv4 address.
|IPv6 address record, which maps host names to their IPv6 address.
|Certificate Authority (CA) Authorization, which specifies which CAs are allowed to create certificates for a domain.
|Canonical name record, which specifies alias names.
|The DNSSEC key from another operator for secure transfer. This record set type can only be added to a DNSSEC-enabled zone in Transfer state.
|The DNSSEC key fingerprint for secure delegated zone. This record set type does not activate DNSSEC for a delegated zone unless you enable (and activate) DNSSEC for this zone.
|IPsec tunnel gateway data and public keys for IPsec-capable clients to enable opportunistic encryption.
|Mail exchange record, which routes requests to mail servers.
|Naming authority pointer record, defined by RFC 3403
|Name server record, which delegates a DNS zone to an authoritative server.
|Pointer record, which is often used for reverse DNS lookups.
|Start of authority record, which specifies authoritative information about a DNS zone. An SOA resource record is created for you when you create your managed zone. You can modify the record as needed (for example, you can change the serial number to an arbitrary number to support date-based versioning).
|Sender Policy Framework record, a deprecated record type formerly used in email validation systems (use a TXT record instead).
|Service locator record, which is used by some voice over IP (VoIP), instant messaging protocols, and other applications.
|SSH fingerprint for SSH clients to validate the public keys of SSH servers.
|TLS authentication record for TLS clients to validate X.509 server certificates.
|Text record, which can contain arbitrary text and can also be used to define machine-readable data, such as security or abuse prevention information.
A TXT record can contain one or more text strings; the maximum length of each individual string is 255 characters
When you intend to add the forwarding targets to the forwarding zones, then you are demanded to choose between two available routing methods. The two methods include Standard Routing and Private Routing. Standard routing has the potential of routing the traffic through the authorized VPC network or through the internet, depending upon the IP address of the forwarding target. It should be RFC 1918 IP address! But in the case of private routing, the traffic is always routed through the authorized VPC network, without depending upon the IP address of forwarding target.
There are basically three types of forwarding targets that are named as Type 1, Type 2, and Type 3. They are different from one another in terms of their standard and private routing supports. Here is a brief elaboration upon all of these forwarding target types.
1. Type 1
It is an internal IP address of the Google Cloud Virtual Machine within the same VPC network. It is authorized especially to make use of the forwarding zone.
2. Type 2
It is an IP address over the on-premises system that is connected seamlessly to the VPC network. It has the authorization to query the associated forwarding zone using Cloud Interconnect and Cloud VPN.
3. Type 3
It is an external IP address of the DNS server that is accessible to the internet or external IP of Google Cloud resource. For instance, this type can allow access to external IP of VM in some other VPC network.
For accessing the Type 1 or Type 2 forwarding target, Cloud DNS intends to adapt routing within the authorized VPC network. There is no such compulsion to consider the IP address of the target. For sending traffic to the Type 1 forwarding targets, Cloud DNS makes use of subnet routes that are automatically created! For replying, these forwarding targets then make use of a specific return route for the Cloud DNS responses.
If you intend to send traffic to Type 2 forwarding target, then Cloud DNS will use custom static routes or dynamic routes. But the custom static routes that come with network tags are not feasible to be used over Type 2 targets. Along with that, the Type 2 targets make use of routes within the on-premises network for replying. If you wish to learn more about the network requirements associated with Type 1 & Type 2 targets, you can check upon this official documentation that highlights the network requirements.
Process of Setting up Domain with the use of Google Cloud DNS
As of now, you are well aware of how Google Cloud DNS helps streamline the accessibility of your data. Now is the time for you to learn the ideal steps to set up a domain to begin its implementation. The following process of setting up a domain is considering that you already have your Google Cloud account over the portal. The next steps are as follows:
Step 1: Register the Domain
- Head out to Google Domains by clicking on this link. If you already have a domain, then you can head directly to Step 2 by skipping it.
- Check for all of the names that are available to be picked as a domain.
- Choose any available name as your domain.
- Add it to the cart for buying it.
- You need to set the auto-renewal and privacy settings before making the final purchase.
- Complete the registration process, and then make the purchase.
- You can head to the ‘My Domain’ section to check out the domains that you own.
Step 2: Creating VM Instance
- Head to the ‘VM Instances’ page over the Google cloud portal.
- Click on ‘Create instance.’
- Go to the ‘Boot Disk’ section. You will now have to click upon ‘Change’ to begin with configuration of the boot disk.
- When you reach for the ‘Public Images’ tab, you will have to choose ‘Debian Version 9’ over it.
- Now, go ahead and click on select.
- Head to the ‘Firewall’ section, and select the option that says, ‘Allow HTTP Traffic.’
- Now, click on ‘Create’ to complete the creation of the VM instance.
- Head to the VM instances page, and click on ‘SSH’ on the instance that you created. It will let you connect to your instance.
Step 3: Setting up Domain with Cloud DNS
- Head to ‘Create a DNS Zone page’ over the console.
- Select ‘Public’ over the tab, Zone Type.
- Enter zone name in the dedicated section.
- Turn off the DNSSEC setting
- Now, click on ‘Create’ to create the DNS zone.
- For pointing the domain name to the IP address of hosting server, add A record to the zone.
- Head to the zone details page, click on ‘Add Record Set.’
- Select ‘A’ for the ‘Resource Record Type’ menu.
- Under the ‘IPv4’ section, give the external IP of your instance.
- Now, click on ‘Create’ to set the A record for your zone.
Google Cloud DNS has 100% availability and assures low latency. It supports automatic scaling to a large number of records and zones. You have the reliability to create & update millions of DNS records. The name servers over Cloud DNS scales on automatic measures to handle the complete query volume.
Cloud DNS makes use of the global network of anycast servers to serve the DNS zones. Hence, this is the potential that Google Cloud offers its users for streamlining their business and organizational approaches. Head out to get practical experience upon using Cloud DNS.
Assess your understanding of Cloud DNS- Click Here
No Credit Card Required
- Cloud DNS – A Complete Guide - December 15, 2021
- Google Compute Engine: Features and Advantages - December 14, 2021
- What is Cloud Run? - December 13, 2021
- What is Cloud Load Balancing? A Complete Guide - December 9, 2021
- What is a BigTable? - December 8, 2021
- Docker Image creation – Everything You Should Know! - November 25, 2021
- What is BigQuery? - November 19, 2021
- Docker Architecture in Detail - October 6, 2021