dig and nslookup: how to diagnose a domain that does not resolve
Published on 2026-10-26 by frfrand
Query DNS servers, records, and cache from terminal
api.ejemplo.com opens on the phone but not on your computer. Before randomly deleting DNS configurations, ask the resolvers directly what response they are delivering. dig and nslookup are useful for this.
Let's turn it into a procedure you can use on a real VPS. The goal is to understand why it works, how to test it, and what problem appears if one part is misconfigured.
What dig vs nslookup means and when you need them
Both tools perform DNS queries. dig usually makes it easier to analyze TTL, responses, and servers; nslookup is available on many Windows installations. Choosing one depends on the system and the information you need to see.
Before changing anything in production, note the current status: IP, domain, port, affected service, and time of the last deploy. An isolated change is easy to verify; five simultaneous changes make it harder to reconstruct what happened.
Configuration or example commands
dig api.ejemplo.com A +noall +answer
dig @1.1.1.1 api.ejemplo.com A
nslookup api.ejemplo.com
nslookup api.ejemplo.com 8.8.8.8
# NS del dominio
dig ejemplo.com NS +shortDomains, IP addresses, paths, and names are illustrative. Do not copy an entire configuration over the current one without comparing first. In examples that include ports or firewall, make sure to keep administrative access.
How I would do it step by step
- Preparation. Check your system's normal resolution and note down the address received.
- Step 2. Ask a different public resolver to detect discrepancies.
- Step 3. Review TTL and authoritative servers for the domain.
- Step 4. If the IP is correct, proceed to test TCP 443 and HTTPS; DNS is not the entire connection.
- Verification. If you changed the domain, verify that there is no old AAAA record or a CNAME to another destination.
When finished, check the actual operation from another connection. For example, for an API it is not enough to open the browser: run a read request, a write to a test database, and check the process logs.
Example of a real project
You migrated a WordPress site to a new VPS and a browser still sees the previous version. dig shows an old IP on a resolver, but the authoritative server already responds with the new one. This suggests cache, not that Nginx is misconfigured.
The lesson is simple: an infrastructure configuration does not live isolated from the application. The frontend, the server, the database, and the workers connect, so measuring where the failure starts is more useful than restarting everything.
The mistake I would avoid
nslookup does not reproduce all browser resolution: there may be local cache, DNS-over-HTTPS, and proxy. If DNS responses match but the website fails, check HTTP instead of continuing to modify records.
When working with client servers, keep a backup or rollback procedure before changes that affect data, network, or certificates. And if you don't know what permissions an operation needs, avoid running it as root just to make errors stop showing.
How does it relate to ArduMaker?
Before reconfiguring domains in ArduMaker, contrast the DNS response from more than one source and confirm the exact domain. Separating symptoms avoids unnecessary outages.
In a typical case you can create a VPS for the application, deploy from Git, associate an HTTPS domain, and manage the backend and necessary databases. Tools help centralize operations, but you need to understand which port and process fulfills each function.
Questions that arise when you try it
How do I know if the failure is DNS or the service? Check resolution first, then connection to the port, and finally the application response. That order avoids confusing different problems.
Can I expose a database to make it easier to maintain? Better design private access or authenticated tunnels when possible. Exposing a port does not replace engine permissions or the firewall.
What should I document? The expected configuration, how it is verified, and how to return to the previous state. That document helps you more than a list of commands without context.
References
In summary: a good network or server configuration is one that you can explain, verify, and recover when something fails.