Last updated: March 16, 2026

DNS-based ad blocking intercepts domain name resolution requests and blocks queries matching known advertising and tracking domains. When configured on your router, this approach provides network-wide protection without installing software on individual devices. GL-Inet travel routers running OpenWrt-based firmware support several DNS blocking solutions, with AdGuard Home being the most straightforward option for most users.

This guide covers deploying AdGuard Home directly on GL-Inet routers and running a separate Pi-hole instance for users who prefer dedicated hardware.

Table of Contents

Why DNS-Based Blocking Matters

Every device on your network makes DNS queries to resolve domain names into IP addresses. Advertisers and trackers host their content on separate domains, and blocking those domains at the DNS level prevents the requests from ever reaching your devices. This method is efficient because a single DNS block eliminates multiple tracking scripts, pixel tags, and advertisement resources simultaneously.

Travel routers present a unique use case. When connecting to hotel WiFi, public networks, or guest networks at Airbnb accommodations, your devices inherit whatever DNS configuration the network provides. Running your own DNS resolver on a travel router ensures consistent privacy protection regardless of the upstream network.

Prerequisites

This guide assumes you have a GL-Inet travel router such as the GL-MT1300 (Beryl), GL-SFT1200 (Slate), or GL-AX1800 (Flint). These devices run OpenWrt-based firmware and have sufficient storage for running DNS blocking software.

Verify your router’s available storage before proceeding:

df -h

AdGuard Home requires approximately 100MB of storage. If your device has limited space, consider using an USB drive for additional storage.

Step 1 - Install AdGuard Home on GL-Inet

GL-Inet routers running firmware version 3.x or later include application support through the web interface. The simplest installation method uses the built-in plugin system.

Method 1 - Web Interface Installation

  1. Access your router’s admin panel at 192.168.8.1 (default)
  2. Navigate to Applications → AdGuard Home
  3. Click Install and wait for the package to download
  4. Configure the listening interface (typically 0.0.0.0 for all interfaces)
  5. Set the upstream DNS servers (see configuration section below)

Method 2 - Command-Line Installation

For advanced users preferring terminal access:

Update package lists
opkg update

Install AdGuard Home
opkg install adguardhome

Configure initialization
/etc/init.d/adguardhome enable
/etc/init.d/adguardhome start

After installation, access the AdGuard Home web interface at 192.168.8.1:3000 (or the port you configured during setup).

Step 2 - Configure Upstream DNS Servers

AdGuard Home requires upstream DNS resolvers to forward legitimate queries. For privacy-conscious users, consider these options:

Cloudflare (Fast, No Logging)

1.1.1.1
1.0.0.1

Quad9 (Security-Focused)

9.9.9.9
149.112.112.112

NextDNS (Customizable)

45.90.28.0
45.90.30.0

To configure upstream DNS in AdGuard Home, navigate to Settings → DNS Settings and enter your chosen servers. For maximum privacy, use DNS-over-HTTPS by entering URLs such as:

https://dns.cloudflare.com/dns-query
https://dns.quad9.net/dns-query

Step 3 - Configure Client DNS

After setting up AdGuard Home, configure your router to use it for all DHCP-assigned DNS. In the GL-Inet web interface:

  1. Go to Network → DHCP and DNS
  2. In the DNS Forwarding section, enter 127.0.0.1#53
  3. Save and apply settings

This configuration ensures all devices connected to your router use the local DNS resolver for their queries.

Step 4 - Manage Block Lists

AdGuard Home ships with default block lists, but you can add more lists for better coverage. Navigate to Filters → DNS Blocklists and add these reputable sources:

Recommended Block Lists

https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
https://v.firebog.net/hosts/Prigent-Ads.txt

Update your block lists regularly by clicking Update in the web interface or running:

adguardhome --update

Step 5 - Set Up Pi-hole on Separate Hardware

For users seeking more filtering or running additional network services, Pi-hole provides a mature alternative. Install Pi-hole on a Raspberry Pi or virtual machine, then configure your GL-Inet router to use it.

Router Configuration

SSH into your GL-Inet router
ssh root@192.168.8.1

Navigate to network configuration
uci set dhcp.@dnsmasq[0].server='192.168.8.100#53'
uci set dhcp.@dnsmasq[0].noresolv='1'
uci commit dhcp
/etc/init.d/dnsmasq restart

Replace 192.168.8.100 with your Pi-hole’s IP address.

