[Opera-Linux] Flushing the DNS cache?

[Daniel Pittman]

"Herman Robak" <herman at opera.com> writes:
> On Tue, 16 Dec 2008 05:46:08 +0100, Daniel Pittman <daniel at rimspace.net> 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