How to point a PKNIC .pk domain at Vercel

We searched for this before we did it, because doing DNS from first principles on a client's live domain is not anyone's idea of a good afternoon. There is nothing. Vercel's documentation assumes you are at GoDaddy, Namecheap or Cloudflare. PKNIC's documentation assumes you know what you are doing. (For the whole path from buying a domain to a live site, start with the domains, hosting and deployment guide.) Between the two is a gap that every Pakistani developer running a .pk domain falls into exactly once.

The short version. Point the apex at Vercel with an A record to 76.76.21.21, then add a www CNAME pointing at the target Vercel gives you in the project's domain settings. Save in the PKNIC panel, add both hostnames in Vercel, and wait. SSL provisions automatically once the records resolve. Budget a few hours, not the fifteen minutes an international registrar takes.

Why .pk is different

An apex domain cannot use a CNAME. That is not a PKNIC rule, it is how DNS works: the root of a zone has to carry SOA and NS records, and a CNAME cannot coexist with them. Registrars with modern panels paper over this with ALIAS or ANAME records, which look like CNAMEs and behave like A records that update themselves.

PKNIC does not offer that. So the apex gets a real A record with a real IP in it, which is the part that makes people nervous, because an IP address feels like something that will change and break silently at 2am.

It will not. 76.76.21.21 is Vercel's stable anycast address for exactly this purpose, and it resolves to whichever of their edge locations is nearest the visitor. One IP, many locations.

The records

Two records, and only two.

Type: A       Name: @      Value: 76.76.21.21
Type: CNAME   Name: www    Value: <the target shown in your Vercel project>

The www target is per project now. Vercel used to hand everyone alias.vercel.sh, and older guides still say that. Current projects get something in the form xxxxxxxxxxxx.vercel-dns-0NN.com, generated for your project and visible under Project, Settings, Domains once you have added the domain there. Copy it from the dashboard rather than from any article, including this one.

In the PKNIC panel the apex is entered as @ or as the bare domain depending on which version of the interface you are looking at. If @ is rejected, enter the domain itself.

Order matters more than people expect

Add the domain in Vercel first, then set the records at PKNIC. Not the other way around.

Vercel will not issue a certificate for a hostname it does not know about, and it verifies by checking DNS. If you set DNS first and add the domain later, nothing is broken, but you will spend the waiting period looking at a domain that resolves to a Vercel error page and wondering which half you got wrong. Adding it in Vercel first means the only variable is propagation.

Add both example.pk and www.example.pk in Vercel. Pick one as canonical and let Vercel redirect the other. Which one you pick barely matters for ranking; picking neither, and serving both, is the mistake.

Propagation, honestly

International registrars often propagate in minutes, which has trained everyone to expect instant. .pk is slower. Plan for a few hours and do not be alarmed by the first hour.

While you wait, check resolution directly rather than by refreshing the browser, because your own machine and your ISP will cache the old answer long after the change has taken:

dig +short example.pk
dig +short www.example.pk
nslookup example.pk 8.8.8.8

Query 8.8.8.8 specifically. Asking Google's resolver tells you what the wider internet sees, which is the thing that matters. Asking your ISP's resolver tells you what your ISP has cached, which is the thing that will mislead you.

The certificate is the last piece to arrive. Vercel requests it once DNS resolves, and there is a window where the domain loads over HTTP and throws a certificate warning over HTTPS. That window is normal. If it lasts more than a couple of hours after DNS is clearly resolving, remove the domain in Vercel and add it again, which forces a fresh issuance attempt.

What actually goes wrong

Existing records left in place. If the domain was previously parked or pointed at a shared host, there is an old A record sitting there. Two A records means DNS answers with both, and roughly half of your visitors reach the old host. Delete the old record rather than adding alongside it. This is the single most common failure and it produces the worst symptom: a site that works for you and not for your client.

A leftover CAA record. If the domain previously used a host that set a CAA record naming its own certificate authority, Let's Encrypt cannot issue for it and Vercel's SSL step fails silently. Check with dig example.pk CAA +short. If anything comes back and you do not know why it is there, remove it.

Email records lost. Repointing a domain that was receiving mail without carrying the MX records across takes the mail down with no warning, because nothing on the website breaks. Copy MX, SPF, DKIM and DMARC before you change anything. We wrote a separate piece on getting .pk email to actually reach inboxes.

Trailing dots. Some panels require target.example.com. with the dot, some reject it. If a CNAME is not resolving and everything else looks right, try it the other way.

The tradeoff worth naming

This setup gives you Vercel's edge network with your domain still administered at PKNIC. The cost is that DNS changes go through PKNIC's panel, which is slower and less forgiving than a modern registrar's, and there is no ALIAS record if you later want the apex to follow a hostname instead of an IP.

If you have not chosen a host yet, we measured which ones are actually fast from Pakistan.

The alternative is delegating the nameservers to a service with a better panel and leaving PKNIC holding only the registration. That is a legitimate choice and it makes future DNS work easier. We have kept domains at PKNIC because the two-record setup is stable once it is right, and because fewer parties in the chain means fewer places for a renewal to go wrong. Reasonable people go the other way.

Talk to us

We run .pk domains on modern hosting for clients across Balochistan and Pakistan. If yours is stuck between a registrar and a host, send us the domain and we will tell you what is wrong with it.