Tunnelblick should flush DNS cache after connected/disconnected

[GoogleCodeExporter]

Mac OS X's built-in VPN client does flush the cache.

Original issue reported on code.google.com by yaohua2...@gmail.com on 2 Jul 2010 at 4:58

[GoogleCodeExporter]

I gather it should be done in the up and down scripts. That being the case, it 
is relatively easy for users to add it themselves. I don't know enough about 
the consequences and/or side effects to know if it should be added to the 
standard Tunnelblick scripts.

Note: there is some disagreement on the web about how to flush the cache on 
different versions of OS X. Some say "lookupd -flushcache" works up through 
10.5.1, others say 10.5.0 and up require "dscacheutil -flushcache".

Original comment by jkbull...@gmail.com on 2 Jul 2010 at 9:03

[GoogleCodeExporter]

I'm pretty sure 10.5.0 and above should be using dscacheutil. If you do add it, 
you could first check for dscacheutil, and then fall back to lookupd, and then 
to nothing.

Really no big negatives to using it. All it does is make the system forget all 
the lookups that have been done that haven't already expired.

Original comment by batman...@gmail.com on 3 Jul 2010 at 9:18

[GoogleCodeExporter]

batmanppc's suggestion to use dscacheutil if it exists, fall back to lookupd, 
and then fall back to nothing is a good idea.

I've though some more about where this should be done. It doesn't belong in the 
down script, because the down script is only run if the user checks "Set 
nameserver" (and the VPN server "pushes" DNS changes).

So I think it should go in the program itself, with a per-connection? 
preference to disable it.

I'm still a bit leery of doing this, since the dscacheutil entry for 
-flushcache says "This should only be used in extreme cases." But I think I'll 
put it in the beta and see if anybody has problems.

Original comment by jkbull...@gmail.com on 6 Jul 2010 at 2:37

[GoogleCodeExporter]

Per connection as a preference seems like the logical place. Not sure it should 
be enabled by default. I would consider it an 'advanced' feature that someone 
should enable if they needed it.

Here is the case where a user would need this (I use it daily with my 
connections):
* machine.foo.com resolves to x.x.x.x when on the public internet
* machine.foo.com resolved to y.y.y.y when on VPN

OR (happens sometimes only)

* machine.vpn.foo.com is only resolvable behind VPN but I tried to access it 
when the VPN isn't up
* OS X now has the resolve failure cached and so it continues to fail until I 
flush the DS cache

Original comment by batman...@gmail.com on 7 Jul 2010 at 12:50

[GoogleCodeExporter]

To deal with your last example, we need to flush when the tunnel is opened, 
too, not just when it is closed.

When, exactly, should the flush occur? For closing, it should be after the 
system has been restored to its normal state; that's pretty easy -- do it after 
the OpenVPN process exits. On opening, it should be done after the VPN has been 
completely set up.

I've tried flushing (dscacheutil falling back to lookupd). It seems to work OK 
on Snow Leopard (Intel), but on Tiger (PPC) (which Tunnelblick still supports), 
it causes a warning message from OpenVPN of "Workaround Bonjour: Unknown error: 
0". Looking up that error message on the Internet, it seems to be either (A) 
innocuous, or (B) causes a 60-second delay in "something". In my experiments on 
Tiger, it doesn't seem to interfere with web browsing (which is all I've 
tested).

Aside from that issue, I guess I would say "what's the harm"? Might as well 
make it the default. (Although it isn't clear to me exactly what flushing the 
"DS" cache is, compared to flushing the "DNS" cache.)

Thoughts?

Original comment by jkbull...@gmail.com on 7 Jul 2010 at 1:34

[GoogleCodeExporter]

My tests show there isn't much time penalty flushing the cache -- most times 
were under 100 ms on a Mac Mini (1.66 GHz Intel Core Duo) and under 350 ms on 
an old iBook (333 MHz PPC).

So it's not like it adds much latency. (The connection process takes about 9 
seconds, disconnections take about 3 seconds, so this is a pretty small 
addition.)

Original comment by jkbull...@gmail.com on 7 Jul 2010 at 2:14

[GoogleCodeExporter]

On my setup I flush both on connection setup and tear down.

You're right. I guess making it default doesn't hurt anything. (DS meant 
DirectoryService which is what's doing the caching-- dscacheutil doesn't only 
flush the DNS portion of the cache; it's all of Directory Service's cache)

Original comment by batman...@gmail.com on 7 Jul 2010 at 4:12

[GoogleCodeExporter]

