The lookup starts with an application
When you enter a website name, the application needs an address it can use to connect. It may ask the operating system to resolve the name through a function such as getaddrinfo. The device-side component that handles a DNS request is commonly called a stub resolver. Unlike a recursive resolver, a stub resolver generally does not walk through DNS servers to find an answer. It prepares a question and asks a configured server to resolve it.
The path is not identical on every device. A browser may keep its own cache or use its own DNS settings, while other applications rely on the operating system. The operating system may also have a DNS service between the application and the network. These variations matter when two apps on the same device appear to get different results for the same name.
Local answers may stop the query before it leaves
Before sending a DNS packet, the device may find an answer locally. Depending on its configuration, it can check a local cache, a hosts file or another configured naming source. A cache holds answers from earlier lookups for a limited time; it may also temporarily hold a response saying that a name was not found. A hosts-file entry can map a name to an address without consulting DNS.
These checks explain why changing a DNS record does not always produce an immediate change on one device. They also explain why a single computer might reach a different destination than its neighbors. If you are troubleshooting, check the exact name the app requested and whether a local entry or cached answer could be involved before assuming the authoritative DNS records are wrong.
The stub turns a name into a question
If a network lookup is needed, the resolver must decide what to ask. For a website, an application often needs an IPv4 address, an IPv6 address or both. That can result in A and AAAA DNS questions. Asking for an address is not the same as connecting to it: the application still has to choose an address and attempt a connection after it receives a usable answer.
The name itself can require interpretation. A fully qualified name specifies the intended DNS name, but a short name such as printer may be tried with one or more search suffixes supplied by network settings. For example, a device configured with the suffix office.example might try printer.office.example. The order and conditions for those attempts vary by system. When inspecting a failed lookup, a fully qualified name helps remove uncertainty about whether a search suffix was added.
Resolver settings determine where the question goes
The device needs the address of a DNS server to ask. It may receive resolver settings from a network connection, a router, a VPN or a manual configuration. Some devices send the question to a router that forwards it onward; others send it directly to a recursive resolver. A VPN can direct certain names to a separate resolver, so the destination may depend on both the name and the active network.
A conventional DNS question may travel over UDP, with TCP used in some circumstances. Configured encrypted DNS can change how the device reaches its resolver, without changing the basic need to ask for an answer. Because applications and operating systems can have separate DNS settings, changing a device-wide setting may not affect every application. The useful troubleshooting question is not only “Which DNS server is configured?” but “Which resolver path did this application use for this name?”
The reply is an answer, not a connection
The configured server might already have a cached answer, or it might perform recursive work before replying. The stub receives the response and passes the relevant result back toward the application. It may retain an answer in a local cache for an allowed period. If there is no usable address, the application can report a name-resolution error; if an address is returned, a connection can still fail for unrelated reasons.
To narrow down a problem, separate these stages. First confirm the exact name and whether a local override exists. Then check which resolver the device or application uses and whether a VPN or search suffix changes the request. Finally, distinguish “DNS did not return an address” from “an address was returned, but the service could not be reached.” That distinction keeps troubleshooting focused on the step that actually failed.
