I'm a noob when it comes to DNS and BIND9, so forgive me if my description seems pedantic:
I connect to my workplace's network using VPN, which sets me up with the workplace DNS servers. Those servers manage the an internal namespace (visible only to users inside the VPN), with a specific domain name -- lets call it internal.net. Those servers also resolve queries to external addresses (e.g. Google) by forwarding them to some external DNS masters.
Without connecting to the VPN, my DNS lookups are performed via the router (192.168.0.1) which forwards to the ISP DNS server. What I would like to do is do is:
all lookups that don't belong to internal.net should be performed on my ISP's DNS server
all lookups belonging to internal.net are done on the VPN DNS servers
I was able to do this in the past with simply having the /etc/resolv.conf look like:
nameserver 192.168.0.1
search internal.net
nameserver 10.0.0.1 <== the addr of the VPN DNS
But the problem is that my ISP recently introduced the annoying DNS redirection "service" where they redirect all unresolved DNS queries to an ad-laden search page, so if I do a lookup on somehost.internal.net, my ISP's DNS will resolve it to their own search page, preventing the use of nameserver 10.0.0.1.
So I figured I could solve this problem by having a local BIND9 instance on my machine that does conditional forwarding based on domain name. The problem is BIND9 configuration seems intimidating and my trials with it have been unsuccessful. Can someone suggest to me a simple BIND9 configuration that achieves my goals?'
I agree you can solve this using BIND9. There is a simple one for such cases, but it's been years. But first, why can't you reverse the order so that the "local" nameserver is searched first?
Hmmm, not sure I understand your question, by local nameserver, do you mean the router's nameserver (192.168.0.1) or do you mean the BIND9 instance I would be setting up on my machine. If it is the former, then I think I already have it such that the local nameserver is searched first:
nameserver 192.168.0.1
search internal.net
nameserver 10.0.0.1 <== the addr of the VPN DNS
If it is the latter, then this is exactly why I came here, I don't know how to set up a local BIND9 server with conditional forwarding i.e. a DNS server that forwards all lookups under domain internal.net to 10.0.0.1 and forwards other queries to 192.168.0.1.
What happens if you set all requests to 10.0.0.1 and THEN 192.168.0.1 ? Is it the problem that requests take a long time if there is no such VPN established? This can be solved by routing tables I think.
I don't want to set all requests to 10.0.0.1 because that means all my DNS queries will go to my workplace first, and that makes me kind of uncomfortable, since my workplace can and do monitor my traffic.
My problem is that I want all my DNS queries to go my ISP's DNS servers first, then to my work place's. This was possible in the past, but my ISP implemented this annoying "assistive DNS feature" that takes all unresolved DNS queries and routes them to their own search page laden with queries.. that means that as far as my computer is concerned, the DNS query is *resolved* because it was routed to the IP of the ISP's search page. What this means is that:
1- I issue a DNS query for somehost.internal.net (this is a host inside the VPN, the VPN's DNS servers should be able to resolve it, but the ISP's DNS would not be able to resolve it)
2- my query is issued first to the ISP's DNS, which is unable to resolve it. Instead of telling me "sorry, we could not find a match for your DNS name" and let the computer ask alternative DNS servers (like the VPN's DNS), the ISP's DNS instead volunteers and routes me to their own search page.
3- my computer thinks the DNS query resolved fine, and doesn't try the other configured DNS servers.
You don't want to use a secondary nameserver in the system resolver as a form of conditional DNS lookups - the timeouts are too long, and that is not its intended purpose. The purpose is for one of having a backup for the situation when a primary is temporarily offline or unresponsive.
Setup bind with a forward zone for queries to internal.net that query your DNS server of choice. See: "A "forward zone" is a way to configure forwarding" in the BIND reference manual: BIND 9 Administrator Reference Manual