Google Cloud (Load Balancing and DNS): From a Domain Name to a Healthy Application (Part 6)

When a user opens a website, several things happen before the application responds. DNS resolves the hostname, the client connects to the application’s entry point, and a load balancer routes the request to a suitable backend.

These four services address different parts of that journey:

Service	Main purpose	Practical example
Cloud Domains	Register and manage domain names	Register a domain for a customer portal
Cloud DNS	Publish and resolve DNS records	Point portal.example.com to a load balancer
Cloud Load Balancing	Distribute application traffic	Route requests across healthy application instances
Service Extensions	Add custom logic to supported traffic-processing paths	Apply custom header or request-processing logic

The examples below are illustrative designs.

1. Cloud Load Balancing — Route requests to application backends

Cloud Load Balancing is a managed portfolio of load balancers. Select the type according to protocol, access requirements, geographic scope, and backend support.

Load balancer family	Typical purpose
Application Load Balancer	HTTP/HTTPS routing, including hostname and path rules
Proxy Network Load Balancer	Supported TCP traffic using a proxy
Passthrough Network Load Balancer	Supported network protocols where packet-level forwarding is required

External, internal, regional, and global options differ by load balancer type. Not every load balancer supports every feature.

Practical example: a customer portal

Suggested hands-on exercise

1. Deploy two demo web servers.
2. Configure their backend group.
3. Create an appropriate health check.
4. Configure the backend service and routing.
5. Configure the frontend IP, HTTPS listener, and certificate.
6. Test the application.
7. Stop one demo backend and observe traffic behavior.

Interview question: Is load balancing the same as autoscaling?

No. Load balancing distributes requests. Autoscaling adjusts backend capacity. They work together but perform different functions.

Common mistake: Assuming a load balancer makes the database, sessions, and application dependencies highly available.

2. Cloud DNS — Translate names into connection information

Cloud DNS hosts managed DNS zones and records.

• Public zones publish records for internet resolution.
• Private zones make records available through authorized VPC networks.
• Forwarding configurations can support name resolution between cloud and on-premises environments.

Practical example

Use a public record for a customer portal and a private record for an internal API.

Record	Purpose	Example
A	Maps a name to an IPv4 address	Portal name → load-balancer IPv4
AAAA	Maps a name to an IPv6 address	Portal name → supported IPv6 frontend
CNAME	Makes one name an alias of another	A subdomain → another hostname
MX	Identifies mail servers	Domain email routing
TXT	Stores text values	Domain verification or email policies
NS	Identifies authoritative name servers	Delegates a DNS zone

DNS participates in name resolution; application requests do not pass through Cloud DNS.

Hands-on checks

On Windows:

nslookup portal.example.com
Resolve-DnsName portal.example.com -Type A

On Linux:

dig portal.example.com A
dig example.com NS

Interview question: Why might users still reach the old IP after a DNS change?

Their resolver or client might have a cached answer. I check authoritative records, delegation, TTL, and cache behavior.

Common mistake: Treating DNS resolution as proof that the application port is reachable.

3. Cloud Domains — Manage domain registration

Cloud Domains lets you register and manage supported domain names through Google Cloud. You separately choose a DNS provider, such as Cloud DNS or custom name servers.

Cloud Domains and Cloud DNS are different services with separate charges. Cloud Domains is also distinct from the former Google Domains consumer service, whose registrations were acquired by Squarespace.

Practical example: launch a new portal

1. Search for an available domain.
2. Review registration and renewal costs.
3. Register the domain and complete required contact verification.
4. Select the authoritative DNS provider.
5. Configure DNS records for the application.
6. Verify resolution and HTTPS.
7. Monitor renewal and billing status.

Interview question: Can I use Cloud DNS with a domain registered elsewhere?

Yes. Configure the domain’s delegation at its registrar to use the appropriate Cloud DNS name servers.

Common mistake: Registering a domain and expecting it to host a website automatically. Registration, DNS, application hosting, and certificates are separate parts of the setup.

4. Service Extensions — Customize supported request processing

Service Extensions adds custom logic to supported Google Cloud networking products.

Two approaches are available:

Approach	How it works	Operational consideration
Plugins	Run supported WebAssembly logic on Google-managed infrastructure	Follow sandbox and runtime restrictions
Callouts	Invoke an external processing service through supported gRPC interfaces	Manage processor capacity, availability, and latency

Supported stages and capabilities depend on the product and extension type.

Practical example: custom request metadata

A platform adds a trusted classification header based on approved request-processing rules.

Suggested implementation workflow

1. Define the business requirement.
2. Check whether native load-balancer features already satisfy it.
3. Confirm extension support for the selected product.
4. Choose a plugin or callout.
5. Configure matching rules and processing behavior.
6. Test normal requests, processor failures, and latency.
7. Monitor the extension after deployment.

Interview question: What risk does a callout introduce?

It adds a dependency in the request path. I evaluate its latency, capacity, availability, timeout behavior, and configured handling of failures.

Common mistake: Assuming an extension automatically fails open or fails closed. Verify the configured behavior for the chosen extension.

Putting the services together

For an illustrative customer portal:

Step	Capability	What happens
1	Domain registration	Establish ownership of the domain
2	DNS delegation	Identify its authoritative name servers
3	Cloud DNS	Return the application frontend address
4	Cloud Load Balancing	Receive and route the request
5	Optional Service Extensions	Apply supported custom processing
6	Application backend	Process the request and return a response

A practical troubleshooting flow

A useful diagnostic is to test the expected frontend while preserving the hostname and TLS validation:

curl -v --resolve portal.example.com:443:LOAD_BALANCER_IP \
  https://portal.example.com/

Replace the hostname and IP with your demo values. This helps distinguish a DNS problem from an HTTPS or application problem.

Interview answer

“Cloud Domains manages registration, and Cloud DNS publishes the records used to locate the application. Cloud Load Balancing receives traffic and routes it to supported backends. Service Extensions adds optional custom processing. During an incident, I investigate resolution, frontend connectivity, TLS, backend routing, and application behavior separately.”