Cannot resolve custom domains when VPN is up

Question

I just upgraded to 12.04 from 11.10, and now I can't resolve custom domains over my VPN (e.g. *.dev.local). It worked splendid before the upgrade.

Both my /etc/resolv.conf and route -n looks exactly as it did before the update.

I am using OpenVPN and it connects without problem.

output from ping

$ ping example.dev.local
ping: unknown host example.dev.local

resolv.conf

nameserver 172.16.1.4
nameserver 172.16.1.5
nameserver 10.4.180.250
search office.local corp.local

route -n

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.4.180.250    0.0.0.0         UG    0      0        0 eth0
10.4.180.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.61.80.0      172.28.0.254    255.255.255.128 UG    0      0        0 tap0
10.61.80.128    172.28.0.249    255.255.255.128 UG    0      0        0 tap0
10.200.2.126    172.28.0.249    255.255.255.255 UGH   0      0        0 tap0
81.92.65.52     172.28.0.249    255.255.255.255 UGH   0      0        0 tap0
81.92.71.128    172.28.0.249    255.255.255.192 UG    0      0        0 tap0
81.92.72.128    172.28.0.254    255.255.255.224 UG    0      0        0 tap0
81.92.72.160    172.28.0.249    255.255.255.224 UG    0      0        0 tap0
172.16.0.0      172.28.0.1      255.255.248.0   UG    0      0        0 tap0
172.28.0.0      0.0.0.0         255.255.254.0   U     0      0        0 tap0

Snippet from /etc/dhcp3/dhclient.conf (22-25 is original before upgrade, previously had to remove domain-name-servers for some reason I've forgotten about)

 22 #request subnet-mask, broadcast-address, time-offset, routers,
 23 #       domain-name, domain-name-servers, domain-search, host-name,
 24 #       netbios-name-servers, netbios-scope, interface-mtu,
 25 #       rfc3442-classless-static-routes, ntp-servers;
 26 
 27 prepend domain-name-servers 192.168.1.1;
 28 request subnet-mask, broadcast-address, time-offset, routers,
 29         domain-name, domain-search, host-name,
 30         netbios-name-servers, netbios-scope, interface-mtu,
 31         rfc3442-classless-static-routes, ntp-servers;

Any help would be greatly appreciated.

Edit: I can reach the hosts by IP, it's just the resolving that does not work.

Answer 1

Maybe look at /etc/nsswitch.conf. I had a problem with Ubuntu not acknowledging names from my local dns server regardless of the /etc/resolve.conf setting. Slackware worked fine so I modified mine to be a little closer to Slackware's version:

hosts:          files dns mdns4_minimal mdns4 [NOTFOUND=return]

I think I had to move the dns and mdns4 stuff... maybe there was an asterisk (*) that prevented further lookups.

Answer 2

The problem is that the VPN uses local as its top-level domain which is also used by avahi for mdns.

Avahi's documentation

http://avahi.org/wiki/AvahiAndUnicastDotLocal

says

If you come across a network where .local is a unicast
DNS domain, please contact the local administrator
and ask him to move his DNS zone to a different domain.
If this is not possible, we recommend not to use Avahi
in such a network at all.

Answer 3

It is highly likely that when you are on VPN your nameserver and/or search domains are different. If you use nslookup for the custom DNS name you are trying to reach you'll need to see the nameserver that you are querying. If the address is different you are trying to resolve the name on a server where it is not listed.

for example...

munich:~ jeremy$ nslookup bangkok
Server:     192.168.1.2
Address:    192.168.1.2#53

Name:   bangkok.home.com
Address: 192.168.1.5

Bangkok is a custom DNS name for a box in my home network. Were I to connect to my companies VPN I would hit their nameserver first so I can revolve their custom names such as svn and wiki. We have several namesevers at work, each with their own domain like foo.work.com and bar.work.com and work.com. If I have bar.work.com listed as my first domain and I try to reach svn.foo.work.com with only svn the search will fail to resolve to an ip address because it will look for svn.bar.work.com.