On 4/11/2011 7:18 AM, kapetr wrote:
Hello,
interesting ...
----- PŮVODNÍ ZPRÁVA -----
Od: "Stacey Marshall"<stacey.marsh...@gmail.com>
Komu: "kapetr"<kap...@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@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@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@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@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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
