Huawei Cloud Cashback Credits Setting Up Private Zones for Huawei Cloud Internal DNS

Huawei Cloud / 2026-04-27 23:15:11

Introduction: The DNS Party Nobody Asked For (But Everybody Needs)

Internal DNS is one of those things that feels optional until it suddenly isn’t. The day you deploy a few services, you can reach everything by IP. The next day, someone asks, “Can we rename that thing?” Then another day comes—where applications start “mysteriously” failing, caches get stubborn, and your team begins debating whether the issue is code, routing, or the invisible magic that turns names into addresses.

Huawei Cloud’s private zones help you solve this properly for internal networks. Instead of relying on external DNS or ad-hoc hosts files (which are basically DNS in its most chaotic form), private zones give you a dedicated, controllable namespace inside your cloud environment. The goal is simple: make internal services resolvable by name, consistently, and safely.

This guide is written for practitioners who like things to work. We’ll cover planning, prerequisites, zone creation, record management, VPC associations, verification, and troubleshooting. Along the way, I’ll point out common mistakes that can turn your internal DNS into a horror movie titled “Why Is It Still Resolving to the Old IP?”

What Are Private Zones in Huawei Cloud Internal DNS?

A private zone in Huawei Cloud internal DNS is a DNS namespace that is intended for internal use. When clients inside the associated virtual networks query a domain name that belongs to the private zone, the DNS service returns the records you create—A/AAAA, CNAME, MX, TXT, and so on (depending on what’s supported in the product and configuration).

Think of it as running your own “corporate directory” for cloud resources, without relying on external resolvers. You control what answers clients get, and you can scope visibility by associating the zone with one or more VPCs or networks (based on your architecture).

When Should You Use Private Zones?

Use private zones when any of the following rings true:

You want consistent service discovery by name (e.g., api.internal.example.com instead of 10.0.2.17).
You run microservices that scale and change IPs, and you don’t want to update client configs every time.
You have internal dependencies like databases, message brokers, and private endpoints that must resolve privately.
You need controlled split behavior (internal clients resolve differently than external clients).
You want predictable DNS responses for compliance and stability.

Planning First: The Unsexy Part That Saves You From Rework

Before touching the console, spend a few minutes designing the namespace and record strategy. DNS misdesign is like bad cabling: it works… until you have to change anything.

1) Choose a Domain Name Strategy

Common options include:

Dedicated internal domain: e.g., internal.example.com
Subdomain for private zones: e.g., corp.example.com for internal only
Environment separation: dev.internal.example.com, staging.internal.example.com, prod.internal.example.com

Tip: If you expect multiple environments, separate them now. Retroactively splitting domains later usually involves painful cleanup.

2) Decide Record Ownership and Lifecycle

Ask yourself: who updates DNS records when something changes?

If you have static IPs (rarely ideal), you can create stable A records.
If services are behind load balancers, you can point names to LB IPs or endpoints.
If you use dynamic scaling, you may need automation (or ensure that your service endpoints remain stable).

Also decide record TTLs. A short TTL makes changes propagate faster but can increase query load. A long TTL reduces load but means clients stubbornly cling to old answers.

3) Prevent Name Collisions

Huawei Cloud Cashback Credits Decide how you’ll handle:

Overlapping names across environments
Legacy hostnames (everyone has a favorite old name that “must keep working”)
Conflicting records (e.g., someone creates an A record where a CNAME should be)

In DNS, conflicts aren’t theoretical; they’re practical. And they usually show up at 2 a.m.

Prerequisites: What You Need Before Creating a Private Zone

While the exact console steps vary by Huawei Cloud service version and your account permissions, the typical prerequisites are:

Access permissions to manage internal DNS/private zones and to view VPC information
VPC(s) and network connectivity where clients will query DNS
Planned record targets (IP addresses, load balancer endpoints, etc.)
Client-side DNS configuration so instances use the internal DNS resolver (or are forwarded/linked appropriately)

If your instances currently use some other DNS, your new private zone might exist perfectly but will remain “invisible” to clients. That’s not DNS’s fault—it’s the client’s fault for not listening.

Creating a Private Zone: Step-by-Step

Let’s walk through the typical workflow for setting up a private zone in Huawei Cloud internal DNS.

Step 1: Open the Internal DNS Service

Navigate to Huawei Cloud’s internal DNS section (often under networking services). Make sure you’re in the right region. DNS is region-sensitive in many setups, and the internet is not going to route your internal domain back to the correct region just because you asked nicely.

Step 2: Create a New Private Zone

Choose Create Zone (or equivalent). You’ll be prompted for:

Zone name (e.g., internal.example.com)
Zone type (private/internal)
Associated networks/VPCs (or you’ll add associations after zone creation)

Double-check the trailing dot situation in your mental model: DNS tooling sometimes treats internal.example.com and internal.example.com. differently in UI, but conceptually they’re the same. The console usually helps you avoid mistakes, but you still want to be awake.

Step 3: Associate the Zone with VPC(s)

