Separate IP connectivity from name resolution

A host reaches a service by IP transport, but applications commonly begin with a name. The resolver may ask a recursive DNS server for an A record, AAAA record or another type. The recursive server may answer from cache or query authoritative servers. A failed name lookup can occur before the client attempts the application connection. Conversely, a successful name lookup only provides addressing or other DNS information; it does not prove that the server listens on the expected port or that any firewall permits the connection.

An efficient first test separates the question into three parts: can the client reach its configured resolver, can the resolver return the intended records, and can the client connect to the returned address? Record the exact name, record type, resolver and observed answer. If an application chooses IPv6 from an AAAA record and the IPv6 route is broken, an IPv4-only ping may create false reassurance. Test both address families if both are published and note which address the actual application selected.

A troubleshooting note should also distinguish a negative response from a transport timeout. An authoritative NXDOMAIN response indicates that the queried name does not exist in the responder’s view; a timeout can mean packet loss, unreachable DNS servers, filtering or server distress. A response of no data for a particular type does not necessarily mean the name itself is absent. Error wording in client applications often blurs these cases, so use DNS-aware tools instead of relying on browser messages.

Know what A, AAAA and CNAME answers mean

An A record maps a domain name to an IPv4 address. An AAAA record provides an IPv6 address. One name may return multiple addresses for distribution or redundancy, and those records can legitimately change as services move. If a hostname resolves to an old address after a migration, verify which server answered and whether the record or cached response is stale. Flushing every network device’s cache blindly is usually less useful than checking the responsible authoritative record and its time-to-live.

A CNAME record makes one name an alias of another canonical name. A resolver follows the alias chain to obtain the requested address information, subject to normal DNS constraints. If a CNAME points to a decommissioned target, the alias can appear syntactically correct while leaving the client without a usable A or AAAA answer. Watch for excessively long chains and record-management rules, including the fact that ordinary CNAME rules restrict coexistence with unrelated record types at the same owner name.

In a lab, create app.example.invalid as a documented fictitious naming example with an A record and optionally an AAAA record, then give portal.example.invalid an alias to it in a local DNS test zone. Observe each query type, the TTL and returned record chain. The .invalid top-level name is reserved and should not be treated as a functioning public DNS zone. For live tests use an authorized domain and resolver. The exercise matters because it makes the difference between a nonexistent alias, a target without an address and a service that is down at a valid address concrete.

Diagnose mail and delegation records without confusing their roles

MX records identify mail-exchanger hosts and include preference values that help senders choose mail destinations. The MX record points to an appropriate mail host name, not directly to an IPv4 address; that host also needs usable address records. If mail delivery fails, changing a web application’s A record will not correct an incorrect MX target. Mail systems add many other controls, but the CCNA-level diagnostic distinction begins with querying MX, resolving the exchange hostname and testing network reachability on the relevant protocols.

NS records identify authoritative name servers for a DNS zone or delegation. A client’s configured recursive resolver is not the same thing as an NS record for a public zone, and confusing those concepts can lead to wrong changes. A delegation problem may cause recursive resolvers to query incorrect or unavailable authoritative servers even though internal network routing is fine. Use a trace or explicit authoritative server queries where appropriate to locate the hop at which the delegation diverges from expected data.

Nameservers can appear healthy in one geography while a different recursive resolver retains older cached delegation or address data. Document the resolver and timestamp when comparing reports. After a DNS migration, authoritative changes and TTL behavior can produce a temporary mixed picture; ‘propagation’ should not be used as a vague explanation without showing the actual responses. DNS troubleshooting improves when expected zone ownership and observable answers are both written down.

Understand PTR records and the limits of reverse lookup

A PTR record supports a reverse mapping from an address-oriented DNS name to a hostname. Reverse lookups use in-addr.arpa for IPv4 and ip6.arpa for IPv6, with names derived from address bits in their respective DNS forms. A PTR result can be useful for logging, mail-service checks or investigating a device name, but it is not an authentication guarantee. A client should not conclude that an endpoint is trustworthy because its reverse lookup returns a familiar string.

An environment may have a correct forward A record but no reverse PTR. Some applications work normally in that condition, while operational logs or mail checks may be less informative. Before adding a PTR, check who controls the relevant reverse zone; cloud or provider addresses may not be under the enterprise’s normal public DNS administration. A PTR that resolves but points to a hostname whose forward record has changed may also be operationally confusing. Evaluate both directions where the application needs them.

When building a troubleshooting table, include name, expected type, expected target, authoritative owner, observed recursive answer, TTL and observed application behavior. These fields distinguish a wrong answer from a correct answer that leads to a blocked service. The table also prevents a common drift in incident meetings: a record is described simply as ‘DNS’ without anyone saying what type of DNS data is actually involved.

Caching can also hide a deliberate fix. Suppose an authoritative A record has been corrected but a client still reaches the retired address until the cached record’s TTL expires. Check whether the queried resolver is returning a cached answer and whether local operating-system or application caches add another layer. Repeatedly changing the authoritative record back and forth can prolong confusion. Document the old and new answer, TTL, time of change and affected resolver rather than relying on a generic claim that DNS must be allowed to ‘propagate.’

Use resolvers and packet tests together

On a workstation, tools such as nslookup, dig or system-specific resolver commands can query specific record types and servers. Do not assume every workstation ships with every command. Where allowed, compare a query to the default corporate resolver with a query directly to the authoritative server. The difference may reveal stale caching, split-horizon policy or a forwarding problem. Record the command’s server and query type because a result without those fields is difficult to interpret later.

A firewall may allow ordinary DNS over UDP but filter larger responses, TCP fallback or encrypted resolver protocols depending on architecture. A query that works for a short A answer may fail for a larger response or different transport. Likewise, a VPN-connected user may use corporate split DNS while an off-network user sees public records. Testing both contexts can reveal that both DNS systems are acting according to their configurations, even when the application team expects one unified result.

For a hands-on lab, introduce six faults: missing A, missing AAAA, broken CNAME target, stale MX host, incorrect NS delegation and missing PTR. For each, query the expected record and then test the network path to any resulting address. Describe which symptoms the record can explain and which it cannot. An MX error, for instance, should not become a default-router edit, and a correct A answer should not become an automatic declaration that the web application is functional.

Position DNS in the CCNA exam versions accurately

CCNA v1.1 asks candidates to explain the roles of DHCP and DNS in the network. The announced v2.0 blueprint strengthens the operational requirement by explicitly naming six DNS record types and diagnosing issues that affect host, web-application and mail-server access by name. A candidate sitting v1.1 does not need to pretend that this v2.0 wording is already the current test blueprint, but learning record-level diagnosis is useful beyond any exam transition.

The CCNA certification context and 200-301 exam destination place the subject within networking preparation. Read Cisco’s v1.1 objectives and the announced v2.0 objectives for exact requirements. A successful DNS incident report ends with a verified chain from the client resolver through the returned record to the attempted service connection; it does not rely on the ambiguous phrase ‘DNS is down.’