Closed Bug 1677806 Opened 3 years ago Closed 3 years ago

83.0 (64-bit) Local host names not resolved by their NetBIOS name

Categories

(Core :: Networking, defect, P2)

Firefox 83
Desktop
Windows
defect

Tracking

()

VERIFIED FIXED
85 Branch
Tracking Status
firefox-esr78 --- verified
firefox82 --- unaffected
firefox83 + fixed
firefox84 --- verified
firefox85 --- verified

People

(Reporter: rizanto, Assigned: valentin)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [necko-triaged])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

I have just update Firefox from previous version. Then try to connect web server within LAN by its NetBIOS name
https://rk01/
note: connection is normal when use the IP address.

Actual results:

Hmm. We’re having trouble finding that site.
We can’t connect to the server at rk01.
If that address is correct, here are three other things you can try:

Component: Untriaged → Networking
Product: Firefox → Core

32-bit version confirmed too. It did worked in 82.0.3 and doesn't work in 83.0.

Could you try to use mozregression to find out the faulty revision?
Thanks.

Flags: needinfo?(rizanto)

It was quite hard to understand to use nbtstat -R on each regression test :)
mozregression showed this:

Bug 1663571 - Resolve single label DNS queries using DnsQuery_A r=necko-reviewers,dragana
Differential Revision: https://phabricator.services.mozilla.com/D91117

(In reply to sddex from comment #3)

It was quite hard to understand to use nbtstat -R on each regression test :)
mozregression showed this:

Bug 1663571 - Resolve single label DNS queries using DnsQuery_A r=necko-reviewers,dragana
Differential Revision: https://phabricator.services.mozilla.com/D91117

Thanks for this information. This is really helpful.
Valentin, could you take a look?

Flags: needinfo?(rizanto) → needinfo?(valentin.gosu)

Could you check if resolving https://rk01./ works? Thanks!

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(valentin.gosu) → needinfo?(rizanto)
Priority: -- → P2
Regressed by: CVE-2020-26966
Whiteboard: [necko-triaged]
Has Regression Range: --- → yes

Could you check if resolving https://rk01./ works? Thanks!

I have different hostname but I confirm that resolving name with trailing dot works. But in my case server gives 400 Bad Request so this workaround doesn't suit everyone.

Another work around is setting the network.dns.dns_query_single_label pref to false in about:config

QA Whiteboard: [qa-regression-triage]
OS: Unspecified → Windows
Hardware: Unspecified → Desktop

Amending subject a bit to make it easier to find.

Summary: 83.0 (64-bit) Can not host by its NetBIOS name → 83.0 (64-bit) Local host names not resolved by their NetBIOS name

Another workaround is to add NetBios names to the "C:\Windows\System32\drivers\etc\hosts" file
Hosts added to this file will be resolved correctly

See Also: → 1677395
Alias: regression
Alias: regression

When i want to open page at my e.g. NAS, i must add .local after name.
Before last upgrade i used https://myNAS.
Now I must put https://myNas.local

Chrome / edge is ok

For the record, this also appeared on the latest ESR (79.x I believe)

A fast workaround in Windows is to edit the Hosts file and add the IP and NetBIOS name.

Run Notepad as Administrator
Open C:\Windows\System32\drivers\etc\hosts
Add your unreachable machine's IP then a tab, then the machine name, ie.

10.10.10.10 myServer

Close and save
Now you should be able to connect to the NetBIOS name