Testing Your Configuration

Verify DNS blocking is working by querying a known advertising domain:

nslookup doubleclick.net 192.168.8.1

A blocked response shows the NXDOMAIN status. In AdGuard Home, check the Query Log to see blocked requests in real-time.

Step 6 - Use Encrypted DNS

For complete privacy, configure your DNS resolver to use encrypted protocols. AdGuard Home supports DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS-over-QUIC.

In AdGuard Home, navigate to Settings → Encryption and enable:

This prevents upstream DNS providers from seeing your query history, complementing the blocking functionality.

Troubleshooting Common Issues

Devices Not Resolving Domains

If connected devices cannot resolve domains, check that the DNS forwarder is running:

/etc/init.d/adguardhome status

Restart if necessary:

/etc/init.d/adguardhome restart

Slow DNS Resolution

Slow resolution typically indicates upstream DNS issues. Switch to faster servers like Cloudflare or add multiple upstream providers for redundancy.

Block Lists Not Updating

Ensure your router has internet connectivity and can reach the block list URLs. Test with:

curl -I https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts

Step 7 - Practical Applications for Travel Routers

Deploying DNS blocking on a travel router provides consistent protection across all your devices. When staying at hotels or using public WiFi, connect your laptop, phone, and tablet to your personal travel router instead of the venue’s network. Your DNS queries remain private, and advertising domains get blocked regardless of the upstream network’s configuration.

This setup is particularly valuable for sensitive browsing or when working remotely. The router acts as a privacy firewall, filtering traffic at the DNS level before it reaches your devices.

Advanced Filter Management

As your block list grows, performance optimization becomes necessary. Managing hundreds of thousands of blocking rules requires strategy.

Filter List Performance Tuning

Check block list size and compilation time
Larger lists = more memory usage and lookup latency

Get rule count per list
curl -s https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt | wc -l

Benchmark DNS query time
Before/after adding lists
dig @192.168.8.1 google.com +stats

Expected overhead - <50ms per query with large filter lists

Very large filter lists (millions of rules) can introduce latency. Select lists balancing coverage and performance.

Custom Block List Creation

Create organization-specific block list
cat > custom_blocks.txt << EOF
Local organization blocklist (generated 2026-03-22)

Block Instagram tracking infrastructure
0.0.0.0 scontent-*.cdninstagram.com
0.0.0.0 instagram.com
0.0.0.0 *.instagram.com

Block TikTok environment
0.0.0.0 tiktok.com
0.0.0.0 *.tiktok.com
0.0.0.0 bytedance.com

Block specific Ad networks
0.0.0.0 googleadservices.com
0.0.0.0 doubleclick.net
EOF

Host this on your router or a Git repository

Custom lists let you block services specific to your organization or threat model without forcing entire lists on all users.

Multi-Device Configuration and Testing

DNS filtering effectiveness depends on proper device configuration. Test across your device environment:

Device-Specific DNS Settings

macOS - Set DNS at system level
networksetup -setdnsservers Wi-Fi 192.168.8.1

Linux - Using systemd-resolved
cat >> /etc/systemd/resolved.conf << EOF
DNS=192.168.8.1
FallbackDNS=1.1.1.1
EOF

Android - Private DNS (system-wide)
Settings → System → Advanced → Private DNS
Server hostname - router.local (or IP)

iOS - DNS over HTTPS configuration
Settings → Wi-Fi → Info icon → DNS → Configure DNS

Each platform’s DNS configuration differs. testing ensures all devices use your DNS filter.

Validation and Testing Tools

#!/bin/bash
DNS filtering validation script

echo "=== DNS Filter Validation ==="

Test that blocking is active
echo "1. Testing blocked domain:"
nslookup doubleclick.net 192.168.8.1 | grep -q "NXDOMAIN" && echo " Blocked" || echo " Not blocked"

Test that legitimate queries work
echo "2. Testing legitimate domain:"
nslookup google.com 192.168.8.1 | grep -q "has address" && echo " Resolves" || echo " Failed"

Check query log in AdGuard Home
curl -s http://192.168.8.1:3000/api/querylog | jq '.data | length'

Verify all connected devices are using router DNS
arp-scan -l | grep "192.168.8.1"

Regular testing confirms DNS blocking remains active across all devices.

Failover and Redundancy

Critical applications require DNS availability. Implement failover:

Dual DNS Resolver Setup

