Previous 1 2 3 Next 31 Replies Latest reply: Mar 3, 2008 2:40 PM by aBarbieri
aBarbieri Level 1 Level 1

I'm quite puzzled... I noticed a constant low bandwidth traffic on the WAN port of the router and tracked it back to the MacOS X (10.5.2) host constantly DNS querying for (about every three seconds). I am using DHCP and the network configuration picks up the external DNS server.

I thought this localhost information should be picked up directly from /etc/hosts (in my case)
cat /etc/hosts
# Host Database
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
## localhost broadcasthost
::1 localhost
fe80::1%lo0 localhost

and there should be no need to ask for this reverse DNS name resolution to the external DNS server.

do I really have to use dscl and create an entry for localhost to stop this DNS querying activity?


MacMini G4 1.5GHz, Mac OS X (10.5.2)
Solved by Snoop Dogg on Mar 3, 2008 12:44 PM Solved
Yeah, I think the problem is that your machine is sending the dns-bug-test query to your router's DNS proxy at, but then the query is being incorrectly forwarded along to your ISP's DNS server of, and then your ISP's DNS server is correctly responding with NXDOMAIN but the NAT translator is not translating the source IP address of the response, so it reaches mDNSResponder with an apparent source IP address of, and mDNSResponder rejects it because it looks like a spoofed response. So two separate bugs in your router are causing this. As you've discovered, you can work around this by setting your machine's DNS server to, thus bypassing the DNS proxy in your router.
Reply by Snoop Dogg on Mar 3, 2008 12:05 PM Helpful
Hi aBarbieri, you're correct that this query is being generated by mDNSResponder. It's not actually querying for, it's doing a special bogus query to detect if you own a buggy router. The test looks like this.*dig ptr*Buggy routers will respond with "localhost" to the above query. The correct response is NXDOMAIN because that name doesn't really exist in DNS.Can you look in system.log and post all messages that contain "mDNSResponder"?

