Bug 795109

Summary:	Thunderbird fails to detect DNS changes
Product:	Red Hat Enterprise Linux 6	Reporter:	Dmitri Pal <dpal>
Component:	thunderbird	Assignee:	Martin Stransky <stransky>
Status:	CLOSED WONTFIX	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2	CC:	bill-bugzilla.redhat.com, dpal, liko, mkolbas, ovasik, stransky, tpelka, vseerror
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-09-18 13:52:28 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1002711

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