Two of the five questions from Part 1 cause more incidents than all the others put together: which address does this name resolve to, and which route carries the packet there and back. They are also the two that are easiest to get wrong without noticing, because both can be correct from one place and wrong from another.
DNS answers can legitimately differ depending on who asks. Routes can legitimately differ depending on where a packet starts. So a service can work perfectly from a cloud VM and fail from the office, and both observations are true at once. Most "it works for me" tickets live exactly here.
This part follows a name to an address, the address to a path, and the path through the gateways that join one network to another, using Hadeda Freight's estate. Hadeda Freight is fictional, and its address ranges and figures are illustrative.
DNS is the contact list
People remember names more easily than numbers. DNS, the Domain Name System, converts a name such as track.hadeda.example into an address a client can use. The simplified process:
- The client asks a recursive resolver, usually provided by its network, its ISP or the cloud platform.
- The resolver checks its cache.
- If it has no fresh answer, it follows the DNS hierarchy down to the authoritative name server for that domain.
- The authoritative server returns the record.
- The resolver caches the answer for the record's time to live (TTL), then hands it to the client.
That cache is both a blessing and a trap. It makes DNS fast and resilient. It also means that when you change a record, clients keep the old answer until their TTL expires. Teams planning a cut-over lower the TTL a day or two in advance for exactly this reason, and teams that forget wonder why half their users still hit the old server an hour later.
| Record | Purpose |
|---|---|
A | Name to IPv4 address |
AAAA | Name to IPv6 address |
CNAME | Name to another name (an alias) |
MX | Where mail for a domain is delivered |
TXT | Text data, such as domain verification and mail-security policy |
NS | Which servers are authoritative for a zone |
PTR | Reverse lookup, from address to name |
A detail that matters in the cloud: managed services usually give you a name, not a fixed address. A database or storage endpoint may change its address during maintenance or failover. Applications should connect by name and respect the TTL, rather than having an address pasted into configuration.
Routing is the road-sign system
Once a client has an address, the packet needs a path. A route table lists destination prefixes and the next hop for each. When a packet could match several routes, the router picks the most specific one, the route with the longest prefix. This is called longest-prefix match, and it is the single most useful rule in routing.
Here is a simplified route table from Hadeda's production network after the Midrand office connected over both a VPN and, later, a private circuit for its busiest subnet:
| Destination | Next hop |
|---|---|
10.40.0.0/16 | Local virtual network |
10.10.0.0/16 | VPN gateway |
10.10.8.0/24 | Private circuit |
0.0.0.0/0 | Firewall |
A packet for 10.40.20.5 stays local. A packet for 10.10.4.7 goes to the VPN. A packet for 10.10.8.20 matches both the /16 VPN route and the /24 circuit route, and the /24 wins because it is more specific. Anything else follows the default route, 0.0.0.0/0, to the firewall.
Two consequences are worth holding on to. First, adding a more specific route anywhere in an estate can silently redirect traffic that used to follow a broader one; that is powerful when intended and alarming when not. Second, routing is per direction. The route table on the other side decides how the reply comes back. If Midrand sends a request over the circuit and the cloud returns it via the VPN, a stateful firewall that only saw one half of the conversation will drop it. Part 9 calls this asymmetric routing, and it is one of the most confusing faults to diagnose.
Gateways connect routing domains
A gateway is any component that joins one routing domain to another. The common ones:
- An internet gateway connects a cloud network to internet routing.
- A NAT gateway lets private workloads start outbound connections using a shared public address (Part 6).
- A VPN gateway terminates encrypted tunnels from offices or other networks (Part 8).
- A private circuit gateway connects a dedicated carrier link into the cloud (Part 8).
- A transit gateway or virtual WAN hub connects many networks through one routing service (Parts 8 and 9).
The name "gateway" hides the fact that each of these has its own routes, limits, costs and failure behaviour. When a diagram has a box labelled "gateway", ask which kind, and what its route table says.
Split-horizon DNS: same name, two answers
Now combine the two halves. Hadeda's Track application stores delivery photos in a managed storage service. Rather than reaching it over its public endpoint, Hadeda created a private endpoint (Part 6): a private address, 10.40.40.8, inside its own network, that leads to the storage service.
Applications still use one name, storage.hadeda.example. The trick that makes this work is split-horizon DNS: the same name gives different answers depending on who asks. A private DNS zone, attached to Hadeda's cloud networks, returns 10.40.40.8. Public DNS returns a public endpoint, or nothing at all if public access is disabled.
Inside the cloud network, this just works, because cloud workloads use the cloud provider's resolver, which knows about the private zone. The office is different. Laptops in Midrand use the office's DNS resolver, which has never heard of Hadeda's private zone in the cloud. Unless someone configures a conditional forwarder ("send any query for this zone to the cloud resolver endpoint"), office users get the public answer, or none.
That is the root of the most common private-endpoint complaint of all: "it works from one network but not another". The network path was fine. The DNS design was missing. Hybrid DNS needs three things written down: which resolver is authoritative for which zone, which forwarders send which queries where, and who owns each piece. Creating a private endpoint without that design is one of the most reliable ways to generate a week of tickets.
Troubleshooting in order
When a name does not lead where it should, work through these steps in sequence, from the client that is failing, not from a convenient machine that works:
- Resolve the name and record the returned address.
- Confirm that address is the expected one for this client's location.
- Inspect the client's own route to that address.
- Inspect the network and appliance route tables along the path.
- Confirm the return route from the destination back to the client.
- Check the stateful and stateless security controls on the way.
- Test the actual application protocol, not just ping.
Hadeda's operations team keeps this list in their runbook. The point of the order is that each step rules out a whole class of cause before you spend time on the next one.
Common mistakes
- Testing DNS from the wrong place. A cloud VM and an office laptop use different resolvers, so one can be right while the other is wrong.
- Pasting an IP address into configuration. Managed services change addresses; connect by name.
- Changing a record without lowering the TTL first. Clients keep the old answer for hours.
- Adding a more specific route without checking what it captures. Longest-prefix match will obey it immediately.
- Creating a private endpoint without a DNS design. The endpoint is ready; nobody can resolve it.
Try it yourself
Draw the DNS and traffic path for an employee in Midrand reaching Track's managed database through a private endpoint. Mark which component holds the authoritative private record, which resolver the laptop asks, where the conditional forwarder sits, and which route carries the packet from 10.10.0.0/16 into 10.40.40.0/24 and back again.
Test your understanding
A packet for 10.10.8.20 matches both 10.10.0.0/16 and 10.10.8.0/24. Which route is used, and why?
Answer: The /24, because routers choose the longest, most specific matching prefix.
A storage service works from cloud VMs but not from the office after a private endpoint was enabled. Where would you look first?
Answer: DNS from the office. The office resolver probably has no forwarder for the private zone, so it returns the public answer or nothing.
Why should you lower a record's TTL before a planned cut-over?
Answer: So resolvers stop caching the old answer for long. When you change the record, clients pick up the new address within minutes instead of hours.
Why can a working forward route still produce a timeout?
Answer: Because the reply follows the route table on the other side. If the return route is missing or goes a different way, the response never arrives or is dropped by a stateful device.
What to take from this part
DNS answers depend on who is asking. Always resolve from the client that is failing.
The most specific route wins. Know what every new route captures before you add it.
Every route has a return journey. The far side's route table decides it.
Private endpoints are a DNS project as much as a network one. Design the resolvers and forwarders first.
Next in the series: VPCs, VNets and subnets: drawing useful boundaries in a cloud network.
How CloudNala can help
Hybrid DNS is where many cloud estates quietly go wrong. We map which resolvers and zones exist across offices and clouds, design the forwarding and ownership model, and review route tables for the specific routes and return paths that cause intermittent faults, before private endpoints and hybrid links go into production.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Network Review or write to us at consult@cloudnala.co.za