It’s Always DNS: Why Your Registrar’s Nameservers Are Killing Your Site
I’ve spent the last week debugging a Magento checkout failure for a client in Stavanger. The servers were fine. The load averages on the Dual Xeon boxes were barely scratching 0.5. Yet, every third request hung for two seconds. The culprit? DNS resolution timeouts.
Most of you register a domain and let the registrar handle the DNS. It’s convenient. It’s also a performance disaster. If your target audience is here in Norway, but your DNS queries are bouncing off a congested nameserver in Arizona, you are introducing latency before the first TCP packet even hits your web server. In 2009, with broadband speeds increasing and user patience decreasing, that delay is unacceptable.
The ".NO" Reality Check
We all know Norid runs a tight ship. You can't just buy a .no domain anonymously; you need an organization number in Brønnøysundregistrene. It’s bureaucratic, sure, but it keeps the neighborhood clean.
However, compliance with the Personal Data Act (Personopplysningsloven) and satisfying Datatilsynet isn't just about where your database lives. It's about the integrity of your entire stack. If you are routing traffic through non-EEA DNS providers that log queries without a Safe Harbor agreement, you are treading on thin ice.
Technical Deep Dive: Taking Control with BIND 9
Real sysadmins run their own resolvers. Or at least, they use a provider that understands the concept of "local." If you are hosting on a Linux VPS, you are likely using BIND (Berkeley Internet Name Domain). It’s the standard, but out of the box, it’s often misconfigured for high-traffic environments.
The Recursion Trap
One common mistake I see in /etc/bind/named.conf.options is leaving recursion open to the world. This turns your server into an open relay for DNS amplification attacks. Don't be that guy.
options {
directory "/var/cache/bind";
recursion no;
allow-transfer { none; }; // specific slaves only
listen-on-v6 { any; };
};
By setting recursion no;, you ensure your nameserver only answers for the zones it is authoritative for. This reduces CPU load and secures your infrastructure.
TTL: The Cache-22
Time To Live (TTL) settings are a balance. Set it too high (like 86400 seconds), and if you need to migrate your VPS IP, you're stuck waiting 24 hours for propagation. Set it too low (300 seconds), and you hammer your server with queries.
Pro Tip: Use a "ramp-down" strategy. Keep TTL at 24 hours normally. 48 hours before a planned migration, drop the TTL to 300 seconds. Once the move to the new IP is verified, bump it back up.
Latency Matters: The NIX Connection
Let’s talk physics. If your customer is in Oslo, and your server is in Oslo, the round-trip time (RTT) is practically zero. But if your DNS lookup has to travel to Frankfurt or London first, you add 20-50ms of overhead. That doesn't sound like much until you realize a modern site makes dozens of external lookups.
Here is a simple test. Run this from your local machine:
$ dig @your_nameserver_ip yourdomain.no | grep "Query time"
If that number is over 40ms and you are in the same country as your server, something is wrong.
The CoolVDS Advantage
We don't believe in separating the brain from the body. At CoolVDS, our DNS resolvers are located in the same datacenter as our VPS nodes, directly peered at NIX (Norwegian Internet Exchange).
While other providers are overselling resources on aging hardware, we use high-performance SAS 15k RPM RAID-10 arrays (and are currently testing early enterprise SSDs) to ensure that disk I/O—including the BIND zone file reads—is instantaneous. We treat DNS as a first-class citizen, not an afterthought.
| Feature | Standard Registrar DNS | CoolVDS Local DNS |
|---|---|---|
| Latency to Oslo | 40-150ms | < 5ms |
| Propagation Control | Limited / Slow | Instant Zone Reloads |
| Redundancy | Opaque | Transparent Secondary NS |
Take the Reins
Stop leasing your infrastructure's roadmap to a domain registrar that sells business cards on the side. Reliability is about owning your stack, from the A-record down to the metal.
If you are tired of SERVFAIL errors and sluggish lookups, it’s time to move. Spin up a Centos 5 instance on CoolVDS today, configure your zones, and watch your latency drop.