(In reply to Valentin Gosu [:valentin] (he/him) from comment #5)

Could you check if resolving https://rk01./ works? Thanks!

Adding the dot at the end made the page display

This seems to have caused a bunch of regressions. We'll likely try to enable
it at a later time.

Assignee: nobody → valentin.gosu
Status: NEW → ASSIGNED
Depends on: 1678387

Mihai, we are doing a pref rollout for the release and esr channels (83 and 78.5) to avoid a dot release just for this patch, we would need QA to check that network.dns.dns_query_single_label is set to false as soon as the rollout is done. Thanks

Flags: qe-verify+
Flags: needinfo?(mihai.boldan)

with deployments which have already been completed, is there a way to resolve this in an enterprise environment (aka group policy controlled). We have 2000+ machines with 83 installed which are experiencing issues with shortname resolution. Iv just changed the network.dns.dns_query_single_label setting in my about:config on my local machine and it has resolved the issue, but we dont deploy preference files with our deployment, they are updated directly from cloud and settings controlled via GPO.

(In reply to Aaron from comment #21)

with deployments which have already been completed, is there a way to resolve this in an enterprise environment (aka group policy controlled). We have 2000+ machines with 83 installed which are experiencing issues with shortname resolution. Iv just changed the network.dns.dns_query_single_label setting in my about:config on my local machine and it has resolved the issue, but we dont deploy preference files with our deployment, they are updated directly from cloud and settings controlled via GPO.

You can set network.* preferences (including this one) with the Preferences policy, see https://github.com/mozilla/policy-templates/releases and https://github.com/mozilla/policy-templates/blob/master/README.md#preferences .

(In reply to :Gijs (he/him) from comment #22)

(In reply to Aaron from comment #21)

with deployments which have already been completed, is there a way to resolve this in an enterprise environment (aka group policy controlled). We have 2000+ machines with 83 installed which are experiencing issues with shortname resolution. Iv just changed the network.dns.dns_query_single_label setting in my about:config on my local machine and it has resolved the issue, but we dont deploy preference files with our deployment, they are updated directly from cloud and settings controlled via GPO.

You can set network.* preferences (including this one) with the Preferences policy, see https://github.com/mozilla/policy-templates/releases and https://github.com/mozilla/policy-templates/blob/master/README.md#preferences .

Ah, thats a good one, i knew the old ones were there but never had a need to look at this one. Struggling a little to understand how to implement though, we have no preferences in the deprecated preferences area of the GPO, but the new preferences option is just a text box. What exactly do i add to configure this "network.dns.dns_query_single_label" setting to be set as false.

(In reply to Aaron from comment #23)

(In reply to :Gijs (he/him) from comment #22)

(In reply to Aaron from comment #21)

with deployments which have already been completed, is there a way to resolve this in an enterprise environment (aka group policy controlled). We have 2000+ machines with 83 installed which are experiencing issues with shortname resolution. Iv just changed the network.dns.dns_query_single_label setting in my about:config on my local machine and it has resolved the issue, but we dont deploy preference files with our deployment, they are updated directly from cloud and settings controlled via GPO.

You can set network.* preferences (including this one) with the Preferences policy, see https://github.com/mozilla/policy-templates/releases and https://github.com/mozilla/policy-templates/blob/master/README.md#preferences .

Ah, thats a good one, i knew the old ones were there but never had a need to look at this one. Struggling a little to understand how to implement though, we have no preferences in the deprecated preferences area of the GPO, but the new preferences option is just a text box. What exactly do i add to configure this "network.dns.dns_query_single_label" setting to be set as false.

I'm not an expert on our GPO support (and I'm in Europe and it's now 2am, where did the time go). But it looks like you want:

{
  "network.dns.dns_query_single_label": {
    "Value": false,
    "Status": "default"
  }
}

:mkaply should be able to confirm.

Flags: needinfo?(mozilla)

(In reply to :Gijs (he/him) from comment #24)

(In reply to Aaron from comment #23)

(In reply to :Gijs (he/him) from comment #22)

(In reply to Aaron from comment #21)

with deployments which have already been completed, is there a way to resolve this in an enterprise environment (aka group policy controlled). We have 2000+ machines with 83 installed which are experiencing issues with shortname resolution. Iv just changed the network.dns.dns_query_single_label setting in my about:config on my local machine and it has resolved the issue, but we dont deploy preference files with our deployment, they are updated directly from cloud and settings controlled via GPO.

You can set network.* preferences (including this one) with the Preferences policy, see https://github.com/mozilla/policy-templates/releases and https://github.com/mozilla/policy-templates/blob/master/README.md#preferences .

Ah, thats a good one, i knew the old ones were there but never had a need to look at this one. Struggling a little to understand how to implement though, we have no preferences in the deprecated preferences area of the GPO, but the new preferences option is just a text box. What exactly do i add to configure this "network.dns.dns_query_single_label" setting to be set as false.

I'm not an expert on our GPO support (and I'm in Europe and it's now 2am, where did the time go). But it looks like you want:

{
  "network.dns.dns_query_single_label": {
    "Value": false,
    "Status": "default"
  }
}

:mkaply should be able to confirm.

Was playing with this myself last night, and tried something very much like that from the example, but every time i did a gpupdate and checked the about:config the setting remained set to true :(

did your previous post tag :mkaply in some way that he would be notified, or should i try and be contacting him in some way (sorry, first time posting into the bugzilla area, so not sure of all the tags and processes...)

(In reply to Aaron from comment #25)

did your previous post tag :mkaply in some way that he would be notified, or should i try and be contacting him in some way (sorry, first time posting into the bugzilla area, so not sure of all the tags and processes...)

mkaply is tagged (NeedInfoed in Bugzilla jargon), he is in a US timezone.

(In reply to Pascal Chevrel:pascalc from comment #20)

Mihai, we are doing a pref rollout for the release and esr channels (83 and 78.5) to avoid a dot release just for this patch, we would need QA to check that network.dns.dns_query_single_label is set to false as soon as the rollout is done. Thanks

Sure thing Pascal. Alex (atrif) will handle this as soon as the rollout is done.

Flags: needinfo?(mihai.boldan) → needinfo?(alexandru.trif)
Flags: needinfo?(alexandru.trif)

DNS Query Single Label Hotfix
Firefox Release 83.0
Firefox ESR 78.5.0

We have finished testing the [PI-871] DNS Query Single Label Hotfix rollout.

Quality status: YELLOW - SHIP IT CONDITIONALLY

Why is this rollout yellow?
- Delivery mechanism:
- No issues found.
- Product specific:

  • Given the time constraints and our limited knowledge of the feature, we have only covered the rollout (using the Prod recipe) and rollback (using a cloned Staging recipe) actions, but were not able to set a proper environment in order to verify if the hotfix resolves the issue mentioned in Bug 1677806.

What needs to be done?

  • [Engineering] [Product]: The team should continuously monitor any feedback from the users enrolled in the rollout in order to intervene in case of reported regressions on the feature part of the rollout.

Testing Summary:
- Covered the following scenarios:

  • Verified enrollment in Normal Browsing mode, Private Browsing mode, and Safe mode.
  • Verified that users that become eligible are enrolled in the study.
  • Verified that ineligible users are not enrolled in the rollout.
  • Verified that the preference is correctly set in the “about:config” page.
  • Verified that the “enroll” telemetry event is displayed after enrollment.
  • Verified that the rollout remains enabled after restarting and updating the browser.
  • Cloned the production recipe on the stage environment and verified unenrollment via rollback in Normal Browsing mode, Private Browsing mode and Safe mode.
  • Verified that users remain enrolled in the rollout after editing the recipe.
  • Verified that the “unenroll” telemetry event is displayed after rollback.

- We have NOT been able to cover the following scenarios:

  • Update browser from ESR 78.5.0 to a higher version.

Tested Platforms and Firefox versions:

  • Windows 10 x64 - Firefox 83.0 (Build ID: 20201112153044) and Firefox ESR 78.5.0 (Build ID: 20201110001500) en-US, es-ES locales
  • Windows 7 x64 - Firefox 83.0 (Build ID: 20201112153044) and Firefox ESR 78.5.0 (Build ID: 20201110001500) en-US locale
  • Linux Mint 20 x64 - Firefox 83.0 (Build ID: 20201112153044) and Firefox ESR 78.5.0 (Build ID: 20201110001500) fr locale
  • macOS 10.15 - Firefox 83.0 (Build ID: 20201112153044) and Firefox ESR 78.5.0 (Build ID: 20201110001500) de locale

For reasons I don't understand (yet), the default value of this pref is not able to be changed. Try this instead:

{
  "network.dns.dns_query_single_label": {
    "Value": false,
    "Status": "locked"
  }
}
Flags: needinfo?(mozilla)

I just did some more testing and it is working. I think I hadn't restarted my browser.

If you're continuing to have issues, feel free to reach out to me directly. mkaply at mozilla.com

(In reply to Valentin Gosu [:valentin] (he/him) from comment #5)

Could you check if resolving https://rk01./ works? Thanks!

https://rk01./
it work !
(In reply to Valentin Gosu [:valentin] (he/him) from comment #5)

Could you check if resolving https://rk01./ works? Thanks!

https://rk01./
it works!! and the bugs gone. Thanks!

Flags: needinfo?(rizanto)
Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/b4672a70686e
Set network.dns.dns_query_single_label to false r=Gijs
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch

Was fixed in 83 with a Normandy rollout, we should probably uplift the in-tree fix. to beta though.

Flags: needinfo?(valentin.gosu)

Comment on attachment 9188867 [details]
Bug 1677806 - Set network.dns.dns_query_single_label to false r=Gijs

Beta/Release Uplift Approval Request

  • User impact if declined: This feature is preffed off via Normandy at the moment to avoid failures when resolving certain local domains.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Reverts Firefox to a previous behaviour (that is currently being set by Normandy anyway)
  • String changes made/needed:

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: esr78 is affected.
  • User impact if declined: This feature is preffed off via Normandy at the moment to avoid failures when resolving certain local domains.
  • Fix Landed on Version: 85
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Reverts Firefox to a previous behaviour (that is currently being set by Normandy anyway)
  • String or UUID changes made by this patch:
Flags: needinfo?(valentin.gosu)
Attachment #9188867 - Flags: approval-mozilla-esr78?
Attachment #9188867 - Flags: approval-mozilla-beta?

Comment on attachment 9188867 [details]
Bug 1677806 - Set network.dns.dns_query_single_label to false r=Gijs

Approved for 84.0b7 and 78.6esr.

Attachment #9188867 - Flags: approval-mozilla-esr78?
Attachment #9188867 - Flags: approval-mozilla-esr78+
Attachment #9188867 - Flags: approval-mozilla-beta?
Attachment #9188867 - Flags: approval-mozilla-beta+
QA Whiteboard: [qa-regression-triage] → [qa-regression-triage][qa-triaged]

I have verified that network.dns.dns_query_single_label is set by default to false on Firefox 85.0a1 (Build ID 20201202091636), Firefox 84.0b7 (Build ID 20201201213706 and 20201201000017) and Firefox 78.6.0esr (Build ID 20201201001008) using Windows 10, Linux Mint 20 and macOS 10.15.

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