A cloud application can have a valid hostname and still be unreachable. It can also accept a network connection while returning an application error. Treating all three situations as “DNS is broken” makes troubleshooting slower and encourages changes that may not address the problem.
This guide uses a fictional Windows lab to separate name resolution, TCP port reachability and application behaviour. It makes no connection to a customer environment and requires no new cloud resources. Start with the paper examples. Run commands only against a lab you own or are authorised to test, using its actual hostname and expected service port.
Write down the request you are investigating
Record the source machine, network connection, intended hostname, service port and observation time. Include whether the source is connected to the lab's VPN or private network. An answer observed from your laptop's home connection may differ from the answer available to a machine inside a cloud network.
Define the symptom precisely: the name does not resolve, a connection cannot be established, or the application returns an error after connection. Preserve the original error text in a private troubleshooting note, removing secrets and unnecessary personal data. Do not start by changing DNS records or opening firewall rules.
Ask what the name lookup actually returned
Microsoft's nslookup reference describes querying DNS information and distinguishes outcomes such as a nonexistent domain, missing records of the requested type and a server failure. Those observations call for different questions; none should be replaced by a generic “internet down” label.
$labHost = "app.example.test"
nslookup $labHostThe hostname above is a documentation placeholder. It will not become a working lab application simply by running the command. Substitute the authorised hostname your lab actually configures. Record which DNS server answered and which address or error it returned. Keep those facts beside the source network information.
If an address is returned, compare it with the address expected by the lab owner or its current configuration. A successful lookup means that a DNS answer was obtained. It does not establish that the answer is the intended one or that a service is listening at that destination.
Check the intended TCP port separately
Microsoft's Test-NetConnection documentation includes TCP connection diagnostics and a detailed result with fields such as the remote address, port and TCP test outcome. In an authorised HTTPS lab, the following example checks the chosen hostname and port.
Test-NetConnection `
-ComputerName $labHost `
-Port 443 `
-InformationLevel DetailedUse the service port agreed for your lab; the example uses the usual HTTPS port. Record the remote address actually selected by the test, especially if the hostname has more than one answer. Keep the source machine and network unchanged between observations so the comparison answers a clear question.
A successful TCP connection is evidence about reaching that port from that source at that time. It does not establish that TLS validation, application authentication or the requested operation succeeded. A failed TCP check does not identify one cause by itself: routing, filtering, the destination service or another part of the path may need investigation.
Classify the paper cases before proposing a change
Use this original practice table to write the next question for each observation. These are invented cases, not captured command results. The aim is to keep an observation separate from a diagnosis.
| Observation | What remains to check |
|---|---|
| Name lookup returns no usable address. | Spelling, expected record type, resolver and lab network context. |
| Expected address returned; TCP check fails. | Path, applicable rules and whether the service is listening. |
| TCP succeeds; the browser reports a certificate error. | The TLS error and intended hostname, without bypassing validation. |
| Connection succeeds; the application rejects access. | The application's response and authorised identity, separately from DNS. |
For the first case, do not assume that a public resolver should know a private lab hostname. Check the intended resolution path. For the second, avoid adding broad allow rules merely to see whether the error disappears. Identify the source, destination and required service, then use the lab's approved change process if a correction is justified.
Keep later layers in the investigation
After a TCP success, inspect the application through its intended client and hostname. A direct IP connection may change certificate or virtual-host behaviour, so it is not an equivalent proof that the normal user path works. Preserve the original hostname in your evidence and explain any deliberate variation in a diagnostic test.
Do not disable certificate checks to turn a failed test green. If the browser reports a certificate problem, record that as the current finding and investigate the relevant hostname, validity or trust issue with the lab owner. A temporary bypass would conceal information the exercise is intended to teach you to recognise.
Make a handover someone can continue
Write a short note with the expected behaviour, source context, DNS answer, selected remote address, port result and application observation. Add the exact next question, its owner and any change already attempted. Keep test observations in time order so a later reader can tell whether they came before or after a configuration change.
For example: “The lab hostname resolves to the expected address from the VPN-connected test machine. The TCP check failed on the intended service port. No rule change made; next check is whether the destination service is listening.” This is illustrative wording. It is useful because it states both what was observed and what remains unknown.
For deeper packet-path practice, use the Azure network trace exercise. Keep the two worksheets distinct: one follows routes and rules, while this one establishes which layer of a hostname-based request needs attention.
Common questions
Does a DNS answer prove the website works?
No. Continue through the intended connection, TLS and application checks. Record each result separately.
Should I change a firewall rule after one failed test?
First identify the expected path and the available evidence. A failure alone does not establish which rule, if any, needs changing.
Can I practise without a cloud subscription?
Yes. Classify the fictional cases and write handovers. Actual command results require an authorised, configured environment and must not be invented.
Explore networking foundations and Azure training, or ask for counselling about a suitable starting point.