Re: Disabling recursion causes browser hangs on clients with auto proxy config
On Mon, Jan 25, 2010 at 07:12:50PM +0100, Frank Stanek wrote: > Thank you for your reply. > > > the browser apparently needs to resolve the IP before itdesides whether to > > use proxy or not. It may be a problem of the .pac file. > > I have also suspected the pac file some time ago. We have tried > to use !(isResolvable(host)) to try and make the browser give up First problem! ... > || isInNet(host, "192.168.1.0", "255.255.255.0") ... Another! The last tip in the old Netscape "Navigator Proxy Auto-Config File Format": * Use of isInNet(), isResolvable() and dnsResolve() functions should be carefully considered, as they require DNS server to be consulted (whereas all other autoconfig related functions are mere string matching functions). If a proxy is used, the proxy will perform its own DNS lookup which would double the impact on the DNS server. Most of the time these functions are not necessary to achieve the desired result. http://web.archive.org/web/20060424005037/wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: is it possible to dynamically update an RRSIG record?
Jack Tavares wrote: > Looking at the code for libbind, specifically > res_nmkupdate, > there is no case statement for RRSIG records. > > In this case, I was trying to update the TTL. > Is that not allowed intentionally? I think so. The TTL of a RRSIG RR *MUST* match the TTL value of the RRset it covers. Hugo ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AW: Disabling recursion causes browser hangs on clients with auto proxy config
On 1/25/2010 2:47 PM, Niall O'Reilly wrote:
Frank Stanek wrote:
I'm sorry but I don't quite understand what you mean. Could you
please elaborate this on the basis of this excerpt from our pac
file?
function FindProxyForURL(url, host)
{
var proxy1 = "PROXY 192.168.240.29:8080";
var proxy2 = "PROXY 172.16.1.30:8080";
if ( dnsDomainIs(host, ".intern")
|| shExpMatch(url, "*//localhost*")
|| shExpMatch(url, "*//127*")
So far so good: you've tried to match part of the text of the
URL against each of those rules.
|| isInNet(host, "192.168.1.0", "255.255.255.0")
// more lines with subnets
Before applying this rule, your browser has to convert the
domain name given in the URL to an address, in order to check
whether the address belongs to the subnet. Since you've
chosen to block recursive name resolution, this rule will fail
except for domain names for which your name server is
authoritative; likewise for "more lines with subnets".
Good analysis.
More generally,
1) isInNet() or any other function which causes constant DNS lookups is
bad from a DNS infrastructure point of view, and can run into caching
complications
2) any form of access control which involves turning off recursion for
particular clients is iffy, since stub resolvers don't react
consistently to unexpected lookup results such as referrals. It is
generally better to give a definitive REFUSED response, in order to make
one's intent clear. In BIND terms, that would be "allow-query" rather
than "allow-recursion".
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
is it possible to dynamically update an RRSIG record?
Looking at the code for libbind, specifically res_nmkupdate, there is no case statement for RRSIG records. In this case, I was trying to update the TTL. Is that not allowed intentionally? Thank you -- Jack Tavares "How many more can we sell with this button?" ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AW: Disabling recursion causes browser hangs on clients with auto proxy config
Frank Stanek wrote:
I'm sorry but I don't quite understand what you mean. Could you
please elaborate this on the basis of this excerpt from our pac
file?
function FindProxyForURL(url, host)
{
var proxy1 = "PROXY 192.168.240.29:8080";
var proxy2 = "PROXY 172.16.1.30:8080";
if ( dnsDomainIs(host, ".intern")
|| shExpMatch(url, "*//localhost*")
|| shExpMatch(url, "*//127*")
So far so good: you've tried to match part of the text of the
URL against each of those rules.
|| isInNet(host, "192.168.1.0", "255.255.255.0")
// more lines with subnets
Before applying this rule, your browser has to convert the
domain name given in the URL to an address, in order to check
whether the address belongs to the subnet. Since you've
chosen to block recursive name resolution, this rule will fail
except for domain names for which your name server is
authoritative; likewise for "more lines with subnets".
Best regards,
Niall O'Reilly
University College Dublin IT Services
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
AW: Disabling recursion causes browser hangs on clients with auto proxy config
Thank you for your reply.
> the browser apparently needs to resolve the IP before itdesides whether to
> use proxy or not. It may be a problem of the .pac file.
I have also suspected the pac file some time ago. We have tried
to use !(isResolvable(host)) to try and make the browser give up
faster, with mixed results. In general this made things a little
faster but we still saw between 2 and 12 tries before the browser
gave up trying to resolve. This was still very noticable on sites
with lots of external content.
> check the .pac content. If you use IP's in it, they are probably going to
> get resolved from given hostname.
I'm sorry but I don't quite understand what you mean. Could you
please elaborate this on the basis of this excerpt from our pac
file?
function FindProxyForURL(url, host)
{
var proxy1 = "PROXY 192.168.240.29:8080";
var proxy2 = "PROXY 172.16.1.30:8080";
if ( dnsDomainIs(host, ".intern")
|| shExpMatch(url, "*//localhost*")
|| shExpMatch(url, "*//127*")
|| isInNet(host, "192.168.1.0", "255.255.255.0")
// more lines with subnets
|| isPlainHostName(host)
)
{
return "DIRECT";
// Internal
}
else if ( shExpMatch (host, "int1.fujitsu.co.jp")
|| shExpMatch(host, "int2.fujitsu.co.jp")
// more lines with WAN domains
)
{
return proxy2;
// WAN
}
else
{
return proxy1;
// Internet
}
Basically what we do is return one proxy for WAN sites (depending on the
domain name), another proxy for normal internet traffic or DIRECT for local
sites.
Regards
Frank
- Originalnachricht -
Von: "Matus UHLAR - fantomas"
Gesendet: Mon, 25.1.2010 17:56
An: bind-users@lists.isc.org
Betreff: Re: Disabling recursion causes browser hangs on clients with auto
proxy config
On 25.01.10 17:14, Frank Stanek wrote:
> 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
> However when we use a pac file or automatic proxy detection, the browsers
> continually try to resolve the URL, receive "refused (recursion not
> available)",
the browser apparently needs to resolve the IP before itdesides whether to
use proxy or not. It may be a problem of the .pac file.
> 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.
check the .pac content. If you use IP's in it, they are probably going to
get resolved from given hostname.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC Bogus NXDOMAIN survives authenticating RR
On 2009-12-10 08:49, Niobos wrote: Thank you very much for your help; I'll forward the conversation to the bug-tracking list. Since these are my first DNSSEC experiments, I just wanted to make sure that it wasn't a problem with my understanding of the concept. Niobos This has been confirmed as a security-bug by ISC a while back. Due to the potential exploit, they asked me not to release this information until the fix was released. BIND 9.6.1-P3 now contains the fix: 827. [security] Bogus NXDOMAIN could be cached as if valid. [RT #20712] I can confirm that this version behaves as expected: keeps returning SERVFAIL on bogus NXDOMAIN response. Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disabling recursion causes browser hangs on clients with auto proxy config
On 25.01.10 17:14, Frank Stanek wrote: > 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 > However when we use a pac file or automatic proxy detection, the browsers > continually try to resolve the URL, receive "refused (recursion not > available)", the browser apparently needs to resolve the IP before itdesides whether to use proxy or not. It may be a problem of the .pac file. > 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. check the .pac content. If you use IP's in it, they are probably going to get resolved from given hostname. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Disabling recursion causes browser hangs on clients with auto proxy config
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
update failed: SERVFAIL
Hi, I have a problem about the DDNS ,When I nsupdated the master dns server under with dnssec,but it failed as following: *r...@root:/var/named/chroot/etc# nsupdate -d > server 192.168.225.130 5353 > update add test.net 900 A 5.5.5.5 > Reply from SOA query: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32603 ;; flags: qr aa ; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;test.net.IN SOA ;; AUTHORITY SECTION: net. 300 IN SOA dns.net. dns.net. 2010011806 10800 60 604800 10800 Found zone name: net The master is: dns.net Sending update to 192.168.225.130#5353 Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 30960 ;; flags: ; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 0 ;; UPDATE SECTION: dns.net. 900 IN A 5.5.5.5 Reply from update query: ;; ->>HEADER<<- opcode: UPDATE, status: SERVFAIL, id: 30960 ;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 > * But when i nsupdated the master dns server without dnssec, it succeed. So I don't know why? -- - Xudong email：xudon...@gmail.com Beijing,China - ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question!
Yes, of course, at least they needs to know nameservers for that zone. http://ripe.net/rs/reverse/reverse_howto.html 2010/1/25 Alans > I’m new with this ISP, but I don’t think they requested that. > > Your point is RIPE won’t give delegations without request, right? > > > > Regards, > > Alans > > > > *From:* bind-users-bounces+batpower83=yahoo.co...@lists.isc.org [mailto: > bind-users-bounces+batpower83 = > yahoo.co...@lists.isc.org] *On Behalf Of *Peter Andreev > *Sent:* Monday, January 25, 2010 12:15 PM > *To:* BIND Users Mailing List > *Subject:* Re: Delegation question! > > > > Have you requested delegation? > > 2010/1/25 Alans > > Hello, > > When I check our dns ip from external server for ptr records it shows > nothing but > 93.in-addr.arpa.6562IN SOA ns-pri.ripe.net. > dns-help.ripe.net. 2010012534 3600 7200 1209600 7200 > We bought 93.x.x.0/x from RIPE, does that mean that RIPE didn't delegate > 93.x.x.0/x to us? > > Regards, > Alans > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > > > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Delegation question!
I'm new with this ISP, but I don't think they requested that. Your point is RIPE won't give delegations without request, right? Regards, Alans From: bind-users-bounces+batpower83=yahoo.co...@lists.isc.org [mailto:bind-users-bounces+batpower83=yahoo.co...@lists.isc.org] On Behalf Of Peter Andreev Sent: Monday, January 25, 2010 12:15 PM To: BIND Users Mailing List Subject: Re: Delegation question! Have you requested delegation? 2010/1/25 Alans Hello, When I check our dns ip from external server for ptr records it shows nothing but 93.in-addr.arpa.6562IN SOA ns-pri.ripe.net. dns-help.ripe.net. 2010012534 3600 7200 1209600 7200 We bought 93.x.x.0/x from RIPE, does that mean that RIPE didn't delegate 93.x.x.0/x to us? Regards, Alans ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question!
Have you requested delegation? 2010/1/25 Alans > Hello, > > When I check our dns ip from external server for ptr records it shows > nothing but > 93.in-addr.arpa.6562IN SOA ns-pri.ripe.net. > dns-help.ripe.net. 2010012534 3600 7200 1209600 7200 > We bought 93.x.x.0/x from RIPE, does that mean that RIPE didn't delegate > 93.x.x.0/x to us? > > Regards, > Alans > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Delegation question!
Hello, When I check our dns ip from external server for ptr records it shows nothing but 93.in-addr.arpa.6562IN SOA ns-pri.ripe.net. dns-help.ripe.net. 2010012534 3600 7200 1209600 7200 We bought 93.x.x.0/x from RIPE, does that mean that RIPE didn't delegate 93.x.x.0/x to us? Regards, Alans ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
