Self-Hosted DNS Redirect Servers: dnsmasq vs Knot DNS vs PowerDNS Recursor

DNS redirect servers intercept and rewrite DNS queries to route traffic to specific endpoints, enforce content policies, or implement custom routing rules. Whether you need to redirect internal services to private IPs, block malicious domains, or implement split-horizon DNS, the right DNS redirect server is a cornerstone of self-hosted infrastructure. This guide compares dnsmasq, Knot DNS, and PowerDNS Recursor for DNS redirect use cases.

Understanding DNS Redirect

A DNS redirect server sits between clients and upstream DNS resolvers, intercepting queries and returning custom responses based on configured rules. Common use cases include:

• Internal service discovery: Redirect app.internal.company.com to a private IP address
• Content filtering: Block or redirect known malicious domains to a sinkhole
• Geographic routing: Return different IPs based on the client’s network location
• Split-horizon DNS: Different responses for internal vs external clients
• Testing environments: Override production DNS for staging and development

dnsmasq DNS Redirect Configuration

dnsmasq is the most widely used lightweight DNS redirect server. It combines DNS caching, DHCP, and TFTP in a single lightweight binary (~100KB).

Basic Redirect Rules

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# /etc/dnsmasq.conf

# Upstream DNS servers
server=8.8.8.8
server=8.8.4.4
server=1.1.1.1

# Redirect specific domains to custom IPs
address=/app.internal.company.com/10.0.1.50
address=/db.internal.company.com/10.0.1.100
address=/api.staging.company.com/10.0.2.25

# Wildcard redirect - all subdomains
address=/.dev.company.com/10.0.3.1

# Sinkhole known malicious domains
address=/tracker.malware.com/0.0.0.0
address=/ads.adnetwork.com/0.0.0.0

# Load redirect rules from an external file
addn-hosts=/etc/dnsmasq.custom.hosts

Advanced dnsmasq Redirect Setup

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# /etc/dnsmasq.conf - production configuration

# Listen on specific interfaces
interface=eth0
listen-address=127.0.0.1
listen-address=10.0.0.5

# Don't forward plain names (no dots)
domain-needed

# Never forward addresses in non-routed spaces
bogus-priv

# Cache size
cache-size=10000

# Log queries for debugging (disable in production)
# log-queries

# DNSSEC validation
dnssec
dnssec-check-unsigned

# DHCP integration (optional)
dhcp-range=10.0.0.100,10.0.0.200,24h

Docker Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

version: "3.8"
services:
  dnsmasq:
    image: jpillora/dnsmasq:latest
    container_name: dnsmasq-redirect
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    volumes:
      - ./dnsmasq.conf:/etc/dnsmasq.conf:ro
      - ./dnsmasq.custom.hosts:/etc/dnsmasq.custom.hosts:ro
    ports:
      - "53:53/tcp"
      - "53:53/udp"
    networks:
      - dns-net
    dns:
      - 127.0.0.1

networks:
  dns-net:
    driver: bridge

Knot DNS DNS Redirect Configuration

Knot DNS (maintained by CZ.NIC) is a high-performance authoritative DNS server with powerful redirect capabilities through its response policy zones (RPZ) and module system.

Knot DNS Redirect with Response Policy Zones

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# /etc/knot/knot.yml

server:
  listen: 0.0.0.0@53
  user: knot:knot

template:
  - id: default
    storage: /var/lib/knot
    file: "%s.zone"
    dnssec-signing: on

zone:
  - domain: internal.company.com
    file: internal.company.com.zone

# Response Policy Zone for redirect rules
zone:
  - domain: redirect.rpz
    file: redirect.rpz.zone
    rpz:
      - policy: passthru

RPZ Zone File

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

; redirect.rpz.zone
$TTL 300
@ SOA ns1.internal.company.com. admin.internal.company.com. (
    2026010101 ; serial
    3600       ; refresh
    900        ; retry
    604800     ; expire
    86400      ; minimum TTL
)

; NS record
@ NS ns1.internal.company.com.

; Redirect rules (RPZ format)
; CNAME redirect - redirect to custom target
malware.example.com CNAME .
*.tracker.adnetwork.com CNAME .

; A record override
internal-app.company.com A 10.0.1.50

; Wildcard redirect
*.dev.company.com A 10.0.3.1

Knot DNS Docker Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

version: "3.8"
services:
  knot-dns:
    image: czerwonk/knot-dns:latest
    container_name: knot-dns-redirect
    restart: unless-stopped
    volumes:
      - ./knot.yml:/etc/knot/knot.yml:ro
      - ./zones:/var/lib/knot/zones
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "53:53/tcp"
    environment:
      - KNOT_LOG=info

PowerDNS Recursor DNS Redirect Configuration

PowerDNS Recursor is a high-performance, security-focused DNS recursor with extensive scripting capabilities through Lua.

PowerDNS Recursor Redirect with Lua

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

-- /etc/pdns/recursor.lua

-- Redirect specific domains
function preresolve(dq)
    -- Internal service redirect
    if dq.qname:equal("app.internal.company.com") then
        dq:addAnswer(dq.qtype, "10.0.1.50")
        return true
    end

    -- Wildcard redirect for dev environment
    if dq.qname:toString():match("%.dev%.company%.com%.?$") then
        dq:addAnswer(dq.qtype, "10.0.3.1")
        return true
    end

    -- Block malicious domains
    local blocked = {
        "tracker.malware.com",
        "ads.adnetwork.com",
        "phishing.evil.com"
    }
    for _, domain in ipairs(blocked) do
        if dq.qname:equal(domain) then
            dq:addAnswer(dq.qtype, "0.0.0.0")
            dq.rcode = 0 -- No error
            return true
        end
    end

    return false -- Let normal resolution proceed
