➡️ How to check a forwarder

A forwarder is a server you hand certain queries to instead of looking them up yourself. If you are not sure what a forward zone is, read forward zones first.

$ dig @9.9.9.9 example.isitdns.net A

Step 1: is the upstream actually answering?#

Skip your own server entirely and ask the upstream directly. If this fails, nothing else matters.

dig @192.0.2.53 internal.partner.example A

Replace 192.0.2.53 with your forwarder's IP and internal.partner.example with a name inside the forwarded zone.

What you want to see: status: NOERROR and an answer.

What each failure tells you:

The target has to be recursive, or authoritative for the names you forward (RFC 1034 §4.3.2).

Step 2: is your own server actually forwarding?#

Now ask your resolver for the same name:

dig @10.0.0.53 internal.partner.example A

Replace 10.0.0.53 with your own resolver's IP.

What you want to see: the same answer the upstream gave you in step 1, and importantly, no aa flag.

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, ...

Why no aa: your server did not answer from its own data, it passed the question along and relayed what came back. aa means "I own this zone" (RFC 1035 §4.1.1), and a forwarding server does not own the zone. On a working forward, aa is always absent, even when the upstream itself was authoritative, because the forwarding server strips it.

If you see aa=1, your zone classification is wrong. Your server thinks it owns this zone rather than forwarding it. You have accidentally created an auth zone. That is the bug.

If you get NXDOMAIN from your server but a real answer from the upstream, your forward zone is not matching. The query never got forwarded. Check the zone name for a typo, and remember you cannot use a wildcard: you forward internal.partner.example and everything underneath follows automatically. *.internal.partner.example is not a valid forward zone name.

Step 3: does it fail the way you want?#

When the forwarder is unreachable, your resolver does one of two things, and the default disagrees between implementations:

• BIND defaults to forward first: try the forwarder, and if that does not work, go resolve it from the public root servers yourself (BIND 9 ARM)
• Unbound defaults the other way: forward-first is no, so a failed forward stays failed (unbound.conf(5))

For an internal namespace, falling back is almost always wrong. If the forwarders for internal.partner.example are down, you want SERVFAIL, not a fallback query that finds nothing at the public roots and caches NXDOMAIN. That caches the outage: the name stays broken even after the forwarder comes back, until the negative-cache entry expires.

To test it: make the forwarder unreachable on purpose (block it at the firewall, or point the zone at an address with nothing on it), then ask your resolver for a name in that zone.

dig @10.0.0.53 internal.partner.example A

The fix is to set forwarders-only explicitly on every internal-namespace forward zone, even where the default already agrees, so the config states a decision rather than an accident. BIND: forward only;. Unbound: forward-first: no.

Step 4: is DNSSEC rejecting the answers?#

Two different failures hide here.

If the forwarded zone is signed, your resolver sets the DO bit on its upstream queries and expects RRSIG records back (RFC 4035 §3.2.1). A forwarder that strips them turns every answer into SERVFAIL.

dig @192.0.2.53 internal.partner.example A +dnssec

If the same query direct to the upstream returns RRSIG but through your resolver does not, something in between is stripping them.

If the forwarded zone is private and unsigned, like consul. or cluster.local., the failure is the opposite. The signed public DNS tree can prove those names do not exist, so a validating resolver judges the answers bogus and returns SERVFAIL. Carve that one name out of validation rather than turning validation off entirely:

• BIND: validate-except
• Unbound: domain-insecure

See dnssec and dnssec-troubleshooting for the full picture.

Quick reference#

See also#

• check-an-auth: the other end of the path
• Stub zones: one alternative to forwarding
• delegations: the other alternative to forwarding
• dot-doh: encrypting the hop to your forwarder