[Dnsmasq-discuss] Re: Mac client constant reverse query on itself

Eddy Geez eddygeez at gmail.com
Fri Feb 27 14:59:51 GMT 2009


On Thu, 26 Feb 2009 09:29:31 -0500, I wrote:
> Rune Kock wrote:
>> Setting the local-ttl option might help.
>
> seems to have resolved the problem! I set this to 3600 (one hour) and
> the persistent queries from the Macs and iPhones stopped once dnsmasq
> was restarted. Woo-hoo!

After checking the "overnight logs", it now appears that the PTR
queries have been reduced in frequency from 10-15 seconds to exactly
10 minutes. Not sure why it isn't one hour (3600 seconds) since that
is what I have the "local-ttl" setting at. But every 10 minutes I get
6 (!) back-to-back PTR queries from each Mac for its own IP address.

On Thu, 26 Feb 2009 09:17:33 -0500, B. Cook wrote:
> I reported something like this some time ago as well; no one seemed to
> care then either ;)

I think I found your post in the dnsmasq archives when I was searching
for solutions to the constant logging from Macs a couple weeks ago. I
was bummed that there weren't any replies.

> Feb 26 08:30:18 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> 199.10.168.192.in-addr.arpa from 192.168.10.198
> Feb 26 08:30:18 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> 199.10.168.192.in-addr.arpa from 192.168.10.198
> Feb 26 08:30:20 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> 199.10.168.192.in-addr.arpa from 192.168.10.198

This set of entries happened at the same time. What is delta between
sets of PTR queries? For example, if you ran:

grep "PTR.*192.168.10.198" /var/log/dnsmasq [or wherever your log file is]

how much time lapses between each set of queries?

> This also comes from the 10.5 laptop (but not the server..)
> Feb 26 08:33:07 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> b._dns-sd._udp.0.10.168.192.in-addr.arpa from 192.168.10.199
> Feb 26 08:33:07 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> db._dns-sd._udp.0.10.168.192.in-addr.arpa from 192.168.10.199
> Feb 26 08:33:07 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> r._dns-sd._udp.0.10.168.192.in-addr.arpa from 192.168.10.199
> Feb 26 08:33:07 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> dr._dns-sd._udp.0.10.168.192.in-addr.arpa from 192.168.10.199
> Feb 26 08:33:07 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> lb._dns-sd._udp.0.10.168.192.in-addr.arpa from 192.168.10.199
> Feb 26 08:33:07 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> b._dns-sd._udp.tcentral.lan from 192.168.10.199
> Feb 26 08:33:07 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> db._dns-sd._udp.tcentral.lan from 192.168.10.199
> Feb 26 08:33:07 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> r._dns-sd._udp.tcentral.lan from 192.168.10.199
> Feb 26 08:33:07 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> dr._dns-sd._udp.tcentral.lan from 192.168.10.199
> Feb 26 08:33:07 <local5.debug> bacula dnsmasq[32374]: query[PTR]
> lb._dns-sd._udp.tcentral.lan from 192.168.10.199

For what it's worth, I see similar queries every 40 minutes from Macs
on our network.

I believe these are related to Bonjour, and are multicast DNS (mDNS) /
DNS-SD (DNS Service Discovery) messages.

see "man dns-sd" for the dns-sd diagnostic tool. You can watch these
events by running:

dns-sd -B <type>

in a Terminal window, where <type> is "_afpovertcp._tcp" for AFP,
"_daap._tcp" for iTunes shares, etc. If you omit type you'll see
"_http._tcp" entries, and if you have TiVo's or other devices that
advertise web-based services via Bonjour, you'll see those. (You can
open these Bonjour bookmarks in Safari by doing "Show All Bookmarks"
and then clicking on the "Bonjour" entry in "Collections.)

Out of curiosity, I noticed that you are forwarding these queries:

> Feb 26 08:33:07 <local5.debug> bacula dnsmasq[32374]: forwarded
> lb._dns-sd._udp.tcentral.lan to 10.20.0.16

to an (apparently) real name server. I have an entry like:

local=/localnet/

in my conf file so that queries for localnet are never forwarded to a
real name server. Instead, dnsmasq returns "NXDOMAIN" without
forwarding.



More information about the Dnsmasq-discuss mailing list