How to Use Satellite Internet (Starlink) to Keep DNS and Domain Management Online During Blackouts

Keep domains and DNS reachable when your ISP fails: using Starlink as a resilient uplink

Hook: You’ve planned for power outages and backups — but when the terrestrial ISP goes dark, your DNS and registrar access often become single points of failure. This guide shows how to use Starlink (or equivalent satellite LEO services) to restore management plane access, perform emergency DNS updates, and keep domains resolvable during blackouts — securely and repeatably.

Why this matters in 2026

Satellite internet (LEO constellations like Starlink) has moved from an experimental backup to an operational resilience layer for many orgs. By late 2025 many teams relied on LEO links to maintain communications during regional outages; the New York Times reported that activists and groups used Starlink to stay online during local shutdowns in 2023–2025. With improved throughput and lower latency in 2025, LEO links are now practical for critical management plane tasks like DNS API calls and SSH sessions.

Key takeaway: Don’t treat satellite as a last resort. Treat it as a systematically tested, secure recovery path for domain and DNS operations.

High-level strategy

• Pre-provision an authenticated, least-privilege API path to your DNS provider and registrar.
• Provide a predictable, secure remote access route from the satellite uplink to an authenticated bastion or cloud endpoint with a static IP.
• Harden registrar settings (locks, 2FA, DNSSEC, transfer protections) before a crisis hits.
• Automate common emergency changes with scripts that run locally from a satellite-connected device or from an on-demand cloud runbook.

Pre-incident configuration (do this now)

1) Harden registrars and zones

• Enable registrar lock (clientTransferProhibited or equivalent) and request registry lock where available to stop unauthorized transfers.
• Enable DNSSEC to defend against spoofing if you need to change name servers remotely.
• Require multi-factor authentication and hardware tokens for registrar accounts; favor U2F/FIDO2 keys.
• Document recovery contacts and store them securely (encrypted vault + offline copy). Do not rely solely on WHOIS public contacts.

2) Build an emergency bastion and relay

Because many consumer Starlink connections use carrier-grade NAT (CGNAT) and the residential service often doesn't provide a fixed public IPv4 address, you should provision a small cloud bastion with a stable public IP (or IPv6) that you control. The satellite terminal will create an outbound, persistent tunnel to this bastion so you can initiate management actions from anywhere (even if the local link is NATed).

• Choose two regions (primary/secondary) for geo-redundancy.
• Use SSH with certificate-based auth or WireGuard to establish persistent secure tunnels from the satellite-connected device to the bastion.
• Run autossh or systemd units to maintain reverse tunnels that survive network drops.

3) Create least-privilege DNS API tokens

Create scoped API tokens on your DNS provider (e.g., Cloudflare API Tokens, AWS IAM user for Route53 with granular policy). For registrars, use API keys where available and rotate them on a schedule.

Principles: token scope, short expiry for emergency tokens (if supported), rotate after use, and keep secrets in a secure vault (HashiCorp Vault, AWS Secrets Manager, or an HSM-backed store).

4) Prepare offline-runbooks and scripts

Store runnable scripts that implement the most-likely emergency actions: change A/AAAA records, update name servers, change MX records, and initiate domain transfer cancellations. Keep an encrypted copy on a USB token and a copy in a secure cloud vault accessible through your bastion.

Network design patterns for satellite uplinks

Option A — Direct management from the Starlink terminal

Best for quick, console-driven work when Starlink provides public outbound routing and you only need to make a few API calls. Make sure your laptop has local tools and the API tokens.

Option B — Persistent reverse tunnel to cloud bastion (recommended)

Because residential Starlink often disallows inbound connections, make the connection outbound from the satellite side to the cloud bastion. Then SSH into the bastion from your secure device (or use the bastion as the jump host) and perform registry or DNS operations from a predictable IP.

Option C — VPN over Starlink to a corporate network

If you operate a corporate VPN, ensure the Starlink device can connect outbound to your VPN concentrator. Use WireGuard for simplicity and performance.

Concrete examples and scripts

Below are tested patterns you can adapt. Replace placeholders with your real values.

1) Maintain a persistent reverse SSH tunnel using autossh

On the satellite-connected machine, run autossh to expose a remote port on the bastion back to the satellite device. This makes the device reachable from the bastion even if it’s behind CGNAT.

# Install autossh (Debian/Ubuntu)
# sudo apt-get update && sudo apt-get install -y autossh

# Example autossh command: keep a reverse tunnel from satellite -> bastion
autossh -M 0 -f -N -o "ServerAliveInterval=30" -o "ServerAliveCountMax=3" \
  -R 22022:localhost:22 user@bastion.example.com -i /path/to/id_rsa

# Explanation: opens port 22022 on bastion which tunnels back to localhost:22 on the satellite device

From your workstation you then SSH to the bastion and connect to the satellite machine:

# From your laptop (authenticated to bastion)
ssh -J user@bastion.example.com -p 22022 localuser@localhost

2) Keep the tunnel resilient with systemd

[Unit]
Description=Persistent autossh reverse tunnel
After=network-online.target
Wants=network-online.target

[Service]
User=youruser
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -N -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -R 22022:localhost:22 user@bastion.example.com -i /home/youruser/.ssh/id_rsa
Restart=always

[Install]
WantedBy=multi-user.target

3) Update DNS record via Cloudflare API (example)

Store your Cloudflare API token in a vault or environment variable. This example updates an A record to point a domain to an emergency IP.

# set variables
ZONE_ID="your_zone_id"
RECORD_ID="your_record_id"
API_TOKEN="${CLOUDFLARE_API_TOKEN}"  # from secure vault
EMERGENCY_IP="203.0.113.42"

curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records/${RECORD_ID}" \
  -H "Authorization: Bearer ${API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"type":"A","name":"example.com","content":"'${EMERGENCY_IP}'","ttl":120,"proxied":false}' | jq '.'

4) Change Route53 record with AWS CLI

# Create change batch JSON (change-to-emergency.json)
cat > change-to-emergency.json <

# emergency-dns.sh (simplified)
set -e
PROVIDER="$1"   # cloudflare|route53
case "$PROVIDER" in
  cloudflare)
    ./cloudflare-update.sh
    ;;
  route53)
    ./route53-update.sh
    ;;
  *) echo "Unknown provider"; exit 1;;
esac