DNS for VPS: Why Your Domain No Dey Reach Server

Wetin be DNS, and why your domain never reach your VPS yet

DNS (domain name system) dey turn name like example.com into IP (internet protocol) address like 203.0.113.10. Browser no fit connect to name. E dey connect to address, so every page load dey start with DNS question and answer. If you just buy domain and your own VPS, and nothing dey load, one of two things dey happen: no record connect the name to your server address yet, or record dey connect am but something for the path still dey give out older answer.

Both situations normal, and none mean say anything spoil. The sections below go handle the parts for the order wey you go meet dem, starting with the one wey dey waste pass time: which control panel actually hold your records.

Every check here use dig, and fresh Ubuntu or Debian machine no get am installed by default.

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, nameserver, DNS host: which one you go edit

These three names describe different work. If you mix dem up, na why edit fit change nothing.

• The registrar na the company wey you buy the domain from. The important work na delegation: e tells the registry wey dey run your TLD (top-level domain, the .com part) which nameservers get authority for your domain.
• The authoritative nameservers hold the real records for your zone. Zone na your domain plus the names under am.
• The DNS host na whoever dey operate those nameservers. E fit be the registrar, another provider, or bind9 wey dey run for server wey you own.

You buy domain from the registrar. You edit records for the DNS host. If you move your domain go another provider nameservers, the registrar own DNS panel still go show you one zone, still save your edits, but nobody for internet go ever ask that zone any question. The records dey real. Na just say nobody dey consult dem.

Find out where people for internet dey ask:

dig example.com NS +short
dig +trace example.com

The first command print the nameservers wey dey answer for the domain today. The second one follow the chain from the root servers and print the referral wey the TLD servers give out. Na this delegation your registrar dey control. If those names belong to provider wey you no recognise, na that provider own the panel wey you need.

How one lookup dey travel

Four parties dey involved, and each one dey keep copy of wetin e learn.

1. The stub resolver for your machine. E no dey search. E dey ask one configured server and trust the reply. For Ubuntu, /etc/resolv.conf usually na symlink to /run/systemd/resolve/stub-resolv.conf and e dey name 127.0.0.53, wey be systemd-resolved running locally with e own cache.
2. The recursive resolver. Na resolver wey your ISP (internet service provider) dey run, or public one like 1.1.1.1, or one wey you run by yourself. Na e dey do the actual work of finding the answer.
3. The root and TLD servers. The recursive resolver dey ask root server, wey no know your address but e dey reply with referral to the .com servers. Those ones dey reply with referral to your nameservers.
4. The authoritative nameserver. E no dey ask anybody. E dey answer from your zone and mark the answer as authoritative.

dig +trace example.com dey show you this process, because e dey start from the root itself and print each referral instead of asking cache. Na the fastest way to check whether the delegation and the zone agree.

DNS records wey matter when you dey run server

• A: name go IPv4 address. example.com. A 203.0.113.10. Na this record dey point your domain go your VPS.
• AAAA: name go IPv6 address, like 2001:db8::10. Publish am only when your service really dey listen for that address. Clients wey dey IPv6 network go try the AAAA answer first, so address wey no service dey answer for fit add delay to every visit.
• CNAME: alias from one name go another name. www.example.com. CNAME example.com. dey send visitors of www go wherever the bare domain resolve to. CNAME no fit dey for apex (the bare example.com), because apex must carry im own SOA (start of authority) and NS records, and CNAME no fit share name with any other record. Providers get workarounds wey dem dey call ALIAS, ANAME or CNAME flattening.
• MX: where mail for the domain go deliver. E carry hostname and preference number, and the lower number go first. MX must point to name wey get address record. Pointing am to CNAME no valid, and some sending servers go reject am.
• TXT: free text wey dem dey use for proof and policy. Mail authentication records (SPF, DKIM, DMARC) dey here, and the ACME (automatic certificate management environment) token wey issue wildcard certificate dey here too.
• NS: which nameservers dey serve the zone. The copy wey decide where the whole internet go ask dey for the parent zone and come from your registrar's delegation, not the copy inside your own zone.

Two details dey cause more confusion than the record types themselves. Name wey end with dot na absolute, so www.example.com. mean exactly that and nothing more. Most panels dey expect relative name and go append the domain for you, so when you type www.example.com for the name box, e go give you www.example.com.example.com, wey no resolve for anybody. The other detail na @, wey for almost every panel mean the apex: the domain by itself, with no subdomain.

