646670 - DNS cache conflicts with VPN on Mac and PC

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Jesse Costello-Good]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/533.20.25 (KHTML, like Gecko) Version/5.0.4 Safari/533.20.27
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

Imagine you have a service that is available both inside and outside of your company's intranet. You have a private DNS entry in your intranet DNS that points to the intranet machine. You have a public DNS entry that points to the internet machine. Perhaps you have some or all of the functionality of the intranet machine proxied via the internet machine. 

If you have such a set up and you use VPN to connect to the network, you want to reach the intranet machine whenever you are on the VPN and you want to reach the internet machine whenever you are not on the VPN. 

The bug in the Firefox DNS cache is that it does not expire entries when connecting or disconnecting to the VPN. So, when you connect to the VPN for about 5 minutes you still get the public DNS entry and go to the internet machine. When you disconnect from the VPN for about 5 minutes you still get the private DNS entry and all your requests hang since the IP is not reachable. 

I've tested this most extensively in Mac OS X and it is certainly an issue in Firefox and not the OS. "dig" from the Terminal immediately knows the correct DNS entry when connecting/disconnecting from the VPN. Moreover, Safari does not exhibit the incorrect behavior. IMO there is no reason to implement a DNS cache in Mac OS X since there is an operating system level DNS cache. 

Reproducible: Always

Steps to Reproduce:
1. Create two DNS entries for the same host name. One is a public DNS entry and one is private to your intranet. 
2. From outside your intranet, access the host in Firefox. 
3. Connect to your intranet via VPN
4. Reload the page in Firefox 
Actual Results:  
For about 5 minutes you are still directed to host with the public DNS record.

Expected Results:  
You should immediately be directed to the host with the private/intranet DNS record. 

Related to: 512969, 629830, 461221, 338822, 628561

Comment 1

[Boris Zbarsky [:bzbarsky]]

Our DNS cache does things the OS one doesn't do (e.g. cache which IP addresses for the hostname are dead).

It does sound like we should be clearing the DNS cache when the network settings change, though.

Comment 2

[Patrick McManus [:mcmanus]]

(In reply to comment #1)
> It does sound like we should be clearing the DNS cache when the network
> settings change, though.

yeah... iirc we actually try, though I've noted that "when the network settings change" can be a hard thing for us. when time allows I'll look into it because robust network change detection is something I would like as a hook for the pipeline pretest.

Comment 3

[Patrick McManus [:mcmanus]]

I think this can be closed due to bagder's work..

Comment 4

[--]

Yeps, this is all functionality that we have landed a while ago.