Cloud DNS
1. Cloud DNS
Next, let's talk about Cloud DNS. Before we talk about Cloud DNS, let's quickly review how DNS or domain name system works. DNS provides a lookup for sites on the Internet. You can think of it as a phonebook, but instead of using the name of an organization to look up its phone number, you use the name of an organization defined in IP address. A DNS service is provided by your ISP or Internet service provider. For example, suppose a request comes from a client computer to access cymbal.com. To direct the client computer to the cymbal.com site, the Internet service provider needs the IP address of cymbal.com. The ISP connects to get this information from its DNS service. The DNS service recursive resolver issues a request to look up the IP address of cymbal.com from one of its name servers. The name server responds with the ISP, and the recursive resolver sends the IP to the client. When the name server cannot satisfy the lookup, the DNS service might contact another DNS service for this information. Some organizations don't rely on their ISP to provide DNS service, so they create and maintain their own DNS servers. Organizations sometimes do this to limit or customize the information that is returned or because they can achieve better performance if they use their own DNS servers. Alternatively, they can purchase DNS services from another organization. Obviously, there's a lot more that can be said about DNS and its components, but that's not covered in this course. Various companies provide DNS services. Google Cloud is one of them. Cloud DNS lets you create and update millions of DNS records without the burden of managing your own DNS servers and software. Instead, you use a simple user interface, command line interface, or API. On Linux by default, the VM's metadata server 169.254.169.254 resolves internal DNS names. Now, Windows by default, subnet default gateway resolves internal DNS names. Google provides a monthly uptime percentage of serving DNS queries from at least one of the Google managed authoritative name servers to customers of 100% SLO. Important notes, exclusions. It's crucial to understand there are certain situations such as maintenance, force majeure events or actions on your part that void this SLA. Intermittent issues. The downtime definition specifically focuses on at least 60 consecutive seconds of unavailability. Intermittent issues, less than a minute might not count towards the SLA. Private zones are used to provide a namespace that is visible only inside the VPC or hybrid network environment. For example, an organization would use a private zone for a domain dev.gcp.example.com, which is reachable only from within the company Internet. Public zones are used to provide authoritative DNS resolution to clients on the public Internet. For example, a business would use a public zone for its external website cymbal.com, which is accessible directly from the Internet. Don't confuse the concept of a public zone with Google public DNS 8.8.8.8. Google public DNS is just a public recursive resolver. For more information, refer to the Cloud DNS documentation. Cloud DNS policies provide a flexible way to define how your organization uses DNS. After you create the DNS zones and artifacts needed for lookups, create Cloud DNS policies. Cloud DNS supports different types of policies. Server policies apply private DNS configuration to a VPC network. Response policies enable you to modify the behavior of the DNS resolver by using rules that you define. Routing policies steer traffic based on geolocation or round robin. Next, let's look at each of these types of policies. Use server policies to set up hybrid deployment for DNS resolution. You can configure DNS server policy for each virtual private cloud or VPC network. You can set up an inbound server policy depending on the direction of the DNS resolutions. If your workloads plan to use an on-premises DNS resolver, you can set up DNS forwarding zones by using an outbound server policy. If you want your on-premises workloads to resolve Cloud DNS private zones, you can set up an inbound server policy. The policy can specify inbound DNS forwarding, outbound DNS forwarding or both. In this section, inbound server policy refers to a policy that permits inbound DNS forwarding. Outbound server policy refers to one possible method for implementing outbound DNS forwarding. If a policy implements the features of both, it can be an inbound server policy and an outbound server policy. DNS server policies are not available for legacy networks. DNS server policies require VPC networks. For detailed information about server policies, see server policies overview in the Google Cloud documentation. To configure and apply DNS server policies, see apply Cloud DNS server policies in the Google Cloud documentation. A response policy is a Cloud DNS private zone concept that contains rules instead of records. These rules can be used to achieve effects similar to the DNS response policy zone, RPZ draft concept. In other words, you can use response policies to create a DNS firewall by returning modified DNS results to clients. For example, you can use response policies to block access to specified HTTP servers. The response policy feature lets you introduce customized rules in DNS servers within your network that the DNS resolver consults during lookups. If a rule in the response policy affects the incoming query, it's processed. Otherwise, the lookup proceeds normally. For more information, see manage response policies and rules in the Google Cloud documentation. A response policy is different from an RPZ or response policy zone. An RPZ is an otherwise normal DNS zone with specifically formatted data that causes compatible resolvers to do special things. Response policies are not DNS zones and are managed separately in the API. To create and modify response policies in Cloud DNS, use the response policies API. Response policies are separate from managed zones and cannot be managed by using either the managed zones API or the RR set API. DNS routing policies let you steer your traffic based on specific criteria. Google Cloud supports three types of DNS routing policies: weighted round robin, geolocation, geofencing and failover. A weighted round robin routing policy lets you specify different weights per DNS target, and Cloud DNS ensures that your traffic is distributed according to the weights. You can use this policy to support manual, active active, or active passive configurations. You can also split traffic between production and experimental versions of software. A geolocation routing policy let's you map traffic originating from source geographies, Google Cloud regions to specific DNS targets. Use this policy to distribute incoming requests to different service instances based on the traffic's origin. You can use this feature with the Internet, with external traffic, or with traffic originating within Google Cloud and bound for internal load balancers. Google Cloud uses the region where the queries enter Google Cloud as the source geography. A failover routing policy, lets you set up active backup configurations. This option is only available for private zones. Next, you will implement a geolocation routing policy as part of a lab exercise. An example is shown on the screen. Routing policies use geolocation to route requests to the closest load balancer. In a lab exercise, you will configure a routing policy that uses geolocation. To create, edit, or delete DNS routing policies, see manage DNS routing policies in the Google Cloud documentation. Let us look at a scenario before we move on to the lab exercise. Carl is a network engineer at Cymbal Corporation. Cymbal has a hybrid environment with an on-premises data center in Europe and a Google Cloud environment with VPC subnets in Asia and the US. Carl does not want to juggle managing multiple DNS providers for their global web presence. Fragmented setup leads to inconsistencies, manual configuration overhead, and potential for human error. Carl is looking for a solution that can provide a single endpoint for a hybrid application so that external clients in multiple regions resolve www.cymbal.com to the nearest region. Carl can leverage Cloud DNS for its global anycast network for low latency DNS resolution and high availability. The intuitive interface simplifies record management, offering features like health checks and traffic routing. Cloud DNS provides global traffic management for www.cymbal.com, routing users to the closest available server. Asia and US-based visitors are directed to network load balancers within their respective regions, which connect them to GKE instances. European users, a load balancer in European data center handles traffic, forwarding to GKE on VMware. This setup demonstrates flexibility in application hosting. Carl can create this configuration by using the following steps. Carl creates the network load balancers, and the on-premises load balancer in each region. Carl sets up a public Cloud DNS zone for his domain. Cloud DNS automatically assigns anycast name servers to handle domain record storage. These name servers are strategically located in a fully managed shared environment. Then they create a DNS routing policy. In the policy, you set the type to GEO, and you set the routing policy data value to a list of target regions that are mapped to the corresponding network load balancers. When configuring routing policies, consider these caveats. Only one type of routing policy can be applied to a resource record set at a time, and nesting or otherwise combining routing policies is not supported.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.