How long does it take for a DNS change to take effect?

That depends on the record's TTL and on when resolvers last fetched it. At your own nameservers, the change is correct straight away. Elsewhere, it is often visible within a few minutes to a couple of hours, but allow up to 24 to 48 hours before every resolver is up to date. Lower the TTL beforehand to speed this up.

What does the NXDOMAIN error mean?

NXDOMAIN means the name you queried does not exist. Usually that is down to a typo, an expired or unregistered domain, a missing record, or nameservers that are set incorrectly at the registrar. Check the registration and the NS records of your domain first.

What does SERVFAIL mean and how do I fix it?

SERVFAIL means the resolver could not put together a valid answer. The two most common causes are a DNSSEC error (expired signatures or a DS record that does not match) and unreachable or incorrectly delegated nameservers. Test DNSSEC with dig +cd; if it works with that flag, the problem is DNSSEC.

Why do I still see the old IP address after a server switch?

Almost always, this is caching. The new A record is already correct at your nameservers, but resolvers and your own device hold on to the old address until the TTL expires. Compare the authoritative answer (dig @ns1.ljpc.network) with that of a public resolver (dig @8.8.8.8) and clear your local DNS cache if needed.

How do I check whether my DNS change has gone through worldwide?

Use whatsmydns.net to view a record from dozens of locations at once, or query it manually at different public resolvers with dig @8.8.8.8 and dig @1.1.1.1. If the new value comes back everywhere, the change has gone through.

Which nameservers does LJPc hosting use?

The nameservers of LJPc hosting are ns1.ljpc.network, ns2.ljpc.network, and ns3.ljpc.network. You manage your records in Plesk, after which changes become active on these nameservers directly. If you want to check the authoritative value, query one of these nameservers directly.

Troubleshoot DNS problems with dig and nslookup

Learn how to troubleshoot DNS problems: a domain that will not resolve, a wrong IP after a server switch, MX and slow propagation, with dig and nslookup.

DNS is the phone book of the internet: it translates a domain name such as yourdomain.com into the IP address of the server behind it. When something goes wrong there, your website or email is suddenly unreachable even though nothing seems to have changed. In this article, you will learn how to troubleshoot DNS problems: from a domain that will not resolve and a wrong IP address after a server switch to slow propagation and the NXDOMAIN and SERVFAIL errors. You diagnose each problem yourself with the free tools dig and nslookup, so you know exactly where it goes wrong and how to fix it.

How DNS works, and why things go wrong

Your domain has a set of DNS records that live on your nameservers. Those nameservers are authoritative: they have the final say over your zone. Each record has its own job. The A record links your domain to an IPv4 address, the NS records point to the nameservers in charge of your zone, the MX record decides which mail server receives your email, and a CNAME record lets one name point to another name.

The rest of the internet does not talk to your nameservers directly. In between sit resolvers: the DNS servers of your provider or company, and public resolvers such as those from Google (8.8.8.8) and Cloudflare (1.1.1.1). A resolver looks a record up once and keeps the answer in its cache for the length of the TTL. TTL stands for time to live: the number of seconds an answer may be kept before it is fetched again.

Almost every DNS problem comes from this. There are two kinds of answer. The authoritative answer comes straight from your own nameservers and is always current. The cached answer comes from a resolver that may still be holding the old value until the TTL expires. When you troubleshoot DNS problems, nearly everything comes down to the difference between the two: whether the value is already correct at the source, and whether the rest of the internet is simply still catching up.

dig and nslookup: your two most important tools

To diagnose DNS problems, you query records directly. For that, you use dig (on macOS and Linux) or nslookup (built into Windows). Replace yourdomain.com in the examples below with your own domain.

Using dig (macOS and Linux)

dig gives you detailed control. The most useful variants:

dig yourdomain.com A +short          # quickly look up the IPv4 address
dig yourdomain.com                    # full output with status and sections
dig @8.8.8.8 yourdomain.com +short    # what a public resolver returns now (possibly cached)
dig @ns1.ljpc.network yourdomain.com +short   # the authoritative answer, straight from the nameserver
dig MX yourdomain.com +short          # the mail servers
dig NS yourdomain.com +short          # your domain's nameservers
dig +trace yourdomain.com             # follow the delegation from the root downwards

In the full output, look at two things. The status: line tells you whether the query succeeded (NOERROR) or failed (NXDOMAIN or SERVFAIL). The ANSWER SECTION contains the records that were found. If you see the records at @ns1.ljpc.network but not yet at @8.8.8.8, your zone is already correct and it is simply a matter of waiting for the cache to expire.

Using nslookup (Windows)

On Windows, nslookup works in a similar way. Open the command prompt and use:

nslookup yourdomain.com                   # the IP address via your default resolver
nslookup -type=MX yourdomain.com          # the mail servers
nslookup -type=NS yourdomain.com          # the nameservers
nslookup yourdomain.com 8.8.8.8           # ask a specific resolver explicitly
nslookup yourdomain.com ns1.ljpc.network  # ask for the authoritative answer

The line "Non-authoritative answer" is normal: it only means the answer came from a resolver's cache rather than straight from your nameserver. If you want the authoritative answer, ask your nameserver directly, as in the last line above.

Authoritative versus cached

If you would rather not work from the command line, whatsmydns.net is a handy online tool. It queries your record from dozens of locations around the world and shows at a glance where the new value has already arrived and where it has not: exactly what you want to know about a change that is still propagating.