Point A record go your VPS

First get the address wey internet dey see for your server:

curl -4 https://ifconfig.me
ip -brief -4 address show

Then create one record for your DNS host: type A, name @, value na that address, TTL (time to live) 300. Add second record for www, either another A with the same address or CNAME wey point to the apex.

Now prove say e dey resolve, preferably from your laptop instead of the server itself:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

The first one use your machine normal path, including caches. The second one bypass your local cache and ask public recursive resolver. The third one ask your authoritative nameserver directly, so na the current truth be the answer, with no cache anywhere for the path. When the third command return your address but the first one no return am, your DNS don configure correctly and you dey wait for cached copy of the old answer.

Resolving dey work but page no load

A successful name resolving show say DNS dey work. E no prove anything about your web server. Once dig return the correct address, test the connection:

curl -I http://example.com

curl: (6) Could not resolve host: example.com na DNS problem. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused no be DNS problem: the name resolve, and the packet arrive, so the issue be say nothing dey listen for that port. If request hang and later time out, e usually mean firewall drop the packet silently instead of refusing am. Na for there DNS stop to be the issue, and ports and listening sockets plus the ufw firewall rules for your VPS take over. After the connection complete, the remaining page load na HTTP doing its work.

Why browser still dey show the old host

Nothing dey propagate. No server dey push your change go anybody. Your authoritative nameserver hold the new value immediately you save am, and every cached copy of the previous answer remain valid until its own timer expire. That timer na the TTL, for seconds, wey the record carry when dem hand am out.

Copies dey for more places than people expect: browser own short cache, stub resolver for the machine, recursive resolver wey that network dey use, and any resolver wey VPN install for the client. Each one keep its copy for up to the TTL wey e receive. Two people for two networks fit see two different answers for hours, and both machines still dey behave correctly.

Monitor the countdown against a caching resolver:

dig @1.1.1.1 example.com +noall +answer

Run am twice, with few seconds between the runs. The TTL for the answer go reduce. When e reach zero, the resolver discard the record and ask your nameserver again.

Another cache dey wey almost nobody dey account for: negative answers. When resolver receive say a name no exist, e cache that NXDOMAIN too, for the time wey the last field of your zone's SOA record set.

dig example.com SOA +short

The final number for that line na the negative TTL, often 3600. So if you look up staging.example.com before you create am, the record fit remain hidden from you for full hour after you create am. Create the record first, then query am.

Changing nameservers dey slower than changing a record, and the reason na mechanical. The delegation records for the .com zone dey served with TTL of 172800 seconds, wey be two days, so resolver wey cache your old nameservers fit continue asking dem for that long. Na from here the advice to "allow up to 48 hours" come from. E apply to nameserver changes, not ordinary record edits.

Plan migration around the TTL instead of fighting am:

1. Lower the record's TTL to 300 and save am.
2. Wait longer than the old TTL, so every cached copy wey carry the old value don expire.
3. Change the address.
4. After traffic don move, raise the TTL back to 3600 or higher, because low TTL mean every resolver go ask your nameservers much more often.

To clear wetin your own machine dey hold:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics go print cache section with hit and miss counters, so immediately after flush, the next lookup go show as miss. Browsers keep separate cache, wey mean Chrome fit still use old answer after system cache don empty. Clear that one for chrome://net-internals/#dns. Check /etc/hosts too, because leftover line there dey override DNS for that machine and only that machine. getent hosts example.com shows the answer wey system go really use, including /etc/hosts.

Wildcard certificates dey prove with TXT record

A CA (certificate authority) dey check who control a name before e issue certificate. The HTTP-01 challenge dey serve file through port 80 for that exact hostname, and e work well for one name. Wildcard certificate dey cover *.example.com, wey be open-ended set of hostnames wey CA no fit fetch file from. Na why Let's Encrypt dey issue wildcards only through DNS-01 challenge. You go publish TXT record for _acme-challenge.example.com, with token wey CA give you. Control of the zone na the proof.

This one make your DNS host part of certificate renewal. Certbot need create and delete that TXT record by itself for every renewal, so e need API and matching plugin for your provider. When validation fail, the usual message na DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com. E mean say CA check before the record become visible. Either you never save am, or negative answer still dey cache. The complete procedure dey for guide about wildcard certificates with DNS-01 challenge.

