Fix Hostinger DNS Filtering & Enable DNS over TLS

Hostinger DNS filtering by default filters certain subdomains (like router.huggingface.co) used by AI inference endpoints, breaking n8n HTTP requests and other services. This guide shows you how to override Hostinger DNS with Cloudflare/Google DNS and enable DNS over TLS for privacy.

The Problem That Stopped Everything

You’ve just set up an n8n automation workflow on your Hostinger VPS to process data through Hugging Face’s AI models. Everything looks perfect in testing. You hit execute and… DNS resolution error.

Not just once. Every single time.

After hours of debugging, I discovered the culprit: Hostinger’s DNS was silently filtering certain subdomains used by AI inference endpoints like router.huggingface.co. This wasn’t a configuration error—it was Hostinger’s DNS infrastructure blocking legitimate services.

If you’re running AI workflows, API integrations, or any service that relies on specific subdomains, you might hit the same wall. Here’s how I fixed it permanently.

Why This Happens (And Why It Matters)

Hostinger, like many hosting providers, implements DNS-level filtering for security reasons. While this protects against malicious domains, it occasionally catches legitimate services in the crossfire—especially newer AI/ML infrastructure that uses dynamic subdomain routing.

The solution? Take control of your DNS by:

• Switching to reliable public DNS servers (Cloudflare + Google)
• Enabling DNS over TLS for encrypted queries
• Ensuring your containers inherit proper DNS settings

This fix gave me:

• ✅ Unfiltered access to all AI endpoints
• ✅ Encrypted DNS queries (privacy boost)
• ✅ Faster DNS resolution with caching
• ✅ Configuration that survives reboots

Prerequisites

Before diving in, make sure you have:

• Root or sudo access to your Hostinger VPS
• Ubuntu/Debian-based Linux (systemd-based)
• SSH terminal access
• 5-10 minutes

This guide works on Ubuntu 18.04+, Debian 10+, and similar systemd distributions.

The Complete Fix for Hostinger DNS Filtering: Step-by-Step

Step 1: Create Your Custom DNS Configuration

First, create a directory for systemd-resolved overrides:

sudo mkdir -p /etc/systemd/resolved.conf.d

Now create your DNS configuration file:

sudo nano /etc/systemd/resolved.conf.d/dns.conf

Paste this exact configuration:

