DNS-Based Blocking, VPN Stability, and Designing for Resilience (Continuation of Outline Setup)

In our recent setup of an Outline-based VPN server, we faced a practical issue. There was IP-based blocking and instability in Iran’s network. The IP itself became a bottleneck in handling the Outline Access Keys.

To explain more, when the IP is blocked by the internet disruption system, I have to rotate the IP in my AWS Lightsail. Each individual using my service needs to manually remove the key. Then, they add it back with the updated IP.

So, the best solution would be to move into DNS based solution since the cost of disrupting the DNS handshake is high (In the first two weeks of complete blackout in Iran, the DNS protocol was down and blocked, and the cost estimated at $35.7M USD a day, more info: https://iranwire.com/en/news/148305-357-million-a-day-the-hidden-cost-of-irans-internet-blackout/)

Also in restrictive or filtered networks, DNS queries are inspected not by the IP but also semantically. If the domain being resolved is flagged, resolution fails or traffic is silently dropped.

Architecture Overview

I deployed:

• VPS hosted on AWS Lightsail
• Outline server running Shadowsocks protocol

The initial issue was straightforward:

• Direct IP usage works temporarily but is fragile.
• Single-IP deployments create a single failure surface.

This forced me to rethink how DNS should behave in this architecture.

I decided to treat this problem with having my architecture and InfoSec hat on. So:

Design Principle #1: Neutral Domain Naming

If DNS inspection is happening, semantic patterns matter.

Domains that:

• Include “vpn”
• Include “proxy”
• Include “outline”
• Include politically sensitive keywords

…are easier to classify heuristically.

But using neutral, brand-agnostic domain names with no obvious association to VPN services won’t make a system invisible. It reduces its statistical visibility.

Security through obscurity is weak alone — but reducing unnecessary signals is smart engineering.

Design Principle #2: DNS Abstraction Over Direct IPs

Instead of distributing raw IP addresses to clients, we shifted to:

api.yourdomain.com → A/AAAA record → VPS IP

Why?

Because:

• IP rotation becomes possible
• Infrastructure changes don’t require user reconfiguration (Literally no re-adding access keys)
• DNS becomes a control layer

Now if an IP gets blocked:

• Re-attaching a new Static IP in Lighsail
• Update DNS record in CloudFlare
• Users remain untouched

That means minimal friction. Maximum continuity. For non-technical users, this matters enormously.

Design Principle #3: IP Rotation Strategy

One IP = one point of failure.

We explored two strategies:

1. Manual IP Rotation

• Provision new Lightsail instance
• Reconfigure Outline
• Update DNS A record
• Decommission old instance

Low complexity, high control.

2. Multi-Server Architecture Behind DNS (This is my next move)

Multiple VPS instances in different regions:

api.domain.com → multiple A records

DNS round-robin distributes load and creates redundancy.

Caveat which exposes a challenge at this moement for me:

Outline access keys are server-specific. So true multi-server redundancy requires orchestration or automation tooling.

DNS rotation alone doesn’t magically unify servers — the application layer must support it.

Design Principle #4: Whois and Metadata Hygiene

Domain registration data can be a signal.

Using Cloudflare:

• Registrar privacy enabled
• WHOIS redacted
• Nameservers generic

Does this make the system invisible? No.

Does it reduce unnecessary exposure? Yes.

Reduce surface area. Reduce signals.

Design Principle #5: Understanding Path MTU & MSS (Stability Matters)

We also saw instability symptoms:

• Images/videos failing to send
• Intermittent ping drops
• Connection appearing active but unreliable

This pointed toward Path MTU issues.

Path MTU = Maximum Transmission Unit allowed end-to-end.

If packet size exceeds a filtered network’s limit:

• Packets drop
• No fragmentation allowed
• Traffic stalls

Solution:

Enable MSS clamping on the server firewall.

This adjusts TCP’s Maximum Segment Size dynamically so packets stay below the network’s tolerated size.

It’s not glamorous.

It’s just physics of packet size.

Networking is brutally literal.

This one is still work-in-progress as some more adjustment is needed to handle large packet sizes.

Infrastructure is less about hiding and more about adapting.

Every control surface (DNS, IP, MTU, TLS fingerprinting) is part of a dynamic system.

I will update once I have a concrete solution on PMTU and MSS in the future. For now it is still a challenge.