Quoting Hendrik Boom (hend...@topoi.pooq.com): > I'll look for the various programs mentioned here, and see if they are > present on my system...
Realistically, they won't be unless you put them there. (I've long tried to gently poke Linux users, and indeed Linux distributions, into ceasing to outsource recursive DNS nameservice to strangers, as running a local recursive daemon is an easy and trouble-free improvement -- but it's a long campaign and people are lazy.) > But I'm starting to suspect that part of the problem is that too many > programs cache the dns, and once they have something wrong, they hang > onto it. They often do. You had in /etc/nsswitch.conf: hosts: files mdns4_minimal [NOTFOUND=return] dns This says: To resolve hostnames, first look in /etc/hosts, then consult muticast DNS (typically the avahi daemon or nss-mdns), then consult recursive DNS via the relevant lines in /etc/resolv.conf that specify what recursive nameservers to offload queries to. I personally don't trust multicast DNS (Zeroconf aka Rendezvous aka Bonjour) even a tiny bit. You can read about it here: 'ZeroConf' on http://linuxmafia.com/kb/Network_Other/ Avahi is maintained by Lennart Poettering. Me, I'd ditch multicast DNS, but you be the judge. Maybe you use it for autodiscovering printers, and such. (I don't like machines autodicovering and autoconfiguring to talk to each other across networks. If I want to print to a print queue, I'll go into http://127.0.0.1:631/ and tell my system about it.) In your /etc/resolv.conf, you had: nameserver 8.8.8.8 nameserver 8.8.4.4 Those are the IP addresses of Google Public DNS. Whatever your system has for multicast DNS probably does caching (if such software is present), Googple Public DNS most certainly does caching, and whatever application software is attempting to resolve DNS (you didn't specify) may well be also doing caching. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