How to troubleshoot DNS problems

Your domain does not resolve at all (NXDOMAIN)

If you get NXDOMAIN back, DNS is telling you the name does not exist. Work through these points:

Is the domain name still registered and not expired? An expired domain can drop out of DNS.
Do the nameservers at your registrar point to the right servers? Use dig NS yourdomain.com +short to check that the expected nameservers are listed.
Does the name you are querying actually exist? If you look up www.yourdomain.com when no record has ever been created for it, that name does not exist and NXDOMAIN is correct.
Test with dig +trace yourdomain.com to see where the chain breaks. If the trace runs neatly from the root to your nameservers, the delegation is fine.

Wrong IP address after a server switch

You have pointed the A record at a new server, but you, or your visitors, still land on the old one. In almost every case, this is caching. The old address can still be held in several places: in your resolver's cache, in your operating system's DNS cache, and sometimes in your browser.

First, find out where it goes wrong. Compare the authoritative answer with that of a public resolver:

dig @ns1.ljpc.network yourdomain.com +short   # this should be the new IP
dig @8.8.8.8 yourdomain.com +short            # this may still be the old IP

If your nameserver returns the new address and a public resolver still returns the old one, your zone is fine and it is a matter of waiting for the TTL to expire. If you see the old address locally while public resolvers are already up to date, clear your own DNS cache (see below). If you are planning a move in advance, lower the record's TTL a day beforehand, for example to 300 seconds, so the switch comes through quickly afterwards.

Email still arrives at the old server (MX points to the wrong place)

After migrating your email, messages can keep arriving at the old mail server for a while. The cause is the same, but the record is different. Other mail servers sending you messages rely on the MX record and hold on to it until their cache expires. Check the current value with dig MX yourdomain.com +short and compare the authoritative answer with that of a public resolver, just as with the A record. As long as the old value sits in a cache somewhere, some of your email will keep going to the old server. So here too, lower the TTL well before the move and keep the old mailbox reachable until every cache has refreshed.

Your change is not visible yet (propagation is slow)

Propagation is really a misleading word. Nothing is actively broadcast or pushed. Your nameserver has the new value straight away, but resolvers elsewhere return the old answer until their retention period, the TTL, has expired. After that they fetch the new value by themselves.

How long that takes, therefore, depends on the TTL and on how long ago a resolver last fetched the record. In practice, a change is often visible everywhere within a few minutes to a couple of hours, but allow up to 24 to 48 hours before every resolver is truly up to date. Follow progress worldwide with whatsmydns.net, or query the record at different public resolvers with dig @8.8.8.8 yourdomain.com +short and dig @1.1.1.1 yourdomain.com +short.

SERVFAIL: the resolver cannot work it out

SERVFAIL means the resolver could not put together a valid answer. Unlike NXDOMAIN, it is not about a name that does not exist, but about something going wrong along the way. The two best-known causes:

A DNSSEC problem. If a zone is signed but the signatures have expired or the DS record at the registry no longer matches, a validating resolver refuses the answer with SERVFAIL. Test this with dig +cd yourdomain.com. The +cd flag (checking disabled) turns off DNSSEC validation. If the query suddenly works with it, that points strongly to DNSSEC.
Unreachable or incorrectly delegated nameservers. If your nameservers do not respond, or the delegation at your registrar points to servers that do not know your zone, that also produces SERVFAIL. Query the nameserver directly with dig @ns1.ljpc.network yourdomain.com to see whether the source itself answers.

Quick diagnosis by symptom

Common DNS problems, the likely cause, and the first check.
Symptom	Likely cause	First check
Domain does nothing at all, NXDOMAIN	Domain expired, wrong delegation or missing record	`dig NS yourdomain.com +short`
Website on the old server after a switch	Old A record still cached (TTL)	`dig @8.8.8.8 yourdomain.com +short`
Email arrives at the old server	Old MX record still cached (TTL)	`dig MX yourdomain.com +short`
Change not visible everywhere yet	Normal propagation, TTL not expired	whatsmydns.net
SERVFAIL	DNSSEC error or unreachable nameservers	`dig +cd yourdomain.com`

Clearing the DNS cache on your own device

If you still see an old value locally while the rest of the internet is up to date, the answer is stuck in your own computer's cache. Here is how to clear it:

Windows: open the command prompt and run ipconfig /flushdns.
macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
Linux with systemd-resolved: sudo resolvectl flush-caches.

This clears only the cache on your own device, not that of your provider or of public resolvers. If your browser keeps holding on to the old address, close it completely and open it again.

Managing DNS at LJPc hosting

At LJPc hosting, you manage your DNS records in Plesk, the control panel of your hosting package. When you save a change there, it is applied directly to our nameservers ns1.ljpc.network, ns2.ljpc.network, and ns3.ljpc.network. From that moment, our nameservers return the new value straight away.

If you still see the old value elsewhere for a while, that is purely down to caching at the resolvers in between, exactly as described above. If you want to be sure it is correct on our side, query it directly with dig @ns1.ljpc.network yourdomain.com. Our default TTL is one hour. If you are planning a migration, lower the TTL of the records involved a day in advance so the switch becomes visible quickly. If you get stuck, our support team is happy to look into it with you.

If these steps do not get you there, contact support. Mention which domain and record are affected, and include what dig or nslookup returns, so the issue can be traced quickly.