Re: Flushing the DNS cache?
Daniel Pittman <[email protected]>
| Newsgroups | gmane.comp.web.opera.linux |
|---|---|
| Organization | I know I put it down here, somewhere. |
| Message-ID | <[email protected]> |
"Herman Robak" <[email protected]> writes: > On Tue, 16 Dec 2008 05:46:08 +0100, Daniel Pittman <[email protected]> wrote: > >> Specifically, when I work inside the network a DNS lookup of >> www.example.com returns a private 192.168.0.0 address, while a DNS >> lookup outside their network returns the routable Internet address. >> >> As far as I can tell Opera is caching these DNS results, even if the >> local DNS resolver, etc, is returning the right stuff, and the only way >> I can find to flush that cache is to restart opera. >> >> Is this the expected behaviour, and if so, is there any way to disable >> the DNS cache in Opera[1], or to flush it automatically or manually? > > Yes, this is the expected behaviour, and so far there is no way to > disable it. It's a defense against DNS rebinding attacks(*). Well, bother. Does this cache respect the DNS TTL for records, or is it a Windows style "cache the address *forever*" solution? > We are looking into ways to present information about what is going on > to the user. Users who are frequently in the situation you describe > either have a serious network problem (which should be fixed) I am not quite sure what you see as a serious network problem here; perhaps you can expand on that? > or an odd environment (which they can work around explicitly). I don't know that split-horizon DNS is all that odd, honestly, since it has been the deployment method of choice within many, probably even most, of the large corporate networks I have worked on or in. Your suggested "explicit work-around", of ignoring the different DNS responses and hard-coding the address of the service, is also unlikely to work where split-horizon networks are used: typically the public address isn't accessible to clients inside the network, for one reason or another.[1] (Notably, as recently as November 2007, and possibly more recently, Paul Vixie and other DNS experts were strongly recommending split-horizon DNS for internal vs external services, as per RFC1918) On the other hand, yes, using a laptop that travels between multiple sites that are on different sides of the split-horizon of various DNS servers is probably less common. Part of why I wondered about an explicit flush of the DNS cache was that I can manually perform that when I know, as a human, that the network has changed and the cache is no longer valid. On the gripping hand, I *suppose* that could be a path to a social engineering attack, which would be suboptimal. Hmm. Given that the problem with DNS rebinding is related to changing the current network, would it be likely that Opera would consider subscribing to DBus notifications from NetworkManager, and flushing the DNS cache when the network status changed? As per the API documentation[2] it should be practical to discover that a network device has deactivated or activated; this would correlate with a change in network configuration outside Opera. Flushing the DNS cache would, in that case, seem to make sense to me. It wouldn't be possible for a hostile script within the browser to cause an external network event along those lines, and it would resolve the issue. Finally, is this something that should be followed up through some other medium, such as a bug report? I presume not, at least at this stage, but I am happy to file a report if it helps. Regards, Daniel Footnotes: [1] We have also used these, in production, to allow global roaming of staff within our 15K person network, such that the communicated with the closest available server in a globally coherent pool. This was effective and significantly improved staff satisfaction, but would run afoul of the same DNS rebinding issue. :/ [2] http://people.redhat.com/dcbw/NetworkManager/NetworkManager%20DBUS%20API.txt -- Opera-Linux: https://list.opera.com/mailman/listinfo/opera-linux More lists: https://list.opera.com/mailman/listinfo/ Unsubscribe: mailto:[email protected]?subject=unsubscribe