Disabling recursion causes browser hangs on clients with auto proxy config

Frank Stanek frank.stanek at est.fujitsu.com
Mon Jan 25 16:14:24 UTC 2010


Hello,

we want to set up a DNS server (bind-9.4.3-P3) for the internal LAN only.
However for security reasons we need to only allow a few trusted systems
to resolve external host names (ie names we are not authoritative for):
* Trusted systems can resolve names from our zones _and_ external names
* All other systems can only resolve names from our zones

The "untrusted" systems do not need to resolve external names since everything
is done via HTTP and SOCKS proxies.

We tried to do this by setting a forwarder and only enabling recursion for
an ACL that contains the trusted systems. This is what we came up with:

options {
    directory "/var/lib/named";
    dump-file "/var/log/named_dump.db";
    statistics-file "/var/log/named.stats";
    allow-query { 0/0; };
    allow-recursion { acl_recurseallow; };
    # allow-query-cache { none; }; # Is also allowed to acl_recurseallow by default
    # recursion no; # Is disabled for all but acl_recurseallow by default
    forward only;
    forwarders { 192.168.199.97; };    
    listen-on-v6 { none; };
    pid-file "/var/lib/named/var/run/named/named.pid";
};

include "/etc/named.d/zones.conf";

acl acl_recurseallow { 127.0.0.1; 127.0.0.0/8; 192.168.1.1; 192.168.1.2; 192.168.1.3; };

logging {
    # ...
};

Now there is a problem with web browsers on the "untrusted" systems. In
principle they could leave resolving to the HTTP proxy. When the proxy
server is configured manually into the browser, this is what they do and
everything works fine. I see no DNS queries in a packet capture.

However when we use a pac file or automatic proxy detection, the browsers
continually try to resolve the URL, receive "refused (recursion not available)",
then try again for up to many minutes depending on the browser and operating
system. This is what I get:
16:34:20.418896 IP 192.168.1.132.61298 > 192.168.1.1.53:  24052+ A? www.google.de. (31)
16:34:20.418945 IP 192.168.1.1.53 > 192.168.1.132.61298:  24052 Refused- 0/0/0 (31)
16:34:22.693730 IP 192.168.1.132.60804 > 192.168.1.1.53:  54268+ A? www.google.de. (31)
16:34:22.693914 IP 192.168.1.1.53 > 192.168.1.132.60804:  54268 Refused- 0/0/0 (31)
16:34:24.970093 IP 192.168.1.132.51107 > 192.168.1.1.53:  30500+ A? www.google.de. (31)
16:34:24.970218 IP 192.168.1.1.53 > 192.168.1.132.51107:  30500 Refused- 0/0/0 (31)
16:34:27.249565 IP 192.168.1.132.50621 > 192.168.1.1.53:  12951+ A? www.google.de. (31)
16:34:27.249764 IP 192.168.1.1.53 > 192.168.1.132.50621:  12951 Refused- 0/0/0 (31)
16:34:29.519069 IP 192.168.1.132.59523 > 192.168.1.1.53:  11653+ A? www.google.de. (31)
16:34:29.519178 IP 192.168.1.1.53 > 192.168.1.132.59523:  11653 Refused- 0/0/0 (31)

The browser usually freezes completely while this is happening.
This continues forever until the browser finally gives up trying and lets
the proxy resolve. It then renders the page. We have tried Firefox, IE, Safari and
some variant of Chrome and they all exhibit this behavior. We cannot find
a way to get rid of this problem.

Is there something fundamentally flawed with this configuration, ie is there
a better way to do this? We have tried using views but essentially we only
put recursion no; in one view and recursion yes; in the other which comes
down to the same thing. I have also inquired on the Firefox mailing list
about why the browsers behave this way (try to resolve forever when they
shouldn't need to) but have not received a reply yet.

I'd be glad for any insights.
Regards
Frank




More information about the bind-users mailing list