Closed Bug 1552105 Opened 5 years ago Closed 5 years ago

WPAD: automatic configuration does not lookup wpad in parent DNS domains

Categories

(Core :: Networking, defect)

66 Branch
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: eole-team, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
OS: Ubuntu Bionic

  • we have a domain example.net where wpad.example.net configure the proxy for every hosts
  • we have a subdomain ad.example.net for a Samba4 Active Directory, all workstation are under that DNS domain
  • we configure firefox for proxy auto-detection using WPAD

Actual results:

Firefox try to lookup:

  • wpad.ad.example.net
  • wpad

Here are the tshark logs

1 0.000000000    127.0.0.1 → 127.0.0.53   DNS 96 Standard query 0x39c8 A wpad.ad.example.net OPT
2 0.000021291    127.0.0.1 → 127.0.0.53   DNS 96 Standard query 0x50d6 AAAA wpad.ad.example.net OPT
3 0.000525760    10.1.2.50 → 10.1.2.1     DNS 96 Standard query 0x8a0c A wpad.ad.example.net OPT
4 0.000720855    10.1.2.50 → 10.1.2.1     DNS 96 Standard query 0x5fbf AAAA wpad.ad.example.net OPT
5 0.002877691     10.1.2.1 → 10.1.2.50    DNS 96 Standard query response 0x5fbf No such name AAAA wpad.ad.example.net OPT
6 0.003052110    10.1.2.50 → 10.1.2.1     DNS 85 Standard query 0x5fbf AAAA wpad.ad.example.net
7 0.003422653     10.1.2.1 → 10.1.2.50    DNS 96 Standard query response 0x8a0c No such name A wpad.ad.example.net OPT
8 0.003432283     10.1.2.1 → 10.1.2.50    DNS 85 Standard query response 0x5fbf No such name AAAA wpad.ad.example.net
9 0.003499256    10.1.2.50 → 10.1.2.1     DNS 85 Standard query 0x8a0c A wpad.ad.example.net

10 0.003636164 127.0.0.53 → 127.0.0.1 DNS 96 Standard query response 0x50d6 No such name AAAA wpad.ad.example.net OPT
11 0.003815724 10.1.2.1 → 10.1.2.50 DNS 85 Standard query response 0x8a0c No such name A wpad.ad.example.net
12 0.003903402 127.0.0.53 → 127.0.0.1 DNS 96 Standard query response 0x39c8 No such name A wpad.ad.example.net OPT
13 0.003968819 127.0.0.1 → 127.0.0.53 DNS 77 Standard query 0x7d5f A wpad OPT
14 0.003976404 127.0.0.1 → 127.0.0.53 DNS 77 Standard query 0x7066 AAAA wpad OPT
15 0.004077340 127.0.0.53 → 127.0.0.1 DNS 77 Standard query response 0x7d5f Server failure A wpad OPT
16 0.004165124 127.0.0.53 → 127.0.0.1 DNS 77 Standard query response 0x7066 Server failure AAAA wpad OPT
17 0.004197900 127.0.0.1 → 127.0.0.53 DNS 77 Standard query 0x7d5f A wpad OPT
18 0.004203840 127.0.0.1 → 127.0.0.53 DNS 77 Standard query 0x7066 AAAA wpad OPT

Expected results:

Firefox should have tried to resolve the following DNS names:

  • wpad.ad.example.net
  • wpad.example.net

https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Protocol

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

Is your proxy setting at "Auto-detect proxy settings for this network" under options/network settings?

Component: Networking: DNS → Networking
Flags: needinfo?(eole-team)

Yes, that's exactly the setting used.

Without it, there is no DNS request for wpad.ad.example.net.

Here is the screen shot of the parameter, to be sure.

Flags: needinfo?(eole-team)

I believe we are not resolving upper-level domains on purpose, as it's seen as a potential security issue.

You may configure WPAD (PAC) URL using DHCP option 252, which we support since firefox 63.

We use the DHCP option 252 for windows machine:

option wpad-url code 252 = text;
option wpad-url "http://wpad.ad.example.net/wpad.dat\n";

but Firefox on GNU/Linux does not use it.

https://searchfox.org/mozilla-central/rev/11cfa0462a6b5d8c5e2111b8cfddcf78098f0141/netwerk/base/nsPACMan.cpp#573-579

    // We diverge from the WPAD spec here in that we don't walk the
    // hosts's FQDN, stripping components until we hit a TLD.  Doing so
    // is dangerous in the face of an incomplete list of TLDs, and TLDs
    // get added over time.  We could consider doing only a single
    // substitution of the first component, if that proves to help
    // compatibility.
    aSpec.AssignLiteral(MOZ_WPAD_URL);

I think this is the reason for that.
WONTFIX?

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID

Dragana, are you OK with WONTFIX'ing this bug?
As the comment says, We could consider doing only a single substitution of the first component, if that proves to help compatibility. but I'm not sure whether we actually want to do that.

Flags: needinfo?(dd.mozilla)
Resolution: INVALID → WONTFIX
Flags: needinfo?(dd.mozilla)

it is fine.

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

Attachment

General

Creator:
Created:
Updated:
Size: