The Record Types That Matter#

A and AAAA#

The most basic. Maps a domain to an IP address:

example.dev.    A      203.0.113.50
example.dev.    AAAA   2001:db8::1

A is IPv4. AAAA is IPv6. You want both if your server supports v6.

CNAME#

An alias. Points one name to another:

www.example.dev.    CNAME    example.dev.

This says “www is the same as the bare domain.” The DNS resolver follows the chain and ends up at the A record for example.dev.

The critical rule: you cannot have a CNAME alongside other records for the same name. This means the zone apex (bare domain) usually cannot be a CNAME. Use an A record there instead.

MX#

Where to deliver email:

example.dev.    MX    10 mail.example.dev.

The number is priority. Lower means preferred. If you have a backup mail server:

example.dev.    MX    10 mail.example.dev.
example.dev.    MX    20 backup-mail.example.dev.

Senders try priority 10 first, fall back to 20 if it is down.

TXT#

Arbitrary text. Used for verification and email authentication:

example.dev.    TXT    "v=spf1 a mx ip4:203.0.113.50 ~all"

SPF tells receiving mail servers which IPs are allowed to send email for your domain. DKIM and DMARC are also TXT records. Google and other services use TXT for domain ownership verification too.

NS#

Nameserver delegation. Usually set by your registrar:

example.dev.    NS    ada.ns.cloudflare.com.
example.dev.    NS    greg.ns.cloudflare.com.

This tells the internet “Cloudflare knows the DNS records for example.dev.” You rarely touch these directly.

Debugging With dig#

dig is the standard DNS debugging tool:

# Basic lookup
dig example.dev

# Specific record type
dig MX example.dev

# Short output
dig +short example.dev
# 203.0.113.50

# Use a specific DNS server
dig @8.8.8.8 example.dev

# Trace the full resolution path
dig +trace example.dev

The +trace option follows the entire DNS chain from the root servers down. This is invaluable when debugging propagation issues.

TTL#

Time To Live. How long DNS resolvers cache a record:

example.dev.    300    IN    A    203.0.113.50

300 means 5 minutes. After that, resolvers ask again. Lower TTL means faster propagation when you change records, but more DNS queries hitting your nameservers.

Before a migration:

1. Lower TTL to 60 seconds, 24 hours ahead
2. Wait for the old TTL to expire
3. Change the record
4. Verify
5. Raise TTL back to 3600 or higher

This way, when you change the IP, everyone picks up the new address within a minute.

Common Patterns#

Subdomain to a different server#

api.example.com.    A    203.0.113.50

Wildcard#

*.example.com.    A    93.184.216.34

Matches any subdomain that does not have a more specific record. Useful for catch-all routing.

Email setup#

Minimum viable email DNS:

example.com.         MX   10 mail.example.com.
mail.example.com.    A    93.184.216.34
example.com.         TXT  "v=spf1 a mx ~all"
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine"
sel._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIj..."

Cloudflare proxy vs DNS-only#

If you use Cloudflare:

# Proxied (orange cloud) - traffic goes through Cloudflare CDN
example.dev.    A    203.0.113.50    (proxied)

# DNS-only (gray cloud) - direct connection to your server
mail.example.dev.    A    203.0.113.50    (DNS-only)

Proxied records hide your real IP and add DDoS protection. But they break non-HTTP protocols. Mail servers, game servers, and anything that is not HTTP/HTTPS needs DNS-only.

Why Is My DNS Not Working?#

In order of likelihood:

1. Propagation delay. You changed the record 2 minutes ago. Wait for the TTL to expire. Check with dig @8.8.8.8 to see what Google’s DNS returns.

2. Browser cache. Chrome caches DNS aggressively. Try chrome://net-internals/#dns and clear it, or just use a different browser.

3. Wrong record type. You added a CNAME where you needed an A record, or vice versa.

4. Cloudflare proxy interfering. Your service needs direct access but the record is proxied. Switch to DNS-only.

5. Missing trailing dot. In some DNS configurations, mail.example.com and mail.example.com. are different. The dot makes it fully qualified. Most providers handle this for you, but raw zone files need it.

# Quick sanity check script
for record in A AAAA MX TXT CNAME; do
  echo "=== $record ==="
  dig +short $record example.com
done

DNS is not complicated once you understand the record types. The frustrating part is always the caching and propagation delays. Lower your TTLs before making changes, use dig to verify, and be patient.

Let us build a WebSocket server from scratch using only the Node.js standard library.

The Handshake#

WebSocket starts as an HTTP upgrade request. The client sends:

GET / HTTP/1.1
Host: localhost:8080
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

The server responds:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

The Sec-WebSocket-Accept value is computed from the client’s key:

const crypto = require('crypto');

function computeAcceptKey(clientKey) {
  const MAGIC = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';
  return crypto
    .createHash('sha1')
    .update(clientKey + MAGIC)
    .digest('base64');
}

The magic string is literally part of the RFC. Every WebSocket implementation uses it.

The Server#

const http = require('http');
const crypto = require('crypto');

const MAGIC = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';

const server = http.createServer();
const clients = new Set();

server.on('upgrade', (req, socket) => {
  const clientKey = req.headers['sec-websocket-key'];
  if (!clientKey) {
    socket.destroy();
    return;
  }

  const acceptKey = crypto
    .createHash('sha1')
    .update(clientKey + MAGIC)
    .digest('base64');

  socket.write(
    'HTTP/1.1 101 Switching Protocols\r\n' +
    'Upgrade: websocket\r\n' +
    'Connection: Upgrade\r\n' +
    `Sec-WebSocket-Accept: ${acceptKey}\r\n` +
    '\r\n'
  );

  clients.add(socket);
  console.log(`Client connected (${clients.size} total)`);

  socket.on('data', (buffer) => {
    const message = decodeFrame(buffer);
    if (message === null) return;

    console.log('Received:', message);

    // Echo to all clients
    for (const client of clients) {
      client.write(encodeFrame(message));
    }
  });

  socket.on('close', () => {
    clients.delete(socket);
    console.log(`Client disconnected (${clients.size} total)`);
  });

  socket.on('error', () => {
    clients.delete(socket);
  });
});

server.listen(8080, () => {
  console.log('WebSocket server on ws://localhost:8080');
});

Frame Decoding#

WebSocket messages are wrapped in frames. The frame format:

 0               1               2               3
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |            (16/64)            |
|N|V|V|V|       |S|             |                               |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+-------------------------------+
|     Masking key (if MASK set)                                 |
+-------------------------------+-------------------------------+
|     Payload Data                                              |
+---------------------------------------------------------------+

Client-to-server frames are always masked. Server-to-client frames are never masked. Here is the decoder:

function decodeFrame(buffer) {
  const firstByte = buffer[0];
  const opcode = firstByte & 0x0f;

  // 0x1 = text, 0x8 = close, 0x9 = ping, 0xA = pong
  if (opcode === 0x8) return null; // close frame

  const secondByte = buffer[1];
  const isMasked = (secondByte & 0x80) !== 0;
  let payloadLength = secondByte & 0x7f;
  let offset = 2;

  if (payloadLength === 126) {
    payloadLength = buffer.readUInt16BE(2);
    offset = 4;
  } else if (payloadLength === 127) {
    payloadLength = Number(buffer.readBigUInt64BE(2));
    offset = 10;
  }

  let maskingKey;
  if (isMasked) {
    maskingKey = buffer.slice(offset, offset + 4);
    offset += 4;
  }

  const payload = buffer.slice(offset, offset + payloadLength);

  if (isMasked) {
    for (let i = 0; i < payload.length; i++) {
      payload[i] ^= maskingKey[i % 4];
    }
  }

  return payload.toString('utf-8');
}

Frame Encoding#

Sending from server to client is simpler because we do not mask:

function encodeFrame(message) {
  const payload = Buffer.from(message, 'utf-8');
  const length = payload.length;

  let header;
  if (length < 126) {
    header = Buffer.alloc(2);
    header[0] = 0x81; // FIN + text opcode
    header[1] = length;
  } else if (length < 65536) {
    header = Buffer.alloc(4);
    header[0] = 0x81;
    header[1] = 126;
    header.writeUInt16BE(length, 2);
  } else {
    header = Buffer.alloc(10);
    header[0] = 0x81;
    header[1] = 127;
    header.writeBigUInt64BE(BigInt(length), 2);
  }

  return Buffer.concat([header, payload]);
}

Testing It#

Open a browser console:

const ws = new WebSocket('ws://localhost:8080');
ws.onmessage = (e) => console.log('Got:', e.data);
ws.onopen = () => ws.send('hello from browser');

Or use a Node.js client:

const net = require('net');
const crypto = require('crypto');

const key = crypto.randomBytes(16).toString('base64');
const socket = net.createConnection(8080, 'localhost', () => {
  socket.write(
    'GET / HTTP/1.1\r\n' +
    'Host: localhost:8080\r\n' +
    'Upgrade: websocket\r\n' +
    'Connection: Upgrade\r\n' +
    `Sec-WebSocket-Key: ${key}\r\n` +
    'Sec-WebSocket-Version: 13\r\n' +
    '\r\n'
  );
});

What This Does Not Handle#

This implementation is deliberately minimal. A production WebSocket server also needs:

• Ping/pong frames for connection keepalive
• Fragmented messages where large payloads span multiple frames
• Close handshake with proper status codes
• Per-message compression (the permessage-deflate extension)
• Backpressure when clients read slower than you write

That is why libraries like ws exist. But knowing the protocol means you understand what those libraries are doing, and you can debug problems at the frame level instead of guessing.

The entire WebSocket protocol fits in RFC 6455, which is surprisingly readable as RFCs go. The core framing logic is maybe 100 lines of code. Everything else is just handling edge cases.

This means changing your DNS server does nothing. The ISP sees the domain name in the TLS handshake before the connection is encrypted and drops the packet. You need a different approach. Mine has two parts: zapret, which splits up the TLS ClientHello so the DPI system cannot read the SNI field in time, and DNS-over-TLS, so DNS queries stop travelling in plain text.

How DPI Blocking Works#

When you connect to a website over HTTPS, the first thing your browser sends is a TLS ClientHello message. This message is not encrypted. It contains the Server Name Indication field, which tells the server which domain you are trying to reach. This is necessary because multiple domains can share the same IP address, and the server needs to know which certificate to present.

Your ISP inspects this field. If the domain matches their blocklist, they inject a TCP RST packet or simply drop the connection. From your perspective, the site just times out or you get a connection reset.

The Zapret Approach#

There is a tool called zapret that manipulates outgoing packets to confuse DPI systems. It does not encrypt anything or route traffic through a proxy. Instead, it exploits the fact that DPI systems have to make real-time decisions about packets and often take shortcuts.

The basic techniques include fragmenting the ClientHello across multiple TCP segments, adding padding to push the SNI field into a second packet, or modifying TCP flags in ways that confuse stateful inspection engines but are tolerated by the destination server.

I run zapret as a systemd service. It hooks into the outgoing packet flow using nfqueue and modifies specific packets before they leave my machine. The destination server receives the same data, just split up differently, and handles it fine. The ISP DPI system sees fragments that it cannot reassemble quickly enough and lets them through.

DNS-over-TLS Complement#

Zapret handles the TLS handshake problem, but DNS queries can still leak information. Even if the ISP cannot block the connection, they can see which domains you are resolving and log that data.

I force all DNS through DNS-over-TLS using systemd-resolved. The configuration tells resolved to only use TLS-encrypted DNS and to require valid certificates from the upstream resolver. I use Cloudflare and Google as upstream servers since both support DNS-over-TLS.

The resolved config looks straightforward. You set the DNS servers and tell it to require encrypted transport. After restarting the service, all DNS queries from the machine go through TLS on port 853 instead of plaintext on port 53.

The VPN Conflict#

This setup conflicts with split-tunnel VPN configurations. When the VPN is active, DNS queries for private services need to go to the VPN DNS server over the tunnel. But the DPI bypass forces all DNS through TLS, which means queries to the VPN DNS server also try to use TLS.

The VPN DNS server is just dnsmasq. It does not speak TLS. So the queries fail and private domain names do not resolve.

The fix is a PostUp hook in the WireGuard configuration that disables DNS-over-TLS specifically on the VPN interface. The system still uses DoT for all other DNS queries, but queries routed through the VPN go as plain DNS over the encrypted tunnel. Since the tunnel itself is encrypted, this is fine from a privacy perspective.

Getting this right took some trial and error. The symptoms were confusing: public websites worked, VPN connected successfully, but private subdomains just would not resolve. Once I traced it to the DoT setting, the fix was one line.

Performance Impact#

Zapret adds essentially zero latency. The packet manipulation happens in kernel space and takes microseconds. DNS-over-TLS adds a small amount of latency to the first query for each domain, maybe 10 to 20 milliseconds. Subsequent queries are cached by resolved so you do not notice it.

I have been running this setup for months and have never noticed any performance impact in normal usage. Streaming, gaming, and large downloads all work at full speed. The only time I notice it is when I forget to check if the service is running and a blocked site fails to load.

Reliability#

The DPI bypass works about 99 percent of the time. Occasionally the ISP updates their inspection rules and a specific technique stops working. Zapret has multiple strategies and you can configure fallbacks. Usually updating to the latest version fixes any regressions within a day or two.

The DNS-over-TLS setup is rock solid. I have never had it fail. Systemd-resolved handles reconnections and failovers between upstream servers automatically.

Legal and Ethical Notes#

