Name resolution and traffic delivery are separate
A virtual machine may reach an IP address while the expected hostname fails, or resolve a hostname correctly while packets are blocked. In Microsoft AZ-104 network troubleshooting, DNS diagnosis must remain separate from routing, NSGs and application health. Azure DNS can host supported public and private zones, while Azure Network Watcher and Connection Monitor provide troubleshooting evidence about network paths and observed connectivity.
Consider an internal web API reached through a private hostname from VMs in two peered networks. One VM resolves the right address while the other still uses a public answer. Before editing NSGs, compare resolver paths, zone links, records, private endpoint DNS integration and whether the calling environment uses custom DNS forwarders. A DNS answer controls a destination address; it does not authorize that destination.
The AZ-104 blueprint calls out Azure DNS, public/internal load balancers, Network Watcher and Connection Monitor. These objectives overlap in incidents, but each serves a different diagnostic question. Build the incident narrative around the exact failing step.
Design a public DNS zone responsibly
A public DNS zone hosts internet-visible records such as A, AAAA, CNAME or TXT under an approved domain delegation. Create or update records only for domains the organization controls. Correctly pointing a CNAME at an endpoint does not configure HTTPS certificate binding or prove the application responds. DNS propagation and local resolver caching mean multiple clients can temporarily see different answers.
Run a controlled DNS test with a subdomain, document required record type and TTL, inspect authoritative and recursive responses and verify the application endpoint separately. If a certificate challenge uses TXT records, record which process validates ownership before deleting a verification record. Avoid using a production apex domain as a troubleshooting sandbox.
Configure private DNS links and hybrid resolution
Private DNS zones can supply names for clients in linked VNets under supported rules. A private endpoint may rely on specific service-owned zone naming and DNS records; simply creating a private IP resource does not guarantee every client resolves its service hostname privately. Linking another VNet and forwarding on-premises queries may require deliberate resolver configuration.
Private endpoint DNS controls whether clients resolve a service to the intended private address. Here, diagnose mismatched answers from two clients. Record their queried hostname, configured resolver, response address and network location; then check private-zone links, custom DNS and any required forwarder path rather than blindly changing account firewalls.
Use Network Watcher to isolate a network problem
Azure Network Watcher offers diagnostic tools for supported Azure networking resources. Depending on the environment, effective security rules, effective routes, IP flow verification, next-hop inspection, packet capture and other features can illuminate where a flow fails. Features and output vary, so verify regional and permission prerequisites from Azure Network Watcher documentation.
Start with exact source NIC, destination IP, port and protocol. An effective NSG rule can explain a denied flow; an effective route reveals where the system expects to send packets. Neither proves the guest application is listening. Inspect firewall rules and service readiness within the VM if the network controls show an allowed path but no response.
Use Connection Monitor for repeatable path observation
Connection Monitor measures supported connection availability and performance between configured endpoints using monitoring infrastructure. It is useful for tracking intermittent network failures that a one-time portal check misses. Choose the source agents or endpoints, destination and test protocol according to current product support. Record test cadence and alert expectations rather than claiming the tool is a complete packet-by-packet forensic recorder.
Build a small scheduled test for a private API port and capture its success state before introducing an intentional NSG denial. Compare the affected period with activity logs and configuration changes. A monitoring gap does not automatically mean the workload was down; inspection of missing collection, authorization or agent health may be required.
Distinguish load-balancer health and listener behavior
Azure Load Balancer operates at Layer 4 and uses appropriate health probes to select healthy backend endpoints. Application Gateway handles HTTP-aware functions at Layer 7. A backend may accept TCP yet return an application error; conversely, a probe may be misconfigured and mark a functioning service unhealthy. Design probes that reflect the intended load-balancing service.
Choosing Azure load balancing requires matching frontend protocol and routing behavior to the application’s needs. To troubleshoot, verify frontend IP and listener/port, health probe, backend pool membership, security rules and target application. Do not start by replacing the load balancer when the actual fault is a stopped process or an unintended rule.
Diagnose one failed hostname from the client to the application
Start with a working baseline and introduce one fault at a time in a disposable network: an incorrect private DNS answer, an NSG denial, a route with no usable next hop, or a backend that fails its health probe.
Record the resolver used by each affected VM, the exact hostname and IP result, the source subnet, effective security rule, next hop, observed probe state and application response. If one peered VNet resolves a private endpoint and another resolves its public address, inspect zone links and the resolver or forwarding path; peering does not automatically copy private DNS associations.
Use an appropriate Network Watcher test to distinguish reachability from name resolution. Configure Connection Monitor with a supported source, target and protocol and establish a known-good availability measurement before applying a deliberate NSG deny. Missing monitor data may reflect agent or monitoring configuration rather than an outage, so do not report a silent chart as proof that packets were dropped.
Finally verify outbound capacity and route behavior. A client can resolve a public hostname correctly but remain isolated in a subnet that has no configured egress path. Check private-subnet behavior, UDRs and the selected outbound mechanism before changing DNS records or identity permissions. Correct the first failing layer and retest the original application request; a successful ping to an IP is not a substitute for a successful HTTPS transaction.