Michael D. Berger posted on Wed, 31 Aug 2011 17:31:08 +0000 as excerpted:
> My original observation is in error as you will see.
>
> Actually, I first edited /etc/ntp.conf to have use my local time server
> first, and then tock.usno.navy.mil. This time I had WireShark running
> when I first brought up System Settings > Computer Administration
> section > Date and Time. Merely bringing it up results is a barrage of
> weird dns queries. Two I saw this time is "settings-personal.desktop"
> and "settings-system.desktop".
> Is you might expect, dns responded "No such name".
> These things stop and then repeat every now and then.
> On the Date and Time gui, if I uncheck and recheck "Set date and time
> automatically" with my local url entered and selected, I do get a
> correct ntp transaction.
>
> I now see that the odd dns activity is not specifically related to Date
> and Time, but occurs when I click and of various options. Why is this?
I am by no means an expert on this, and don't run CentOS, but from the
description and what I know (and perhaps what I only think I know =:^P ),
it /looks/ to me like EITHER something's misconfigured and you're getting
dbus queries on the IP network as DNS queries, OR you're mistaking
routine dbus query traffic for DNS.
Because those weird names look very much like traffic that I'd suppose
would be dbus based, and dbus traffic does occur over a socket altho at
least here it's a UNIX socket, not IP (but perhaps it can be IP for
network transparency? actually, it appears it can according to the dbus-
daemon (1) manpage). If they're somehow going out as DNS queries, that
is quite disturbing indeed, but if instead, you're somehow mistaking dbus
traffic for DNS, and/or if your wireshark sniffer net is set too broadly
so it's catching both, that would explain the whole otherwise rather
disturbing indeed situation.
Qt has a GUI-based dbus interface browsing tool, qdbusviewer (part of the
qt-gui package here on Gentoo, likely part of the general qt4 package on
most distros), that you can use to explore a bit, altho I don't imagine
you'll see any *.desktop filenames there, but maybe you'll see something
that you can connect with the sniffing you're doing, and getting more
informed about dbus can't hurt even if it doesn't turn up anything
related to this.
You can also try using netstat (and/or checking the config) to see what
dbus sockets are being used, and see if that corresponds to what wireshark
is reporting.
Also, if you have any sort of remote-X desktop stuff going on, it could
be related to that.
That's about all I can suggest ATM, but this discussion is rather
interesting (as in disturbing!) indeed. I do hope you post what's going
on when you get to the bottom of this, as the potential of this sort of
information leakage occurring has security and privacy implications I
don't particularly like, but at the same time, I find it hard to believe
it's by design or could be easily overlooked, so something's GOTTA be
seriously screwed somewhere, either in your config or in your detection
methods, one of the two, and I really HOPE it's your detection methods,
because the alternative really IS quite disturbing, to the point I'll
certainly find it easier to sleep when I know that all this is resolved.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
