[Qt-interest] DNS caching in Qt

Thiago Macieira thiago at kde.org
Wed Jul 6 11:15:50 CEST 2011


Em Wednesday, 6 de July de 2011, às 13:51:55, Mandeep Sandhu escreveu:
> Hi All,
> 
> We recently ran into a problem where we were accessing a network
> resource but the DNS lookup of the host was continuously failing.

Please check if the DNS server is at fault. Many years ago, we had a very ugly 
problem with a faulty firmware in a very popular CPE router in Germany and the 
manufacturer refused to fix. Later, when Safari was affected by the same 
problem, they finally fixed it.

> The problem used to happen when we tried to access the URL for the
> first time while the network was not connected (cable unplugged). At
> this time the connection used to fail as expected.

Right.

> Now, after the network interface is up (i.e after the cable is
> plugged-in, NM gets an IP and configures the interface), if we try to
> access the same URL 'quickly', i.e very little time difference between
> the interface coming up and the app trying to access the URL, we used
> to see the DNS lookup failing continuously.

There are two reasons for this problem. The first is local caching done by the 
application and the second is bad DNS configuration.

QHostInfo does cache results, but I don't remember how it does negative 
caching (i.e., cache a "doesn't exist" result). Assume it also caches negative 
results for the same amount of time.

It's clear, however, that caching of results is a violation of DNS rules, 
since they don't respect the TTL. But this is a place where proper correctness 
is not possible: the application needs to cache in order to have a responsive 
browsing experience.

> If we keep pressing the key which initiates the n/w request, it would
> keep on failing. However, if we wait for around 30 secs and then
> access the URL the lookup used to succeed.
> 
> I had some questions regarding this behaviour:
> 
> * Are DNS lookup failures cached too or only successful resolutions cached?

I don't see anything in the code that would indicate that negative results are 
treated specially. So I guess they are cached.

> * I had read in the comment of a bug-report on the Qt bug tracker,
> that on Linux, Qt invalidates the cache the moment 'resolv.conf' is
> updated. Is this the case? I'm asking this because when this problem
> was happening, I had checked the resolv.conf and it was having proper
> entries. More so, I could manually do a lookup of the hostname that
> was failing and it used to work (all along, the Qt lookup kept
> failing). Even manually updating resolv.conf's timestamp did no help.

I can't find the code to do that either. 

Can you try to touch /etc/resolv.conf when the application isn't finding the 
hostname and check if it changes behaviour?

If it doesn't, please file a bug report.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110706/ca3bed6d/attachment.bin 


More information about the Qt-interest-old mailing list