Configure secondary DNS resolver on different host
Primary - 192.168.8.1 (AdGuard on router)
Secondary - 192.168.8.100 (Pi-hole on Raspberry Pi)

Router DHCP configuration
uci set dhcp.@dnsmasq[0].server='192.168.8.1'
uci set dhcp.@dnsmasq[0].server='192.168.8.100'
uci commit dhcp
/etc/init.d/dnsmasq restart

If one DNS resolver fails, devices automatically use the other. This prevents complete loss of internet connectivity.

Health Check Monitoring

#!/bin/bash
Monitor DNS resolver health

check_dns() {
    local resolver=$1
    local test_domain="google.com"

    response_time=$(dig @$resolver $test_domain | grep "Query time" | awk '{print $4}')

    if [ -z "$response_time" ]; then
        echo "FAIL: $resolver"
        return 1
    else
        echo "OK: $resolver (${response_time}ms)"
        return 0
    fi
}

Monitor both resolvers
check_dns 192.168.8.1
check_dns 192.168.8.100

If primary fails, trigger failover
if ! check_dns 192.168.8.1; then
    echo "Primary resolver failed, switching to secondary"
    uci set dhcp.@dnsmasq[0].server='192.168.8.100'
    uci commit dhcp
    /etc/init.d/dnsmasq restart
fi

Automated monitoring detects resolver failures and triggers failover automatically.

Privacy-First DNS Configuration

Beyond blocking, optimize for privacy by choosing DNS upstreams carefully:

Upstream Provider Comparison

Provider Logging Speed Censorship Privacy
Cloudflare (1.1.1.1) Minimal Fast Low Medium
Quad9 No logs Medium High (blocks malware) High
NextDNS Yes (optional) Medium Customizable Medium
Mullvad No logs Medium None High
Privacy-friendly ISP Depends Varies Varies Depends

For maximum privacy, combine encrypted DNS (DoH/DoT) with no-log providers:

AdGuard Home upstream configuration for privacy
Use multiple upstreams for load balancing and redundancy

Quad9 with DoH
https://dns.quad9.net/dns-query

Mullvad with DoH
https://doh.mullvad.net/dns-query

Cloudflare with DoH (for fallback)
https://dns1.1.1.1.1.1.1.1:8443/dns-query

This setup routes all upstream queries through HTTPS, preventing your ISP from seeing your DNS requests while blocking ads locally.

Maintenance and Update Management

DNS blocking requires ongoing maintenance:

Automatic Block List Updates

Schedule AdGuard Home update checks
0 3 * * * /usr/bin/adguardhome --update-filters

Verify updates completed successfully
30 3 * * * /usr/bin/curl -s http://localhost:3000/api/status | jq '.rules_count'

Schedule updates during low-traffic hours to prevent query latency spikes.

Log Analysis and Optimization

Find top blocked domains
curl -s http://192.168.8.1:3000/api/querylog | \
  jq '.data[] | select(.status=="BLOCKED") | .question.name' | \
  sort | uniq -c | sort -rn | head -20

Analyzing what’s getting blocked helps you identify which filter lists are most effective and which might be overly aggressive.

This setup is particularly valuable for sensitive browsing or when working remotely. The router acts as a privacy firewall, filtering traffic at the DNS level before it reaches your devices.

Frequently Asked Questions

Who is this article written for?

This article is written for developers, technical professionals, and power users who want practical guidance. Whether you are evaluating options or implementing a solution, the information here focuses on real-world applicability rather than theoretical overviews.

How current is the information in this article?

We update articles regularly to reflect the latest changes. However, tools and platforms evolve quickly. Always verify specific feature availability and pricing directly on the official website before making purchasing decisions.

Are there free alternatives available?

Free alternatives exist for most tool categories, though they typically come with limitations on features, usage volume, or support. Open-source options can fill some gaps if you are willing to handle setup and maintenance yourself. Evaluate whether the time savings from a paid tool justify the cost for your situation.

How do I get started quickly?

Pick one tool from the options discussed and sign up for a free trial. Spend 30 minutes on a real task from your daily work rather than running through tutorials. Real usage reveals fit faster than feature comparisons.

What is the learning curve like?

Most tools discussed here can be used productively within a few hours. Mastering advanced features takes 1-2 weeks of regular use. Focus on the 20% of features that cover 80% of your needs first, then explore advanced capabilities as specific needs arise.

Related Articles