For future reference:

OS X:

/private/etc/opt/cisco-vpnclient/Certificates

/etc/CiscoSystemsVPNClient/Certificates

Linux:

/etc/opt/cisco-vpnclient/Certificates

Windows:

C:\Program Files\Cisco VPN Client\Certificates

“Profiles” and “Certificates” folders can be copied/moved between different systems to replicate configuration when there are CA limitations or restrictive policies on certificate export/imports.

…and I’m having a ball…

I hate to have it getting the time and date reset to something in the past (can’t find any pattern on the new date/time) everytime I drop it in the dock and sync. This happens when iTunes is left open when the computer goes to sleep or hibernates (and closing iTunes before sleeping does the trick). It has been like this since forever, there are people reporting the issue since September 2007 (video). Why hasn’t this been fixed?

I hate to have it performing a device backup which takes forever and which I’ll probably never have a chance to actually use and not having a straight way to disable it without messing around. Bastards.

I hate to downloading 250 megs of firmware updates every 2 weeks (currently 2.0.2, released a couple of hours ago, downloading over 3G as we speak), checking the release notes and saying these are just “bug fixes”. Which ones? Fix the damn thing, will you?

A company with a market cap of over $150 billion should actually listen to the customers, right?

And don’t get me started on the interface. The user interface is brilliant if you’re planning to use it as a webpad, PDA, mobile phone, gaming console, show-off thingie, whatever. If you want to use it to listen to music, it’s terrible, it’s cumbersome, it’s annoying. One of the killer features of the “classic” iPods was ease of use, the simple (yet powerful, for a MP3 player) of the interface. Scroll wheel for changing the volume and… uh… scrolling. Simple menu structure. Easy to operate the device without actually looking at it (or having it inside a pocket, for instance). One actual “lock” button that “works”. Do I need to shell out $20 to get a remote and have it working properly?

For those with ADD: Why, oh why does leopard insist on storing entries on its DNS cache with TTL=3600 when the DNS proxy is sending them with TTL=0?

For everyone else: I’m testing DSL routers. One of the “nice” features to have in such a device is something that stands between the DNS clients (computers connected to the LAN ports) and the DNS server (usually provided by the network). This is usually called a DNS proxy or DNS relay and will (hopefully, in decent implementations), if the DSL connection is down, translate every single request to an internal/private/reserved IP address. If the user is using a browser, the www.whatever.com DNS query returns the mentioned IP address instead of the real one and the HTTP request will land on the router itself, which will politely say “your connection is down, go get a towel or something”. Aditionally, the router will send the DNS answer time-to-live to something real low (zero, preferably, so the “fake” DNS entry doesn’t get stored in local DNS caches).

So far so good.

Eventually, DSL connections go up. Sometimes they don’t (but that’s not my problem).

Should the DSL connection go up again, the router will probably fetch a working DNS server from the network and start resolving DNS correctly. End of story.

***Except*** there seems to be something essentially wrong with Leopard (I’m hearing people grinning and whispering “eh, don’t get me started…”).

A quick search on Google returns a few hundred hits on people whining about Leopard’s DNS implementation and the fact that it’ll take a few dscacheutil -flushcache iterations a day to clean the cache from DNS lookup failures (due to unresponsive DNS servers, for instance). Those error entries get marked with a big YES on dscacheutil -cachedump -entries “Neg” column. And they’ll probably have some sort of dealing up with that clutter. Not the issue here.

There’s another issue I won’t bother to go into right now, but is slightly related. Most entries on the cache show up has having TTL=3600 when the DNS server is sending values far above that (12 or 24 hours, just to name a few – I’ve got the packet captures to show it). The sentence “Why would someone want to store a DNS cache entry for so many time” makes some sense to me, but it would be nice if the operating system just did as it’s being told.

Which brings “the” problem here (my problem, at least – but JP mentioned a similar behavior around the time I first noticed the issue on my equipment): Leopard is storing entries with a TTL of 3600 (seconds) for entries that were sent with TTL=0. The DNS relay is saying “don’t cache this entry” but Leopard insists on doing so – and for an hour or something. dscacheutil -flushcache will fix it, but this is plainly annoying.

Here’s the DNS response from the DSL modem on Wireshark:

Windows’ ipconfig /displaydns listing (showing no trace of the google.com entry):

Last but not least, the Leopard dscache -cachedump -entries listing with a glorious TTL=3600:

No sight of similar problems on the Ubuntu installation I tried. Pedro confirmed me minutes ago that Tiger behaves slightly better than Leopard and honors the TTL=0, keeping these records away from the cache (as it should).

Now could someone do something about this? I just did. Filed bug #5711166 and became a Mac Geek, according to Rui. Why do I have a feeling I’ll regret this? ;)

(Update: this issue has been fixed on the Mac OS X 10.5.3 Server update. Not bad.)