VPN wey take over your resolver

A VPN (virtual private network) client normally dey replace the system resolver while e dey connected, because sending lookups go the local network go tell that network the name of every site wey you visit. Na correct behaviour be this, but e fit fail for two directions.

If the tunnel come up and names stop resolving while addresses still dey work, the resolver wey the client install no dey reachable from inside the tunnel. ping 1.1.1.1 succeed and curl https://example.com return curl: (6) Could not resolve host: example.com. But if the tunnel come up and lookups still dey go the network wey you dey use, your traffic dey tunnel while the local resolver still dey see every name wey you ask for.

resolvectl status

That command print the resolver wey each link dey use, so you fit see the one wey the tunnel install and whether na the one you intend. WireGuard tunnel set this from the DNS = line for the client config, and fix DNS when WireGuard take over the resolver explain the systemd-resolved and resolvconf cases for detail.

The reply codes, and wetin each one dey tell you

• NXDOMAIN: authoritative server dey talk say the name no dey exist. Check the spelling, check whether domain suffix repeat two times, and check say you edit the zone wey your delegation dey point to.
• NOERROR with empty ANSWER SECTION: the name dey exist, but e no get record for the type wey you ask for. If you ask for AAAA when na only A dey exist, na exactly this result you go get.
• SERVFAIL: resolver try but e no fit produce answer. The two common causes na authoritative servers wey no reply at all, and DNSSEC (domain name system security extensions) validation wey fail. Test with dig @1.1.1.1 example.com A +cd, wey disable validation. If answer with +cd and SERVFAIL come back without am, na the signatures cause the problem. This fit happen after nameserver move when parent still dey publish the old DS (delegation signer) record.
• REFUSED: the server wey you ask no go answer that question, usually because you point dig to authoritative server for domain wey e no serve.
• ;; connection timed out; no servers could be reached: dig never reach resolver. Na network or resolver problem for your side, so domain no be the problem.

ping: example.com: Temporary failure in name resolution na the same class of failure wey glibc report instead of dig.

Make you run nameservers for your own VPS?

You fit. bind9, knot or nsd go serve your zone from the server, and e go teach you more about DNS pass any panel. The problems na practical ones. Domain suppose get at least two nameservers for separate networks, so one VPS go become one failure point for every service wey dey on the domain, including mail. Nameservers wey dem name inside the domain wey dem dey serve need glue records for the registrar. This na the address of ns1.example.com wey dey stored for the parent zone, because without am lookup no get how to start. When resolver no fit reach your nameserver, e no go fall back to your website. The whole domain go disappear for that user. Hosted DNS wey get API na the lower-risk choice for most people. Running caching resolver for your VPS for your own machines na different work, and e require far less commitment.

FAQ

Why my DNS change never propagate yet?

Nothing dey propagate. Your authoritative nameservers hold the new value immediately you save am, and every resolver wey don already ask keeps the cached copy until the TTL wey e receive expires. Ask the authoritative server directly with dig @ns1.your-dns-host.net example.com A +short. If e return the new address, the change don dey live and na caching remain. If you change nameservers instead of records, expect say e go take much longer, because TLD delegations dey distribute with a two day TTL.

How I fit find which nameservers my domain dey actually use?

dig example.com NS +short prints the nameservers wey dey answer for the domain now, and dig +trace example.com shows the referral chain from the root, including the delegation wey TLD servers dey hand out. If those names no be the provider wey get the panel you dey edit, na your bug be that. Either edit the records for the provider wey the delegation name, or change the delegation for your registrar make e point where you want.

My domain dey resolve but the site still no load. Wetin I go do now?

DNS don finish as soon as dig example.com A +short return your server address. After that, na connection problem. If curl -I http://example.com return Connection refused, e mean say nothing dey listen on that port. Request wey hang until e time out means firewall drop the packet. Check say your web server dey run and e bind to the public address, then check the firewall for the server and the separate network firewall for your provider control panel.

Why I no fit put CNAME for my root domain?

CNAME dey show say one name na alias for another name, and a name wey get CNAME no fit carry any other record. Your root domain must carry SOA and NS records so e fit exist as a zone, so e no fit also be CNAME. Use an A record wey hold the address for the root, or use the provider feature wey dem dey sell as ALIAS, ANAME or CNAME flattening. This feature stores one name and answers queries with the address wey that name currently resolve to.