83.0 (64-bit) Local host names not resolved by their NetBIOS name
Categories
(Core :: Networking, defect, P2)
Tracking
()
People
(Reporter: rizanto, Assigned: valentin)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [necko-triaged])
Attachments
(1 file)
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-esr78+
|
Details | Review |
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:
Updated•3 years ago
|
32-bit version confirmed too. It did worked in 82.0.3 and doesn't work in 83.0.
Comment 2•3 years ago
|
||
Could you try to use mozregression to find out the faulty revision?
Thanks.
Updated•3 years ago
|
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
Comment 4•3 years ago
|
||
(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?
Assignee | ||
Comment 5•3 years ago
|
||
Could you check if resolving https://rk01./ works? Thanks!
Updated•3 years ago
|
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.
Assignee | ||
Comment 7•3 years ago
|
||
Another work around is setting the network.dns.dns_query_single_label
pref to false
in about:config
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Comment 11•3 years ago
|
||
Amending subject a bit to make it easier to find.
Comment 12•3 years ago
|
||
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
Updated•3 years ago
|
Updated•3 years ago
|
Comment 15•3 years ago
|
||
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
Updated•3 years ago
|
Comment 16•3 years ago
|
||
For the record, this also appeared on the latest ESR (79.x I believe)
Comment 17•3 years ago
|
||
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
Comment 18•3 years ago
|
||
(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
Assignee | ||
Comment 19•3 years ago
|
||
This seems to have caused a bunch of regressions. We'll likely try to enable
it at a later time.
Updated•3 years ago
|
Comment 20•3 years ago
|
||
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
Comment 21•3 years ago
|
||
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.
Comment 22•3 years ago
|
||
(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 .
Comment 23•3 years ago
|
||
(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 thePreferences
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.
Comment 24•3 years ago
|
||
(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 thePreferences
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.
Comment 25•3 years ago
|
||
(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 thePreferences
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...)
Comment 26•3 years ago
|
||
(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.
Comment 27•3 years ago
|
||
(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 tofalse
as soon as the rollout is done. Thanks
Sure thing Pascal. Alex (atrif) will handle this as soon as the rollout is done.
Updated•3 years ago
|
Comment 28•3 years ago
|
||
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
Comment 29•3 years ago
|
||
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"
}
}
Comment 30•3 years ago
|
||
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
Reporter | ||
Comment 31•3 years ago
|
||
(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!
Comment 32•3 years ago
|
||
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
Comment 33•3 years ago
|
||
bugherder |
Comment 34•3 years ago
|
||
Was fixed in 83 with a Normandy rollout, we should probably uplift the in-tree fix. to beta though.
Assignee | ||
Comment 35•3 years ago
|
||
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:
Comment 36•3 years ago
|
||
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.
Comment 37•3 years ago
|
||
bugherder uplift |
Comment 38•3 years ago
|
||
bugherder uplift |
Updated•3 years ago
|
Comment 41•3 years ago
|
||
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.
Description
•