Now comes the part that decides whether your clients can actually benefit.

You typically associate the private zone with one or more VPCs. The purpose is straightforward: internal DNS will be reachable for those networks, and queries originating from them will resolve using your private zone records.

Common scenario:

Your application VPC hosts web and service instances.
Your data VPC hosts databases.
Both VPCs need to resolve internal service names.

In this case, associate the private zone with both VPCs, or use a design where queries are routed centrally.

If you only associate one VPC, the other VPC’s instances will continue to stare at you blankly when you request db.internal.example.com.

Step 4: Add DNS Records

This is where you do the actual work. You create resource records inside the zone.

Typical records include:

A records: service.internal.example.com -> IPv4 address
CNAME records: api.internal.example.com -> api-lb.internal.example.com
TXT records: for verification or custom data

Example (practical and boring, which is good):

db.internal.example.com -> 10.10.3.25
redis.internal.example.com -> 10.10.4.12
api.internal.example.com -> CNAME to api-lb.internal.example.com
Huawei Cloud Cashback Credits api-lb.internal.example.com -> 10.10.2.50

If you use load balancers or private endpoints, point DNS to stable endpoints rather than ephemeral instance IPs. Otherwise, your records will be right for about as long as it takes for autoscaling to do its job.

Step 5: Configure TTL and Update Policy

When creating each record, choose TTL. A common default might be 300 seconds. If you’re actively iterating, you might choose shorter TTL temporarily (e.g., 60 seconds) and then increase it once stable.

Here’s the humor part: DNS changes propagate when clients stop believing the old answer. If your clients have a long TTL cached, your updates will feel like they “did nothing,” when in fact they did exactly what they were told. The clients just refused to listen.

Understanding Split-Horizon Behavior (Internal vs External)

One of the biggest reasons to use private zones is to create different answers for internal and external clients. This is called split-horizon DNS (or split-view, depending on terminology).

For example:

Internal clients query payments.internal.example.com and get an internal IP or private endpoint.
External clients (or the public internet) query payments.internal.example.com and may get a different record or no record.

Depending on your design, you might:

Maintain separate public DNS and private DNS records
Ensure forwarding rules prevent internal DNS from leaking sensitive details

Even if Huawei Cloud internal DNS doesn’t automatically enforce every policy by itself, designing split-horizon behavior is the foundation for secure and reliable resolution.

Client Setup: Making Sure Instances Actually Use the Private DNS

Creating the private zone is only half the battle. Your instances must query the internal DNS resolver.

Check Instance Resolver Settings

On Linux instances, DNS resolver settings typically live in /etc/resolv.conf (or are managed by system services). On Windows, it’s in network adapter DNS configuration or DHCP settings.

Huawei Cloud Cashback Credits You want your instances to use the internal DNS resolver addresses provided by Huawei Cloud configuration. Sometimes you can:

Set DHCP options so instances automatically receive correct resolvers
Set VPC-level DNS or network settings
Manually configure resolvers on instances

If you don’t do this, you’ll experience the classic symptoms:

Queries time out
NXDOMAIN occurs even though you created the records
It resolves to something else (because public DNS is taking the query)

Verification: How to Prove It Works (Without Guessing)

Verification is where you separate confident operations from hopeful operations.

Use dig or nslookup from a Test Instance

From an instance inside the associated VPC:

dig api.internal.example.com
nslookup db.internal.example.com
Verify A/CNAME resolution chains

What you want to see:

The record exists under the correct zone
The answer points to the expected IP (or expected CNAME target)
TTL values match your expectations

Cross-VPC Testing

If you associated the private zone with multiple VPCs, test from each one. The most common “it works but not for everyone” issue is a missing association or inconsistent resolver configuration.

Check DNS Query Logs (If Available)

Some platforms provide query logs, metrics, or traces. If resolution fails, query logs can reveal whether:

The query reached the internal DNS
The zone was found
The record matched
Responses were served with the expected records

Logs are the grown-up way to debug. Guessing is the hobby.

Common Pitfalls (And How to Avoid Them)

Here are the classics. If you’ve been around DNS long enough, you’ll recognize them instantly. If not, consider this your protective charm.

1) Overlapping CIDR and Routing Confusion

Huawei Cloud Cashback Credits If your network design involves multiple VPCs and connectivity (peering, gateways, transit), overlapping CIDRs can cause weird routing problems. DNS might resolve correctly, but traffic still fails because packets can’t route.

So remember: DNS resolution answers “where,” but network connectivity answers “how to get there.” Both must be correct.

2) Clients Still Cache Old Answers

After updating records, clients may continue to use cached responses. This is normal behavior based on TTL and resolver caching.

Mitigations:

Huawei Cloud Cashback Credits Lower TTL ahead of planned changes
Restart application DNS caches if applicable
Flush OS DNS cache (platform-specific)
Test with direct DNS queries to bypass app caching

3) Record Types Misused (CNAME vs A Records)

DNS rules matter. For example, a name that is a CNAME typically shouldn’t also have A records in many systems. Some DNS providers enforce strict behavior.

Make sure your record strategy is coherent:

Use CNAME when you want an alias to another hostname
Use A records when mapping directly to IPs

4) Forgetting to Associate the Zone with the Right VPC

It’s easy to create the zone, create records, run a test from the “right” subnet, and celebrate too early. Then someone deploys in another VPC and discovers they can’t resolve the name.

Always test from every environment that needs the records.

5) Using Instance IPs Instead of Stable Endpoints

Autoscaling and replacement can change instance IPs. If your DNS points to instance IPs directly, you’ll spend your weekends chasing records.

Huawei Cloud Cashback Credits Better options:

Use load balancer endpoints
Use stable private IPs reserved for network interfaces
Automate DNS updates if you must use dynamic endpoints

Example Architecture: A Clean Internal Service Name Setup

Let’s outline a common setup.

Use Case

You have:

An application tier VPC where web/app servers run
A database tier VPC where databases run
A private load balancer for the application API

DNS Plan

Huawei Cloud Cashback Credits Zone: internal.example.com
api.internal.example.com - CNAME to api-lb.internal.example.com
api-lb.internal.example.com - A to load balancer private IP
db.internal.example.com - A to database endpoint IP
cache.internal.example.com - A to redis endpoint IP

Association Plan

Associate the private zone with both the application and database VPCs
Ensure instances in both VPCs use internal DNS resolvers

Outcome

Now all services can refer to dependencies by stable hostnames. Deployment becomes “update records if needed,” not “rip and replace config every time an IP changes.” Your future self will send a thank-you note. Probably via a commit message.

Troubleshooting Guide: When Resolution Fails

When something breaks, follow a logical sequence. DNS issues are layered: name resolution, then routing, then service health.

Step 1: Confirm the Query Reaches the DNS Resolver

From the client, run nslookup/dig and ensure it points to the expected resolver (some tools let you specify server).
Huawei Cloud Cashback Credits If queries timeout, your resolver reachability is broken (security group, route table, or resolver address issue).

Step 2: Confirm the Zone Is Matched

Try querying a name inside the zone (e.g., db.internal.example.com).
Check for typos: DNS is brutally literal. One missing character and you’re effectively asking a different universe.

Step 3: Confirm Record Existence and Type

Verify the record is created under the correct hostname.
Verify it is the correct type (A vs CNAME).
Verify TTL isn’t misleading you during testing.

Step 4: Validate Network Connectivity to the Resolved IP

Once you confirm DNS answers correctly, test connectivity to the target IP (e.g., ping where appropriate, or use application-level checks).
Firewall/security rules might block traffic even when DNS is perfect.

Step 5: Handle Caching

If you recently updated records, retest from multiple clients.
Use tools that allow querying authoritative answers (direct server queries).

Operational Best Practices: Keep Your DNS From Becoming a Museum

DNS tends to accumulate historical artifacts. Names that were once valid become stale. Services move. IPs change. People forget which record is actually used.

Here’s how to keep DNS healthy:

Use naming conventions (service-first, environment-aware, consistent prefixes).
Document records with comments in your runbook (since consoles may not store rich documentation).
Use shorter TTL during migrations, longer TTL when stable.
Automate updates when possible for endpoints that can change.
Regularly review and remove unused records to reduce confusion.

Security Considerations: DNS Is Convenient, So It Must Be Controlled

Internal DNS doesn’t automatically mean “ignore security.” It means “the security model changes.” You should still think about:

Principle of least privilege: restrict who can create or modify records
Restrict zone associations to required VPCs only
Avoid exposing sensitive mappings unnecessarily
Use proper network controls so only authorized instances can query DNS resolvers

DNS records are metadata about your infrastructure. Even if the IPs are “private,” they can still reveal architecture details.

A Practical Checklist: “Did We Really Set This Up?”

Before you declare victory, run through this checklist:

A private zone exists with the correct name (e.g., internal.example.com).
The zone is associated with every VPC that needs resolution.
Records (A/CNAME) exist with correct hostnames and correct targets.
Clients use the intended internal DNS resolver.
From each VPC, dig/nslookup returns the expected answers.
Network connectivity to resolved IPs works (security groups, routes).
TTL behavior is understood (no surprise caching).

Conclusion: Internal DNS Should Feel Boring

The best internal DNS setup is the one you barely notice. It should just resolve names consistently, help services find each other, and reduce operational friction. If it’s working, nobody writes a blog post about it—which is exactly the point.

By planning your namespace, creating private zones thoughtfully, associating them with the correct VPCs, maintaining clean record strategies, and verifying resolution with real queries, you can build a reliable internal naming system in Huawei Cloud. And when issues happen (because issues always happen), you’ll have a structured troubleshooting path that doesn’t involve random clicking and prayer.

Now go forth and make your internal services discoverable. May your A records be correct, your CNAMEs be intentional, and your caches behave themselves.