All replies

  • xnav Level 5 Level 5
    What do you get if you use Utilities>NetworkUtility>Lookup on Do you have the tools to tell if this query goes out on the WAN?

    When I trace it on my system it does go out to the WAN DNS server.

    Message was edited by: xnav
  • aBarbieri Level 1 Level 1
    The router syslog facility reports:
    <150>Mar 2 23:24:56 Vigor: Local User: DNS -> inquire

    and the Activity Monitor Network graph does show a constant low level activity when none should happen.

    this is what 'dig' has to say:
    dig -x

    ; <<>> DiG 9.4.1-P1 <<>> -x
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1668
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ; IN PTR

    ;; ANSWER SECTION: 0 IN PTR localhost.

    ;; Query time: 27 msec
    ;; SERVER:
    ;; WHEN: Sun Mar 2 23:30:56 2008
    ;; MSG SIZE rcvd: 63

    and this is 'host':
    host domain name pointer localhost.

    and Network Utility -> Lookup:
    Lookup has started ... 0 IN PTR localhost.

    the point is all of these reverse name resolutions should not be forwarded to the DNS server but resolved internally (from /etc/hosts)...

    if we had the old nsswitch.conf the hosts entry would have read:
    hosts: files dns
    to take care of all of this automatically.
  • aBarbieri Level 1 Level 1
    and tcpdump reports:
    tcpdump -A -n -i en0 port 53
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on en0, link-type EN10MB (Ethernet), capture size 96 bytes
    00:01:51.873347 IP > 13522+[|domain]
    00:01:51.889664 IP > 13522 NXDomain[|domain]
    00:01:54.873113 IP > 13523+[|domain]
    00:01:54.889388 IP > 13523 NXDomain[|domain]
    00:01:57.872864 IP > 13524+[|domain]
    00:01:57.888922 IP > 13524 NXDomain[|domain]
    00:02:00.873402 IP > 13525+[|domain]
    00:02:00.889180 IP > 13525 NXDomain[|domain]
    00:02:03.872666 IP > 13526+[|domain]
    00:02:03.891466 IP > 13526 NXDomain[|domain]
    00:02:06.872956 IP > 13527+[|domain]
    00:02:06.888972 IP > 13527 NXDomain[|domain]
    00:02:09.872419 IP > 13528+[|domain]
    00:02:09.890732 IP > 13528 NXDomain[|domain]
    14 packets captured
    60 packets received by filter
    0 packets dropped by kernel

    pretty clear that the entry in /etc/hosts is unfortunately not used.

    localhost and are part of the loopback interface (lo0) and a lookup from /etc/hosts should suffice! no reason at all to query a DNS service unless explicitly specified.
  • xnav Level 5 Level 5
    Leopard really uses etc/resolv.conf, mainly because of DHCP. Unless this file has a entry in it then etc/hosts will not be used. Your real issue is that some process is polling for no apparent reason. Can you determine who the culprit is?

    +man resolver+
    +man resolver -S 5+

    Message was edited by: xnav
  • aBarbieri Level 1 Level 1
    /etc/resolv.conf is used for different purposes, see resolver (5), and not just because DHCP is involved. you can't specify as nameserver in /etc/resolv.conf unless you are running a DNS service like named on the same very host.

    the point is that any forward query for localhost and reverse query for must really make use of /etc/hosts and not the resolver (which in turns will use what /etc/resolv.conf says).

    lsof -n -i
    SystemUIS 129 ab 10u IPv4 0x207c5f8 0t0 UDP :
    ARDAgent 26074 ab 17u IPv4 0x207d1c8 0t0 UDP *:net-assistant
    AppleVNCS 26114 ab 4u IPv6 0x2081d90 0t0 TCP *:vnc-server (LISTEN)
    PubSubAge 44150 ab 8u IPv4 0x3070270 0t0 TCP> (ESTABLISHED)
    PubSubAge 44150 ab 9u IPv4 0x3a7c270 0t0 TCP> (ESTABLISHED)

    netstat -a -f inet
    Active Internet connections (including servers)
    Proto Recv-Q Send-Q Local Address Foreign Address (state)
    tcp4 0 0 ESTABLISHED
    tcp4 0 0 ESTABLISHED
    tcp4 0 0 ESTABLISHED
    tcp46 0 0 *.vnc-server . LISTEN
    tcp4 0 0 *.kerberos . LISTEN
    tcp4 0 0 *.ssh . LISTEN
    tcp4 0 0 *.microsoft-ds . LISTEN
    tcp4 0 0 *.netbios-ssn . LISTEN
    tcp4 0 0 *.afpovertcp . LISTEN
    tcp4 0 0 localhost.ipp . LISTEN
    udp4 0 0 *.ipp .
    udp4 0 0 . .
    udp4 0 0 *.net-assistant .
    udp4 0 0 .
    udp4 0 0 .
    udp4 0 0 .
    udp4 0 0 localhost.ntp .
    udp4 0 0 *.ntp .
    udp4 0 0 .
    udp4 0 0 *.netbios-dgm .
    udp4 0 0 *.netbios-ns .
    udp4 0 0 *.mdns .
    udp4 0 0 . .

    it's quite hard to inspect a process at the right time to catch the DNS query unless one already knows what to look for.

    it seems more and more unfortunately the job for dscl to provide a workaround (more of a bug to me)
  • aBarbieri Level 1 Level 1
    an update...

    using dscl to create a localhost/ entry does not work.

    also noticed I have not specified anywhere the IP address of the DNS server used in these periodic DNS queries. The OS seems to actively query for it directly from the router itself. That IP address is indeed the Primary DNS server address. I wonder now if this is a 'new' Bonjour or UPNP Leopard feature since all of this disappears when I boot back into Tiger 10.4.11 (same network configuration though).
  • xnav Level 5 Level 5
    The polling is not happening on my Leopard system. Perhaps on your Tiger you don't see it because it is being resolved via hosts.
  • aBarbieri Level 1 Level 1
    using tcpdump with the system booted with Tiger I do see just two reverse dns queries for and that's all (so no lookup from /etc/hosts either).

    I suspect strongly now mDNSResponder (Bonjour) or UPNP and the interaction with the router itself.
  • xnav Level 5 Level 5
    I don't understand why on Leopard the query is not handled from cache. If dscacheutil is available on Tiger, try clearing the cache and see if you get another query that goes WLAN?
  • aBarbieri Level 1 Level 1
    because, as I mentioned in my preview post, this behaviour could very well be related to the new (i.e in Leopard 10.5.x) functionality which does not exist in Tiger (all of the DS tools do not exist in Tiger neither). already reported that the dscl (and dscacheutil) trick doesn't make a difference.

    Since I am not providing the IP address directly I believe Leopard queries the router and extracts the Primary DNS server IP address (and indeed is such value). This seems to be Bonjour (mDNSResponder) or kernel related mainly because even when I switch off UPNP services on the router (a Draytek V2900VG) the situation does not improve.

    I suspect my only alternative now is to play with different router brands and see what happens.
  • xnav Level 5 Level 5
    So, is not in your Leopard resolv.conf, put there by DHCP processing?

    What happens if you enter:
    dscacheutil -q host -a ip_address
    on Leopard?

    Message was edited by: xnav
  • aBarbieri Level 1 Level 1
    both Tiger and Leopard network configurations are identical (wired ethernet and wifi). either cases have the IP address of the router as gateway and DNS server.

    I don't believe it is the DHCP protocol that informs the MacOS kernel to use the primary DNS server IP address used by the router. My Vista laptop uses the same DHCP configuration (to obtain local IP address, gateway and DNS IP addresses) and it obtains the same gateway and DNS IP addresses (router IP address).

    in the MacOS cases (Tiger and Leopard) /etc/resolv.conf only contains one nameserver entry and that value is the router IP address (not, the primary DNS server on the router -- the router actually operates a forward only DNS service and the first forwarder is such IP address).

    so... only when Leopard (10.5.2 to be precise) is involved I start to see this wrong behaviour. seems more and more a bug in Leopard.
  • xnav Level 5 Level 5
    OK, but in your case, it was DHCP processing that put your router's IP address into resolv.conf. Did you try the cache query from my post above?
  • aBarbieri Level 1 Level 1
    OK, but in your case, it was DHCP processing that put your router's IP address into resolv.conf.

    yes (as explained before)

    Did you try the cache query from my post above?

    yes, tried it too on Leopard as mentioned before when talking about the failure of using the ds cli tricks as workaround.
Previous 1 2 3 Next