[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=1.0.0.1 8.8.4.4
DNSSEC=no
Cache=yes
DNSOverTLS=yes

Save and exit: Press Ctrl + X, then Y, then Enter

What each setting does:

• DNS servers: Primary resolvers (Cloudflare 1.1.1.1 + Google 8.8.8.8)
• Fallback servers: Backup if primary fails
• DNSSEC=no: Prevents false failures on broken DNSSEC networks
• Cache=yes: Speeds up repeated lookups by 2-3x
• DNSOverTLS=yes: Encrypts queries to prevent ISP snooping and filtering

Step 2: Enable the Stub Resolver

This is critical for proper DNS caching and Docker networking:

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Important: Use stub-resolv.conf, NOT resolv.conf. The stub resolver enables local caching and proper container DNS inheritance.

Now restart the DNS service:

sudo systemctl restart systemd-resolved

Step 3: Verify Your Configuration

Check that everything is working:

resolvectl status

You should see:

DNS Servers: 1.1.1.1 8.8.8.8
FallbackDNS: 1.0.0.1 8.8.4.4
resolv.conf mode: stub

Verify DNS over TLS is active:

resolvectl status | grep DNSOverTLS

Expected output:

Protocols: -LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
Protocols: +DefaultRoute -LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
Protocols: -DefaultRoute -LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported

Step 4: Test DNS Resolution

The moment of truth—test the previously blocked domain:

curl -I https://router.huggingface.co

Success looks like:

HTTP/2 200 OK
HTTP/2 403 Forbidden
HTTP/2 404 Not Found

Any HTTP status code = DNS resolved successfully!

If you see Could not resolve host, revisit Step 1 and check your configuration syntax.

Step 5: Restart Your Containers (If Using Docker)

For n8n or other Docker containers:

docker restart <n8n-container-name>

For system-installed services:

sudo systemctl restart n8n

Wait 10-15 seconds for full startup.

Verify Your Containers Are Using New DNS

If you’re running Docker containers, confirm they inherited the new settings:

docker exec <n8n-container-name> cat /etc/resolv.conf

Should show:

# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

nameserver 127.0.0.11
search .
options ndots:0

# Based on host file: '/etc/resolv.conf' (internal resolver)
# ExtServers: [host(1.1.1.1) host(8.8.8.8) host(153.92.2.6) host(1.1.1.1) host(8.8.4.4)]
# Overrides: []
# Option ndots from: internal

This confirms Docker is using the host’s DNS resolver.

Testing in n8n Workflows

Now test your actual workflow:

1. Open your HTTP Request node pointing to Hugging Face (or other AI endpoint)
2. Click Execute node
3. Verify the request succeeds without DNS errors

If you see successful responses, congratulations! Your DNS filtering issue is resolved.

Does It Survive Reboots?

Yes! Test it:

sudo reboot

After reconnecting, verify:

resolvectl status

You should still see DNS Servers: 1.1.1.1 8.8.8.8 instead of Hostinger’s DNS.

Troubleshooting Common Issues

Issue 1: DNS Still Shows Hostinger IP

Symptom: resolvectl status shows Hostinger’s DNS servers

Fix:

sudo nano /etc/systemd/resolved.conf.d/dns.conf
# Verify the [Resolve] section is present
sudo systemctl restart systemd-resolved

Issue 2: DNS Over TLS Not Active

Symptom: grep DoT shows nothing

Fix: Check your configuration syntax:

sudo cat /etc/systemd/resolved.conf.d/dns.conf

Ensure:

• No extra spaces before [Resolve]
• No blank lines between settings
• File ends immediately after DNSOverTLS=yes

Issue 3: curl Still Fails

Symptom: Could not resolve host persists

Fix: Verify symlink is correct:

ls -la /etc/resolv.conf
# Should show: /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

If wrong, recreate it:

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved

Issue 4: Docker Container Still Has DNS Errors

Symptom: Container DNS errors after host fix

Fix: Containers cache DNS settings. Recreate them:

docker stop <n8n-container-name>
docker rm <n8n-container-name>
docker run -d --name <n8n-container-name> [your-original-docker-run-command]

Or with Docker Compose:

docker-compose down
docker-compose up -d

Quick Setup: One-Command Install

Want to run all steps at once? Copy-paste this:

sudo mkdir -p /etc/systemd/resolved.conf.d

sudo tee /etc/systemd/resolved.conf.d/dns.conf > /dev/null << 'EOF'
[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=1.0.0.1 8.8.4.4
DNSSEC=no
Cache=yes
DNSOverTLS=yes
EOF

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved

# Verify
resolvectl status
curl -I https://router.huggingface.co

# Restart your containers
docker restart <n8n-container-name>

Replace <n8n-container-name> with your actual container name (find it with docker ps | grep n8n).

Advanced: Verify DNS Encryption

Want proof your DNS is actually encrypted? Monitor your traffic:

sudo tcpdump -i eth0 -n "port 853 or port 53"

You should see traffic on port 853 (DNS over TLS), not port 53 (unencrypted DNS).

Press Ctrl + C to stop monitoring.

Security & Privacy Benefits

This setup gives you:

1. Encrypted DNS queries – Your ISP/Hostinger can’t see what domains you’re resolving
2. Bypass filtering – No more legitimate services blocked by overzealous filtering
3. Redundancy – If Cloudflare goes down, Google DNS takes over automatically
4. Performance – DNS caching speeds up repeated lookups significantly

Configuration Reference Table

Setting	Value	Purpose
DNS	1.1.1.1 8.8.8.8	Primary DNS servers
FallbackDNS	1.0.0.1 8.8.4.4	Backup DNS servers
DNSSEC	no	Prevent false failures
Cache	yes	Speed up lookups
DNSOverTLS	yes	Encrypt queries

Rollback Instructions

Need to revert to Hostinger’s default DNS?

sudo rm /etc/systemd/resolved.conf.d/dns.conf
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
resolvectl status

Final Thoughts

This DNS filtering issue cost me hours of debugging before I realized it wasn’t my code—it was the infrastructure. By taking control of DNS at the system level, you ensure your VPS behaves predictably, just like your local development environment.

Whether you’re running AI workflows, API integrations, or any service relying on external domains, this configuration gives you:

• ✅ Unfiltered DNS resolution
• ✅ Encrypted queries for privacy
• ✅ Better performance with caching
• ✅ Automatic failover between DNS providers
• ✅ Persistence across reboots

Now your Hostinger VPS has the same reliable DNS behavior as enterprise infrastructure.

---

Questions or issues? Drop a comment below or reach out on Twitter or LinkedIn.

Found this helpful? Share it with other VPS users hitting DNS roadblocks!

Related Posts:

• Self-Hosted Web Server on VPS With Multi-Domain Support
• Configure Windows Terminal for Peak Productivity

Updated: December 8, 2025