Implementing a Shared Sinkhole Zone in BIND — and What to Know About DNSSEC

Author: Rico Wu ｜ Topic: DNS Security & Infrastructure

1. Why Create a Sinkhole Zone?

When reviewing your DNS logs, you might often see queries like:

wpad.nuface.tw  IN  A
ns1.nuface.tw   IN  AAAA
blog.nuface.tw  IN  A

Some of these come from automated scanners or bots, and others are legitimate DNSSEC lookups.
However, domains like wpad (Web Proxy Auto Discovery) can sometimes be abused for malicious purposes — for example, through WPAD attacks that hijack proxy settings.

If you want to:

“Sinkhole” these suspicious subdomains to 0.0.0.0, preventing abuse,
and avoid maintaining separate zone files for each one,

you can use a shared sinkhole zone.

2. Shared Sinkhole Zone Configuration Example

1️⃣ Create a shared zone file

File path:

/etc/bind/zones/ext/db.sinkhole.common

Example content:

$TTL 300
@   IN  SOA ns1.nuface.tw. dns-admin.nuface.tw. (
        2025090301 ; serial
        3600       ; refresh
        900        ; retry
        1209600    ; expire
        300 )      ; minimum
    IN  NS  ns1.nuface.tw.

; === Sinkhole targets ===
@   IN  A    0.0.0.0
; Optional IPv6 reply
; @   IN  AAAA ::

*   IN  A    0.0.0.0
; *   IN  AAAA ::

Notes:

TTL 300s → quick to propagate any future changes.
A = 0.0.0.0 → directs all traffic to an invalid address (blackhole).
AAAA is optional:
- If omitted → IPv6 queries get NOERROR/NODATA and clients fall back to IPv4 quickly.
- If included (::) → IPv6-only clients will also fail immediately.

2️⃣ Reference it in `named.conf`

You can map multiple zones to the same file:

zone "wpad.nuface.tw" {
    type master;
    file "/etc/bind/zones/ext/db.sinkhole.common";
    allow-transfer { none; };
    allow-update { none; };
};

zone "bad.attacker.com" {
    type master;
    file "/etc/bind/zones/ext/db.sinkhole.common";
    allow-transfer { none; };
    allow-update { none; };
};

Now, any suspicious or abused subdomain can be quickly blackholed just by adding a new zone entry pointing to the same file.

3. DNSSEC Relationship and Precautions

DNSSEC works via a chain of trust:

. (root) → .tw → nuface.tw → wpad.nuface.tw

This trust chain is linked together using DS (Delegation Signer) records.

✅ If the parent domain (nuface.tw) has DNSSEC enabled

You may already have uploaded a DS record for nuface.tw at your registrar, allowing .tw to verify its signatures.

When you delegate wpad.nuface.tw as a separate zone, just do not add a DS record for it inside nuface.tw.

That means:

nuface.tw remains fully validated by DNSSEC.
wpad.nuface.tw is treated as unsigned.
The overall DNSSEC chain remains intact — no validation errors.

🛑 If you accidentally add a DS record

Resolvers will expect wpad.nuface.tw to be signed.
If it isn’t, those queries will be marked bogus, and validation will fail.

⚙ Recommended practice

Keep the sinkhole zone unsigned.
The parent zone only contains NS, no DS records.

4. IPv6 (AAAA) Response Strategy

Situation	Query Result	Client Behavior	Recommendation
No AAAA record	NOERROR / NODATA	Client falls back to IPv4 immediately	✅ Recommended
AAAA = ::	IPv6 clients try an invalid address, fail fast	Clear blackhole	Optional
AAAA = ::1	Loops back to localhost	May confuse apps	Not recommended

If your goal is simply to make IPv6 clients fall back to IPv4, omit the AAAA record.
If you want to make IPv6-only clients fail explicitly, add AAAA ::.

5. Recommended Defensive Strategy

Create a shared sinkhole zone file
/etc/bind/zones/ext/db.sinkhole.common
Add zone entries for suspicious subdomains zone "wpad.nuface.tw" { file "db.sinkhole.common"; };
Enable Response Rate Limiting (RRL)
to mitigate DNS flood or reflection attacks.
Keep DNSSEC signing only on the main domain (nuface.tw).
Don’t sign or upload DS records for sinkhole zones.
Monitor query logs (/var/log/bind/query.log)
and add new sinkholes dynamically for recurring unwanted queries.

6. Conclusion

By implementing a shared sinkhole zone, you can:

Quickly block malicious or unnecessary queries (e.g., WPAD lookups)
Keep zone management simple and consistent
Preserve the parent domain’s DNSSEC trust chain
Maintain safe behavior for both IPv4 and IPv6 clients

This approach provides a lightweight, scalable, and security-compliant way to strengthen your DNS infrastructure.
As domain traffic grows and exposure increases, proactive sinkhole management becomes an essential part of a modern DNS defense strategy.