Closed Bug 1724345 Opened 6 months ago Closed 4 months ago

"Page cannot be opened due to long Pac file or dns search suffix"

Categories

(Core :: Networking: DNS, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
94 Branch
Tracking Status
firefox94 --- fixed

People

(Reporter: lukas.campr, Assigned: valentin)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Linux; Android 10; MAR-LX1A) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Mobile Safari/537.36

Steps to reproduce:

Hi there, is there anything what could be tweaked in about:config to resolve below issue?

Proxy Pac file used, pac file is quite long but doesn't create issue in general. Now, occasionally some web application cannot open at all. It is happening only in Firefox and not other browsers. I narrow down that it must be related to some timers because if explicit rule in Pac file to send proxy is put somewhere near top, it works. Pac doesn't have to be processed until last default rule. Or it can be resolved by reducing number of dns suffixes I think there was 7 when I was removing them on count 4 page started loading.

Thank you

Actual results:

Page cannot be displayed

Expected results:

Page should openen

The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Networking: DNS
Product: Firefox → Core

Not sure if any prefs are involved that could improve the issue.
Did this just start happening in recent versions? If so, could you use MozRegression to help identify the regressing bug?
Otherwise, we'll need to try to debug this the old-fashioned way :)
You can find instructions on how to do so here - if the logs contain sensitive information consider sending them via email. Make sure to add proxy:5 to the logging modules. Also check the browser console (Cmd+Shift+J) if it contains any proxy related warnings/errors.

Thanks!

Flags: needinfo?(lukas.campr)

Hello,
I played with this a bit more and Sorry for late update. It turned out it is not about number of suffixes (just wrong conclusion because they were in exact order and I always removed problematic) it is about one particular suffix we use on network for which some device on network using dynamic dhcp registr "null" name in that domain. With combination of some dns check in pac file and other factors it all fails. It is not passed on network / proxy is blacholed even before. As soon as this null fqdn dns query appear in Firefox website that has nothing to do with page that is not working it all fails. Another condition to replicate it is that impacted application dns record cannot be resolved internally. I think it has something to do with returning empty response from dns. But it happens only in Firefox. Any idea why unrelated null fqdn cause all this?

I don't want to share details here due to sensitive information. I will share privately.

Thank you

Flags: needinfo?(lukas.campr)

I don't want to share details here due to sensitive information. I will share privately.

Hi, could you try to capture a log and send the log to my email directly?
It'd be great if you can also share the pac file and other details.
Thanks.

Flags: needinfo?(lukas.campr)

So you have a domain named "null" in the pac file?
I assume this is confusing the JS interpreter. I'd be very interested in seeing the pac file too. Feel free to send it to me or Kershaw via email.

Lukas has helped us understand the scenario a bit better.
The buggy pac script does something like this:

function FindProxyForURL(url, host) {
  var destIP = dnsResolve(host);
  if (isInNet(destIP, '2.0.0.0', '255.0.0.0') || isInNet(destIP, '7.0.0.0', '255.0.0.0')) {
    return "DIRECT";
  }
  return "PROXY myproxy.com";
}

For a host that does not resolve, you'd expect it to be proxyed.
But apparently isInNet returns true 🤯
It turns out passing null to isInNet does another dnsResolve for null, but the argument is simply converted to a string which triggers a DNS resolution for the host "null". If this happens to resolve to something that is in that network, isInNet will return true instead of false, which breaks the script logic.

The fix should be easy enough. Thanks for reporting it lukas!

Assignee: nobody → valentin.gosu
Severity: -- → S3
Flags: needinfo?(lukas.campr)
Priority: -- → P2
Whiteboard: [necko-triaged]

Simply converting the argument to a string could lead to odd situations where
resolving null succeeds if a hostname called "null" exists on the network.

Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/0227359f817c
Make sure argument passed to dnsResolve is string in PAC scripts r=necko-reviewers,kershaw
Status: UNCONFIRMED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 94 Branch

FYI this revision has the wrong bug number.
https://hg.mozilla.org/mozilla-central/rev/c18ceac2d1dc

Awsome, thank you for help. Soon I will no more chase null devices in our network 😂

You need to log in before you can comment on or make changes to this bug.