Done in r930: DS cache is flushed after connection is made and after it is torn 
down, unless the per-connection preference XXX-doNotFlushCache is true (XXX is 
the configuration's display name).

Original comment by jkbull...@gmail.com on 7 Jul 2010 at 4:53

[GoogleCodeExporter]

Original comment by jkbull...@gmail.com on 7 Jul 2010 at 4:53

• Changed state: Fixed

[GoogleCodeExporter]

There is one side effect from flushing the resolver cache that Tunnelblick 
should especially consider.

As you may know, mDNSResponder has undertaken the role of the system resolver 
in 10.6, so it does both unicast and multicast DNS. Therefore doing 
'dscacheutil -flushcache' flushes also the mDNS cache. When using a bridged 
openvpn connection, mDNS also runs on tap0 (that didn't work in the past, but 
all issues seem to have been resolved). mDNSResponder adds records to the mDNS 
cache in the order the corresponding advertisements appear. No filtering, 
sorting or prioritization is performed.

Now consider this scenario: Two Macs are on the same LAN (Ethernet or Wi-Fi). 
They have discovered each other, adding the respective records to their mDNS 
cache. They both connect to a bridged openvpn service, so they discover each 
other on a second broadcast domain. Again the respective records are added to 
their mDNS cache. This means mDNSResponder has now cached multiple A and/or 
AAAA records for the other Mac. When answering a query for the other Mac's 
hostname, the records are returned in the order they were added to the cache.
So far so good: The records resolved on the first LAN will *usually* be 
returned first, since they have been added first to the cache. Bonjour-assisted 
traffic between the two Macs will therefore stay on the first LAN.
However if the cache is flushed when tap0 comes up, mDNSResponder removes 
cached records and then re-adds them along with new records resolved on tap0. 
In my experience these records are *usually* added first; this is what happens 
most often, but not always (it is not deterministic). In such a case, traffic 
between the two Macs will thereafter prefer the bridged openvpn connection, 
which is usually not what you want.

See this thread regarding mDNSResponder behavior:
http://lists.apple.com/archives/bonjour-dev//2011//Jan/msg00004.html

I understand there are valid reasons for flushing the resolver cache upon 
connecting to the VPN. I also understand the above is quite a corner case, not 
very likely for most users to come across. I realize that not flushing the 
cache is only a workaround for the behavior of mDNSResponder, which is not 
really predictable in a multi-homed environment. Therefore while I can not 
suggest that flushing the resolver cache by default should be reconsidered, I 
think it may be a good idea for the preference to be added to the GUI 
('Details' window) and to be documented along with this potential side-effect.

Original comment by zmo...@gmail.com on 7 Jan 2011 at 6:07

[GoogleCodeExporter]

Documenting the side effect is a good idea; I'll add your explanation of the 
behavior.

However, it isn't clear to me how often this sort of situation occurs -- this 
is the first I've heard of it. So at this time I don't want to add it to the 
GUI, which is already crowded.

If there is a big response that it should be in the GUI, I'll be glad to 
reconsider.

Question: Does OS X's built-in VPN clients still flush the cache (see the first 
comment)? Do they offer an option to disable the flush?

Original comment by jkbull...@gmail.com on 7 Jan 2011 at 6:18

[GoogleCodeExporter]

Regarding the frequency of appearance of this issue:

I have tested mDNSResponder behavior in different multi-homed environments, 
e.g. using en1 (Airport) instead of tap0 as the second broadcast domain. 
Whenever the second interface comes up but the cache is not flushed, all is 
well: the first interface to come up prevails and it is usually the interface I 
would rather use for such local traffic. When the cache is flushed (triggered 
by Tunnelblick), most often (but not always) mDNSResponder behaves as reported 
and therefore tap0 prevails.

The behavior is rather simple to reproduce: connect two Macs to the same 
bridged openvpn service, after which you will notice increased latency/reduced 
throughput once you try to use Bonjour discovered/addressed services. See my 
earlier post about this:
http://groups.google.com/group/tunnelblick-discuss/browse_thread/thread/bf21de1a
2e1365f5

As for the MacOS built-in client, unfortunately I don't know the answers.

You are probably right about the GUI addition; personally I would have no 
objection anyway as long as there are other means to control this behavior.

Original comment by zmo...@gmail.com on 7 Jan 2011 at 8:15

[GoogleCodeExporter]

I just saw these last few posts again.

Flushing the DNS cache (or not) is a checkbox on the "Advanced" settings tab.

It has been available for some time -- since r1510 on 2011-06-06 and 3.2beta16 
(2011-06-24).

Original comment by jkbull...@gmail.com on 17 Jun 2013 at 2:56