312061 - Call res_ninit when restarting the DNS service [was: Firefox keeps a list of dns servers after connection goes down]

Status: RESOLVED FIXED

(Core :: Networking, defect, P5)

Description

[sgenchev]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Ubuntu package 1.0.7)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Ubuntu package 1.0.7)

 If I bring up another connection that adds entries to my /etc/resolv.conf while
Firefox running, Firefox will pick up new DNS server(s) and will start using
them to do a name resolution. When connection goes down though, Firefox will not
stop using now invalid DNS entries and would try to resolve everything using
them. Only after DNS request times out Firefox starts using other DNS servers.
 This will happen with any DHCP-enabled connection. At least in my case it
happens when I bring up and then down VPN connection or wired connection while
wireless connection is running.
 Restarting firefox fixes the problem.

Reproducible: Always

Steps to Reproduce:
1. Establish a network connection, bring up Firefox
2. Bring up another connection
3. Browse to a new host to make Firefox resolve new entry
4. Bring connection down
5. Fire up your favorite sniffer to observer port 53 traffic

Actual Results:  
 Firefox sends DNS queries to a non-valid-any-more DNS server(s)

Expected Results:  
 Firefox should stop trying to use DNS server that is no longer in  /etc/resolv.conf

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this a problem in Gecko 1.8 or current trunk?  Gecko 1.7 is ancient...

Comment 2

[Darin Fisher]

This is a bug with GLIBC.  Please file it against them.  We try to workaround the buggy behavior of the GLIBC by calling res_ninit whenever we detect a lookup failure, but this doesn't help in the case you describe.  Unless we were to call res_ninit (which causes GLIBC to re-read /etc/resolv.conf) before every lookup, I'm not sure how we would cope with this problem.

This issue is not Mozilla 1.7 specific.  It should still happen w/ trunk builds.

Confirming bug, but this is probably INVALID since there's not much we can do but hope that GLIBC will one day do the right thing.

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

that's not quite true. once we have the autodetect on/offline code checked in, we can call res_ninit whenever an offline->online change is detected.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

(that can be done irrespective of manageOfflineStatus)

Comment 5

[Darin Fisher]

> that's not quite true. once we have the autodetect on/offline code checked in,
> we can call res_ninit whenever an offline->online change is detected.

Yes, good idea.  We already shutdown the DNS service when going offline, and we re-initialize it when we go online.  We should make DNS service initialization call res_ninit.

Comment 6

[Darin Fisher]

OK, morphing the bug...

Comment 7

[Darin Fisher]

Attachment: v1 patch

This seems to do the trick.  I don't want to call res_ninit during startup, so I've made this code call res_ninit during the initialization of subsequent "DNS services."  Actually, the code change is in nsHostResolver.cpp, but there is a 1-1 relationship between nsDNSService and nsHostResolver.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

should the DNS service also observe "network:link-status-changed" and call res_ninit whenever the link status changes?

Comment 9

[Darin Fisher]

(In reply to comment #8)
> should the DNS service also observe "network:link-status-changed" and call
> res_ninit whenever the link status changes?

No need.  The IO service will shutdown and initialize the DNS service in response to that event.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

only if manageOfflineState is true, right?

Comment 11

[Darin Fisher]

> only if manageOfflineState is true, right?

Yup, but that should be the default mode of operation.

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #11)
> > only if manageOfflineState is true, right?
> 
> Yup, but that should be the default mode of operation.

Yes, but if that is set to false and something else manages it, that has no way to trigger a res_ninit call, right? (Other than calling setOffline/setOnline...)

Comment 13

[Darin Fisher]

> Yes, but if that is set to false and something else manages it, that has no way
> to trigger a res_ninit call, right? (Other than calling
> setOffline/setOnline...)

Right.  I think that's reasonable.  Anyways, the idea here is really just to re-initialize GLIBC when the nsDNSService is re-initialized.  I think that makes sense independent of online/offline toggling.

Comment 14

[Darin Fisher]

fixed-on-trunk