324941 - 'Manual' versus 'wpad' proxy settings: inconsistent name resolution behavior

Status: UNCONFIRMED

(Core :: Networking: Proxy, defect, P5)

Description

[Olivier]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8) Gecko/20060121 Ubuntu/1.5.dfsg-4ubuntu4 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8) Gecko/20060121 Ubuntu/1.5.dfsg-4ubuntu4 Firefox/1.5

Dns resolution is not done the same way wether you explicitely specify proxy settings, or if you use pac files (or wpad).

Reproducible: Always

Steps to Reproduce:
1. set http proxy settings manually, capture traffic, fire fox to whatever.com
2. set http proxy via a local pad file, capture traffic, fire fox to whatever.com
3. set http proxy via http://wpad/wpad.dat, capture traffic, fire fox to whatever.com
Actual Results:  
In case 1, dns resolution is performed on server.
In case 2&3, dns resolution is performed client side. 

Expected Results:  
Consistent behavior. Either do the resolution client side, either on the server.
IMHO it should be done on the server, right?

Wether this has (or not) to do with bug #134105 is out of my limited understanding...

Also, I may have done a mistake, misconfiguration somewhere, or I may have simply missed the point of wpad totally....

Information on pac (wpad) files is somewhat hard to collect, and often end-up to http://channels.netscape.com/errorpages/404.jsp


Anyhow, if I prove right, this is a real problem on subnets that don't have access to name servers.


Thank you ;)

Comment 1

[Olivier]

"this is a real problem on subnets that don't have
access to name servers."

Guess I could reformulate that into:
"subnets where the name server(s) is authoritative only (for the "subnet" zone), and where clients can't query other nameservers".

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

Is this a real issue for you, or do you only suspect it to be a problem?

I'm asking because this seems to be fine. With PAC, DNS resolution does not occur on client side only. In fact, that DNS resolution is only done so that the PAC script can use isInNet or similar functions. If it returns a proxy server, that one will do the real DNS resolution.

Comment 3

[Olivier]

> Is this a real issue for you, or do you only suspect it to be a problem?
> I'm asking because this seems to be fine. With PAC, DNS resolution does not
occur on client side only. In fact, that DNS resolution is only done so that
the PAC script can use isInNet or similar functions. If it returns a proxy
server, that one will do the real DNS resolution.

Perfectly right, I'm afraid... I deduced it only from watching paquets flow (which is in fact my main concern)...
Following your idea, I tested it on both side: dns resolution indeed occurs on both sides.


Now, I'm still confused by the following points:
a) - why does firefox needs **such a large amount** of dns queries, all of them returned "refused" by bind, before giving it up? (the "refuse" is defined by acl in bind; I didn't yet test with "dropping" iptables rule)
b) - why is the pac/wpad behavior so different from the "explicit" behavior, with the same rules? Do you suggest that pac/wpad use different methods to determine isInNet? [I'm not familiar with mozilla internals]

All in all, it's working in its current state (yet it seems to me that the dns flow has a bad impact on "performance"), and my initial argument doesn't stand; still, the issue defeats part of my initial plan (silent most dns queries on the subnet).

If you would be kind enough to provide some lights regarding a) || b), we could either close this bug or change its description...


Thank you very much ;)

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #3)
> a) - why does firefox needs **such a large amount** of dns queries, all of them
> returned "refused" by bind, before giving it up? (the "refuse" is defined by
> acl in bind; I didn't yet test with "dropping" iptables rule)

Hm? comment 0 does not mention a large amount. Is there more than one query per HTTP request? (hm... I guess we don't cache negative replies... maybe we should)

> b) - why is the pac/wpad behavior so different from the "explicit" behavior,
> with the same rules? Do you suggest that pac/wpad use different methods to
> determine isInNet? [I'm not familiar with mozilla internals]

No, manual configuration does not need isInNet. The PAC file is a JS file though and can call isInNet or similar methods, and those need the resolved host.

> If you would be kind enough to provide some lights regarding a) || b), we could
> either close this bug or change its description...

I hope I cleared it up. Now, this implementation is maybe not the best way to do this, as it does the DNS query even if the PAC file does not use the resolved host. But, as I recall, changing that is not so easy to do...

Comment 5

[Olivier]

(In reply to comment #4)
> Hm? comment 0 does not mention a large amount. Is there more than one query per
> HTTP request?

No. I didn't noticed at first, as I simply thought name resolution was entirely done client side - and it was enough (wrong, sorry :p).

Indeed, there's *largely* more than 1 query (when bind deny the request), and now this is the main issue.
May I add a dump as an attachment?

> (hm... I guess we don't cache negative replies... maybe we
> should)

Probably...
I'll do more tests, with different bind setup (deny recursion, deny query, deny both), and come back with the results.

> [snip]
> No, manual configuration does not need isInNet. The PAC file is a JS file
> though and can call isInNet or similar methods, and those need the resolved
> host.
> 
> I hope I cleared it up. Now, this implementation is maybe not the best way to
> do this, as it does the DNS query even if the PAC file does not use the
> resolved host. But, as I recall, changing that is not so easy to do...

I'm still confused: how come the "manual" setup decide if the requested host is or is not in the 192.168.1.0/24 subnet (in the no-proxy field) without resolving it?


Now, I'm going for the tests, and try to turn this bogus bug into something usefull :p


Thanks


PS: I didn't found a bug to add proxy settings autodetection via dhcp. Should I fill a RFE, or is it planned?

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #5)
> I'm still confused: how come the "manual" setup decide if the requested host is
> or is not in the 192.168.1.0/24 subnet (in the no-proxy field) without
> resolving it?

Oh, that's easy. It doesn't decide that. IP Addresses in that field are only checked against when an IP address is entered.

> PS: I didn't found a bug to add proxy settings autodetection via dhcp. Should I
> fill a RFE, or is it planned?

Should probably file a RFE... I don't think there a immediate plans for it.

Comment 7

[Lee Carré]

>> PS: I didn't found a bug to add proxy settings autodetection via dhcp. Should I
>> fill a RFE, or is it planned?
> 
> Should probably file a RFE... I don't think there a immediate plans for it.
> 

my appologies as this is unrelated to this particular bug, but i was wondering if the fact that proxy autodetection doesn't use DHCP code 252 has already been reported or not, because that's why i'm visiting, after a few hours of trying to work out why autodetection worked in IE but not in Fx i think using DHCP will save a lot of network admins a lot of hastle

Comment 8

[Michael Mössler]

The Name Resolving doesn't work when using Proxy Script such as This one:
Tested with Firefox  Version 2.0.0.7

function FindProxyForURL(url, host)
  {
    if (isInNet(myIpAddress(),"10.0.0.0", "255.255.0.0"))
      { 
        if (isResolvable(host))
          { var ip=dnsResolve(host);
             if (  isInNet(ip, "11.11.22.33", "255.255.255.255"  ))
		{
			return "PROXY 10.0.0.254:3180;"; 
		}
	     if(
               (myIpAddress() == ip )||
               isPlainHostName(host)||
               isInNet(ip, "127.0.0.0", "255.0.0.0")||
               isInNet(ip, "172.0.0.0", "255.255.0.0")||
               isInNet(ip, "10.0.0.0", "255.255.0.0")||
               isInNet(ip, "80.90.100.128", "255.255.255.192")
        
              )
            {
                 return "DIRECT";
            } else {
              return "PROXY 10.0.0.254:8080";
            }
          }
      }
    return "DIRECT";
  }

Comment 9

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 10

[BMO Automation]

Moving bug to Core/Networking: Proxy.