Howto Redirect unresolved DNS queries to a host?

Solution 1:

NXDOMAIN hijacking is not possible with BIND. This can be done using the PowerDNS Recursor lua scripting. The Ubuntu 10.04 repositories have a package for PowerDNS Recursor which supports the lua scripting functionality.

As other have stated there can be significant consequences to NXDOMIAN hijacking and you understand the potential issues before implementing.

Solution 2:

The forwarders option must either be in an option block or a zone block. From the short extract I cannot see whether either of these conditions is fulfilled.

And, obviously, a DNS service has to run on the forwarder, which can either resolve the query or forward to another DNS server. Plus, that DNS server must be configured to answer queries from the first DNS server. What happens if you open a shell to the Ubuntu box and run

dig what.ever.domain @10.0.1.2

If this times out, then 10.0.1.2 isn't answering the queries from your Ubuntu box.

Solution 3:

If by "resolve all unresolved DNS queries to a given host" you mean DNS hijacking (whereby the server responds with a record pointing to that host when it would otherwise reply with an NXDOMAIN status to indicate the lookup failed) then I do not think that bind supports this out of the box. ISPs that hijack what should be NXDOAIN responses this way presumably use something else or have a custom version patched to add the feature.

NXDOMAIN hijacking is generally frowned upon as it can break a number of things. See http://en.wikipedia.org/wiki/DNS_hijacking for more detail.

The forwarders directive tells bind where to look when performing recursive queries - it names other DNS server(s) that should be queries if this server is asked for a domain it doesn't have records for locally. It does not control behaviour when all lookups (local and via other hosts) fail to find a matching record.

Solution 4:

Please don't do this, it has massive consequences. I understand that it's only for your internal network; however, it will still break many things. Keep in mind that you're returning an IP for a live server, and as such many applications and services may think that something they're trying to access is really available when it's not. While this may seem trivial, consider a situation where an application is attempting to send data to a remote server and sees that it's up from behind your network; however, in reality the server has gone offline. The user begins to see unrelated (if any!) error messages about the program not working and calls you and / or your coworkers for support. Do you really want to troubleshoot that?

Here's ICANN's stance on it:

ICANN strongly discourages the use of DNS redirection, wildcards, synthesized responses and any other form of NXDOMAIN substitution in existing gTLDs, ccTLDs and any other level in the DNS tree for registry-class domain names.