BIND9 fails resolving after connecting to VPN

[Kevin Darcy]

On 4/11/2011 7:18 AM, kapetr wrote:
> Hello,
>
> interesting ...
>
> ----- PŮVODNÍ ZPRÁVA -----
> Od: "Stacey Marshall"<stacey.marshall at gmail.com>
> Komu: "kapetr"<kapetr at mizera.cz>
> Předmět: Re: BIND9 fails resolving after connecting to VPN
> Datum: 9.4.2011 - 22:50:44
>
>> I' wondering if the network your attaching to via
>> VPN allows direct DNS
>> lookups?
>>
>> I know of networks where the provided servers have
>> firewall rules that allow
>> them to make queries but other servers are not.
>>
>> You could test this theory by trying to connect to
>> a root server with dig
>> when connected to VPN.  For example:
>>
>> $ dig @h.root-servers.net. www.seznam.cz
>>
>> Regards,  Stace
>
> Why should VPN provider filter (disable) direct queries and allow
> only recursive queries ?
>
> The results are (for me) surprising:
>
> 1. before VPN: my (127.0.0.1) and ISPs servers work OK and:
> ********************************************************************
>
> hugo at duron650:~$ dig @h.root-servers.net. www.seznam.cz
>
> ;<<>>  DiG 9.7.1-P2<<>>  @h.root-servers.net. www.seznam.cz
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20035
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 10
> ;; WARNING: recursion requested but not available
>
> ;; QUESTION SECTION:
> ;www.seznam.cz.			IN	A
>
> ;; AUTHORITY SECTION:
> cz.			172800	IN	NS	a.ns.nic.cz.
> cz.			172800	IN	NS	b.ns.nic.cz.
> cz.			172800	IN	NS	c.ns.nic.cz.
> cz.			172800	IN	NS	d.ns.nic.cz.
> cz.			172800	IN	NS	f.ns.nic.cz.
>
> ;; ADDITIONAL SECTION:
> a.ns.nic.cz.		172800	IN	A	194.0.12.1
> b.ns.nic.cz.		172800	IN	A	194.0.13.1
> c.ns.nic.cz.		172800	IN	A	194.0.14.1
> d.ns.nic.cz.		172800	IN	A	193.29.206.1
> f.ns.nic.cz.		172800	IN	A	193.171.255.48
> a.ns.nic.cz.		172800	IN	AAAA	2001:678:f::1
> b.ns.nic.cz.		172800	IN	AAAA	2001:678:10::1
> c.ns.nic.cz.		172800	IN	AAAA	2001:678:11::1
> d.ns.nic.cz.		172800	IN	AAAA	2001:678:1::1
> f.ns.nic.cz.		172800	IN	AAAA	2001:628:453:420::48
>
> ;; Query time: 144 msec
> ;; SERVER: 128.63.2.53#53(128.63.2.53)
> ;; WHEN: Mon Apr 11 12:56:18 2011
> ;; MSG SIZE  rcvd: 338
>
> hugo at duron650:~$
>
> 2. after  VPN up:
> ****************************************************************
> - my (127.0.0.1) fails again - "connection timed out; no servers
> could be reached"
> - ISPs server OK again - I get normal "A" answer
> - DNS root server - by name (IP get from ISPs server) or by IP
> gives:
> hugo at duron650:~$ dig @h.root-servers.net. www.seznam.cz
>
> ;<<>>  DiG 9.7.1-P2<<>>  @h.root-servers.net. www.seznam.cz
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2758
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;www.seznam.cz.			IN	A
>
> ;; ANSWER SECTION:
> www.seznam.cz.		203	IN	A	77.75.72.3
>
> ;; Query time: 67 msec
> ;; SERVER: 128.63.2.53#53(128.63.2.53)
> ;; WHEN: Mon Apr 11 12:58:52 2011
> ;; MSG SIZE  rcvd: 47
>
> hugo at duron650:~$
> *************************************************
>
> So why the h.root-servers.net == 128.63.2.53 in case 2 (over VPN)
> gives the recursive answer ?
>
> Do You thing, that this VPN provider
> - blocks direct (not recursive) DNS questions and
> - manipulates recursive queries ? [catch them, make query itself and
> answers with manipulated server IP]
>
> ???
None of your queries were non-recursive (you'd need "+norec" on your dig 
command line for that), so I wouldn't jump to the conclusion that 
non-recursive queries are being blocked.

What's more likely happening is that *all* of your queries are being 
transparently redirected to a recursive resolver. Although, I'd be 
curious to see what responses you get if you actually generate 
non-recursive queries (with the "+norec").

If it's redirecting non-recursive queries to some caching nameserver, 
then that probably explains why named goes stupid when the VPN is up, 
since it won't be able to use the non-authoritative answers it sees.

One thing that will break horribly with this transparent query 
redirection is any form of shared-key authentication (e.g. TSIG). 
DNSSEC, on the other hand, is end-to-end, so offhand I think it'll be 
unaffected.

                                                                         
                                                                         
                                                 - Kevin