end

PowerDNS Recursor Configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# /etc/pdns/recursor.conf

# Listen addresses
local-address=0.0.0.0
local-port=53

# Upstream forwarders
forward-zones=.=8.8.8.8;8.8.4.4;1.1.1.1

# Lua script for redirect rules
lua-dns-script=/etc/pdns/recursor.lua

# Security settings
dnssec=validate
serve-rfc1918=no

# Performance tuning
threads=4
max-cache-entries=1000000
max-negative-ttl=300
max-cache-ttl=86400

# Logging
loglevel=4
quiet=yes

PowerDNS Recursor Docker Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

version: "3.8"
services:
  pdns-recursor:
    image: pschiffe/pdns-recursor:latest
    container_name: pdns-recursor-redirect
    restart: unless-stopped
    volumes:
      - ./recursor.conf:/etc/pdns-recursor/recursor.conf:ro
      - ./recursor.lua:/etc/pdns-recursor/recursor.lua:ro
    ports:
      - "53:53/tcp"
      - "53:53/udp"
    environment:
      - TZ=UTC

Comparison Table

Choosing the Right DNS Redirect Server

Use dnsmasq When:

• You need a lightweight, easy-to-configure solution
• You also need DHCP server functionality
• Your redirect rules are simple (static address mappings)
• You’re running on resource-constrained hardware (embedded, Raspberry Pi)

Use Knot DNS When:

• You need authoritative DNS with redirect capabilities
• You want RPZ-based policy management
• You prefer zone-file configuration over scripting
• You’re already running Knot DNS as your authoritative server

Use PowerDNS Recursor When:

• You need complex redirect logic (Lua scripting)
• You have dynamic redirect rules based on query context
• You need high-performance multi-threaded DNS resolution
• You’re managing redirect rules for hundreds or thousands of domains

Why Self-Host Your DNS Redirect Server?

Running your own DNS redirect server gives you complete control over how DNS queries are resolved within your network. External DNS services like Google DNS or Cloudflare cannot provide custom redirect rules for your internal domains, and they don’t offer the granular control needed for security filtering or split-horizon DNS.

For network infrastructure, see our guides on DNS load balancing and DNS rate limiting.

Security Best Practices for DNS Redirect Servers

When deploying DNS redirect infrastructure, follow these security guidelines to prevent misconfigurations from becoming attack vectors:

Restrict query sources: Never allow open recursion on public-facing DNS redirect servers. Use ACLs in dnsmasq (acl=), PowerDNS Recursor (allow-from=), or Knot DNS (acl) to limit which clients can query your servers. Open resolvers are routinely abused for DNS amplification attacks.

Enable DNSSEC validation: All three servers support DNSSEC validation. This prevents DNS spoofing attacks where an attacker injects false redirect responses. With dnssec=validate in PowerDNS Recursor or dnssec in dnsmasq, the server validates signatures on all responses before returning them to clients.

Monitor redirect rule changes: Track modifications to your redirect rule files using version control (Git) and automated change detection. Unauthorized changes to DNS redirect rules can redirect internal traffic to attacker-controlled servers, leading to credential theft or data exfiltration.

Test redirect rules in staging: Before deploying redirect rules to production, test them against a staging DNS server. A misconfigured redirect rule can take down internal services by sending legitimate traffic to the wrong destination.

Rate-limit external queries: If your DNS redirect server handles queries from untrusted networks, implement rate limiting to prevent abuse. PowerDNS Recursor supports max-cache-entries and query rate limiting, while dnsmasq can be paired with iptables nftables rules for per-client rate limiting.

FAQ

What is a DNS redirect server?

A DNS redirect server intercepts DNS queries and returns custom responses instead of forwarding them to upstream resolvers. It is commonly used for internal service discovery, content filtering, split-horizon DNS, and redirecting traffic to specific endpoints.

How does dnsmasq redirect DNS queries?

dnsmasq uses the address=/domain/ip directive to redirect any query for a specific domain (or all subdomains) to a custom IP address. For example, address=/.dev.company.com/10.0.3.1 redirects all *.dev.company.com queries to 10.0.3.1.

What is DNS RPZ (Response Policy Zone)?

RPZ is a DNS mechanism that allows administrators to define policy rules in a zone file format. When a query matches an RPZ rule, the DNS server returns a custom response instead of the normal resolution result. Knot DNS and PowerDNS Recursor both support RPZ.

Can I use PowerDNS Recursor with dynamic redirect rules?

Yes. PowerDNS Recursor supports Lua scripting through the lua-dns-script directive. You can write custom logic in Lua to evaluate query attributes (client IP, domain name, query type) and return dynamic responses.

Is dnsmasq suitable for production DNS redirect?

Yes, for small to medium deployments. dnsmasq is used in millions of routers and embedded devices worldwide. For large-scale enterprise deployments with thousands of redirect rules, PowerDNS Recursor or Knot DNS may be more appropriate.

How do I test DNS redirect rules?

Use dig or nslookup to query your DNS redirect server directly:

1
2

dig @10.0.0.5 app.internal.company.com
nslookup app.internal.company.com 10.0.0.5

Verify that the returned IP matches your configured redirect rule.