RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 795109 - Thunderbird fails to detect DNS changes
Summary: Thunderbird fails to detect DNS changes
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: thunderbird
Version: 6.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Martin Stransky
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1002711
TreeView+ depends on / blocked
 
Reported: 2012-02-19 12:49 UTC by Dmitri Pal
Modified: 2023-09-14 01:27 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-18 13:52:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Dmitri Pal 2012-02-19 12:49:02 UTC 
Steps
1. Log into the system and connect to a corporate network
2. Start Thunderbird (configured with kerberos, not sure if it makes a difference)
3. Check mail - works fine
4. Close a lid and go to a coffee shop that requires you to accept wireless connection via a browser.
5. Log in offline.
6. Establish wireless connection
7. In the browser accept the connection (you might have to restart FireFox - which IMO is a FF bug.
8. Establish VPN connection  
9. Start using the Thunderbird again

Expected: 
Thunderbird continues to work fine

Actual:
You have to restart Thunderbird as it seems to fail to resolve the name of the server.

Observation:
It seems to cache names in some way and but the DNS server provided by the coffee shop and by organization usually not related to each other. May be it is the bug in the underlying DNS resolution layer.
Comment 3 RHEL Program Management 2012-05-03 05:34:00 UTC 
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Comment 4 Martin Stransky 2012-07-26 14:33:17 UTC 
Does it affect Thunderbird only? Because Firefox and Thunderbird shares the same code. Which package versions do you use?
Comment 5 Clifford Perry 2012-07-26 14:44:32 UTC 
(In reply to comment #4)
> Does it affect Thunderbird only? Because Firefox and Thunderbird shares the
> same code. Which package versions do you use?

Well, I do in fact suffer this issue in Firefox. Which is why within Firefox I use the DNS Flusher add-on. If I had found a similar plugin for Thunderbird, I would have installed it as well :) 

Cliff
Comment 6 Martin Stransky 2012-08-03 12:46:48 UTC 
Does it help if you swith offline/online mode? In File/Offline. It should reload the network settings.
Comment 7 Dmitri Pal 2012-08-09 21:58:28 UTC 
My initial report in step 7 mentions that I have to restart FF. So yes FF has the same issue.

Thunderbird/3.1.18 on RHEL6
Firefox/3.6.26
Comment 13 Bill McGonigle 2014-08-07 16:54:27 UTC 
Still exists on thunderbird-24.7.0-1.fc20.x86_64.

Slightly simpler scenario I got a call on: 

Thunderbird was connected to smtp.example.com with an internal IP (10.) onsite.
Going offsite (residential cable modem), connections to smtp.example.com fail (verified with packet dump), as it's trying to connect to the internal address still.  Even after four days, no DNS expiration happneed.  Quitting Thunderbird and restarting it immediately cleared up the problem.

For an unknown reason the connection to imap.example.com for inbound mail did not suffer the same symptom.  Perhaps there's a check in the IMAP code that got accidentally omitted from the SMTP code?  I notice that Thunderbird is savvy about network changes (guess: dbus messages?) so perhaps that's where/when it's fixing up its IMAP DNS?
Comment 14 Martin Stransky 2015-01-28 10:29:12 UTC 
Reporter, after the DNS change, can you try to clear it? in Menu Tools -> Clear Recent History... and select "Cache".

You can also set those values in about:config:

network.dns.disablePrefetch = true
network.dnsCacheExpiration = 0
Comment 15 Martin Stransky 2015-01-28 10:44:03 UTC 
Note: The about:config values in Thunderbird can be found in Menu, Edit -> Preferences -> Advanced -> General tab -> Config Editor button.
Comment 16 Dmitri Pal 2015-02-12 16:58:49 UTC 
(In reply to Martin Stransky from comment #14)
> Reporter, after the DNS change, can you try to clear it? in Menu Tools ->
> Clear Recent History... and select "Cache".
> 
> You can also set those values in about:config:
> 
> network.dns.disablePrefetch = true
> network.dnsCacheExpiration = 0

The work around I use is turning "work offline" on and then "work offline" off and the DNS seems to be re-read and things usually start working again. Sometimes I need to do it couple times but it is probably because I am inpatient and it takes time to figure out what DNS server is the right one in the resolv.conf.
Comment 17 Dmitri Pal 2015-02-12 17:01:22 UTC 
(In reply to Martin Stransky from comment #14)
> Reporter, after the DNS change, can you try to clear it? in Menu Tools ->
> Clear Recent History... and select "Cache".
> 
> You can also set those values in about:config:
> 
> network.dns.disablePrefetch = true
> network.dnsCacheExpiration = 0

I do not see dnsCacheExpiration I see dnsCacheExpirationGracePeriod is this the same thing?
Comment 18 Martin Stransky 2015-02-13 10:01:07 UTC 
You need to add the "network.dnsCacheExpiration" as a new integer value, it's not exposed by default. Default DNS expiration time is 120 sec now.

You can also lower the dnsCacheExpirationGracePeriod.
Comment 20 Wayne Mery (:wsmwk) 2015-06-09 10:46:32 UTC 
(In reply to Martin Stransky from comment #18)
> You need to add the "network.dnsCacheExpiration" as a new integer value,
> it's not exposed by default. Default DNS expiration time is 120 sec now.
> 
> You can also lower the dnsCacheExpirationGracePeriod.

Apparently Dmitri won't be replying any time soon: "I am now used to getting offline and online and this fixes the problem pretty fast. Sometimes I need to restart TB. Overall IMO TB should detect network changes itself like SSSD does and adjust accordingly. .... I just do not have time to test, sorry."

Flipping preferences is rather trivial - most unfortunate it won't be tested.
Comment 22 Chris Williams 2015-09-18 13:52:28 UTC 
This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 6 and therefore will be closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification.
Comment 23 Red Hat Bugzilla 2023-09-14 01:27:32 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
Note You need to log in before you can comment on or make changes to this bug.