This is not about accessing illegal content. My ISP blocks legitimate websites, often because a previous user of the domain or IP address did something that triggered a broad block. The blocking is opaque, there is no notification, and there is no process for getting a site unblocked.

Bypassing DPI to access legal content that your ISP has incorrectly or broadly blocked is a reasonable thing to do. The tools involved are all open source and widely used. Nobody has ever gotten in trouble for running zapret on their own machine.

If you are in a situation where your ISP does DPI blocking, this setup gives you back control over your own internet connection without the overhead and privacy implications of routing all your traffic through a third-party VPN.

The Problem#

I run several services on my VPS that should not be publicly accessible: a git server, an admin panel, a VPN management UI, and a mail server admin interface. These need to be reachable from my laptop and phone, but nobody else should be able to see them.

The obvious solution is a VPN. But I do not want all my traffic going through a server in Germany when I am watching a video or browsing the web. I want my normal internet connection for everything except the few private services.

Split Tunnel Configuration#

The key is the AllowedIPs setting in the WireGuard client config. Instead of 0.0.0.0/0 which routes everything, you specify only the VPN subnet:

[Interface]
PrivateKey = <client-private-key>
Address = 10.0.0.2/24
DNS = 10.0.0.1

[Peer]
PublicKey = <server-public-key>
Endpoint = your-server-ip:51820
AllowedIPs = 10.0.0.0/24

With this config, only traffic destined for 10.0.0.x addresses goes through the tunnel. Everything else takes the normal route. Your browsing speed stays the same, your public IP does not change, and you still get access to your private services.

DNS Is Where the Magic Happens#

The split tunnel routes packets, but your browser needs to know that admin.example.com should resolve to a VPN IP instead of a public one. This is where a local DNS server comes in.

I run dnsmasq on the VPN server, listening only on the WireGuard interface. It has entries like:

address=/git.example.com/10.0.0.1
address=/admin.example.com/10.0.0.1
address=/vpn.example.com/10.0.0.1

For any domain not in this list, dnsmasq forwards the query to Cloudflare or Google DNS. So private subdomains resolve to the VPN IP, and everything else resolves normally.

The client config sets DNS = 10.0.0.1 which tells the system to use the VPN DNS server. Combined with the split tunnel routing, DNS queries for private domains go through the tunnel to dnsmasq, and all other DNS queries go through the tunnel too but get forwarded to public DNS by dnsmasq.

The DNS-over-TLS Conflict#

This one took me a while to figure out. I use a DPI bypass tool on my local machine that forces all DNS through DNS-over-TLS via systemd-resolved. When the VPN comes up, the DNS setting should override this, but it does not always work cleanly.

The fix was a PostUp script in the WireGuard config:

PostUp = resolvectl dnsovertls %i no

This disables DNS-over-TLS specifically on the VPN interface so queries to 10.0.0.1 go through as plain DNS over the tunnel. Without this, the system tries to establish a TLS connection to the dnsmasq server, which obviously does not support TLS, and private domains fail to resolve.

No Public DNS Leaks#

One nice side effect of this setup: your private subdomains are completely invisible. There are no public DNS records for them. They do not show up in certificate transparency logs because the wildcard cert covers them. Someone scanning your domain will find the public subdomains but have no idea the private ones exist.

The only way to discover them is to be on the VPN, at which point dnsmasq resolves them. And even if someone knows the subdomain name and tries to access it from the public internet, Caddy returns 403 based on the source IP check.

Mobile Access#

WireGuard works great on phones. The official app for both iOS and Android supports split tunneling natively. I have the same config on my phone: only VPN traffic goes through the tunnel. This means I can check my git server from my phone without draining battery or slowing down everything else.

The one downside is that you have to manually toggle the VPN on when you need it. There is no automatic connection based on network or location. But honestly, it takes one tap and the connection establishes in under a second.

Resource Usage#

WireGuard is absurdly lightweight. The server side runs as a single container using about 30MB of RAM. The CPU usage is essentially zero unless you are pushing serious bandwidth. On the client side, the kernel module handles everything so there is no userspace overhead.

Compare this to OpenVPN which needs a full userspace daemon, TLS handshakes, and significantly more CPU per connection. For a personal VPN with one or two clients, WireGuard is comically overpowered.

Final Thoughts#

Split tunnel WireGuard gives you the best of both worlds: fast, private access to your services without compromising your normal internet experience. The setup takes maybe 30 minutes and the result is rock solid. I have had zero downtime in months.

The only complexity is the DNS piece, and even that is just a few lines in a dnsmasq config file. If you are running private services on a VPS, this is the way to expose them.