Previous 1 2 3 Next 31 Replies Latest reply: Mar 3, 2008 2:40 PM by aBarbieri
aBarbieri Level 1 Level 1 (0 points)
Hello,

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 127.0.0.1 (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.
##
127.0.0.1 localhost
255.255.255.255 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?

andrea

MacMini G4 1.5GHz, Mac OS X (10.5.2)
  • xnav Level 5 Level 5 (6,635 points)
    What do you get if you use Utilities>NetworkUtility>Lookup on 127.0.0.1? 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 (0 points)
    The router syslog facility reports:
    <150>Mar 2 23:24:56 Vigor: Local User: 192.168.21.100 DNS -> 62.31.176.39 inquire 127.0.0.1

    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 127.0.0.1

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

    ;; QUESTION SECTION:
    ;1.0.0.127.in-addr.arpa. IN PTR

    ;; ANSWER SECTION:
    1.0.0.127.in-addr.arpa. 0 IN PTR localhost.

    ;; Query time: 27 msec
    ;; SERVER: 192.168.21.1#53(192.168.21.1)
    ;; WHEN: Sun Mar 2 23:30:56 2008
    ;; MSG SIZE rcvd: 63


    and this is 'host':
    host 127.0.0.1
    1.0.0.127.in-addr.arpa domain name pointer localhost.

    and Network Utility -> Lookup:
    Lookup has started ...

    1.0.0.127.in-addr.arpa. 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 (0 points)
    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 192.168.21.100.5353 > 192.168.21.1.53: 13522+[|domain]
    E..YO..........d.......5.EnB4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:01:51.889664 IP 62.31.176.39.53 > 192.168.21.100.5353: 13522 NXDomain[|domain]
    E....A@.....>..'...d.5.....S4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:01:54.873113 IP 192.168.21.100.5353 > 192.168.21.1.53: 13523+[|domain]
    E..Yd..........d.......5.EnA4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:01:54.889388 IP 62.31.176.39.53 > 192.168.21.100.5353: 13523 NXDomain[|domain]
    E....B@.....>..'...d.5.....R4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:01:57.872864 IP 192.168.21.100.5353 > 192.168.21.1.53: 13524+[|domain]
    E..YT6.........d.......5.En@4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:01:57.888922 IP 62.31.176.39.53 > 192.168.21.100.5353: 13524 NXDomain[|domain]
    E....C@.....>..'...d.5.....Q4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:02:00.873402 IP 192.168.21.100.5353 > 192.168.21.1.53: 13525+[|domain]
    E..Y)..........d.......5.En?4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:02:00.889180 IP 62.31.176.39.53 > 192.168.21.100.5353: 13525 NXDomain[|domain]
    E....D@.....>..'...d.5.....P4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:02:03.872666 IP 192.168.21.100.5353 > 192.168.21.1.53: 13526+[|domain]
    ..........d.......5.En>4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:02:03.891466 IP 62.31.176.39.53 > 192.168.21.100.5353: 13526 NXDomain[|domain]
    E....E@.....>..'...d.5.....O4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:02:06.872956 IP 192.168.21.100.5353 > 192.168.21.1.53: 13527+[|domain]
    E..Y.(.........d.......5.En=4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:02:06.888972 IP 62.31.176.39.53 > 192.168.21.100.5353: 13527 NXDomain[|domain]
    E....F@.....>..'...d.5.....N4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:02:09.872419 IP 192.168.21.100.5353 > 192.168.21.1.53: 13528+[|domain]
    E..Y!..........d.......5.En<4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    00:02:09.890732 IP 62.31.176.39.53 > 192.168.21.100.5353: 13528 NXDomain[|domain]
    E....G@.....>..'...d.5.....M4............1.0.0.127
    dnsbugtest.1.0.0.127.in-addr.ar
    ^C
    14 packets captured
    60 packets received by filter
    0 packets dropped by kernel


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

    localhost and 127.0.0.1 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 (6,635 points)
    Leopard really uses etc/resolv.conf, mainly because of DHCP. Unless this file has a 127.0.0.1 entry in it then etc/hosts will not be used. Your real issue is that some process is polling 127.0.0.1 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 (0 points)
    /etc/resolv.conf is used for different purposes, see resolver (5), and not just because DHCP is involved. you can't specify 127.0.0.1 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 127.0.0.1 must really make use of /etc/hosts and not the resolver (which in turns will use what /etc/resolv.conf says).

    lsof -n -i
    COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
    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 192.168.21.100:50731->12.129.147.65:http (ESTABLISHED)
    PubSubAge 44150 ab 9u IPv4 0x3a7c270 0t0 TCP 192.168.21.100:51471->84.53.177.24:http (ESTABLISHED)

    and
    netstat -a -f inet
    Active Internet connections (including servers)
    Proto Recv-Q Send-Q Local Address Foreign Address (state)
    tcp4 0 0 192.168.21.100.52499 217.243.192.18.http ESTABLISHED
    tcp4 0 0 192.168.21.100.51471 84.53.177.24.http ESTABLISHED
    tcp4 0 0 192.168.21.100.50731 12.129.147.65.http 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 192.168.21.100.netbios .
    udp4 0 0 192.168.21.100.netbios .
    udp4 0 0 192.168.21.100.ntp .
    udp4 0 0 localhost.ntp .
    udp4 0 0 *.ntp .
    udp4 0 0 192.168.21.100.kerbero .
    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 (0 points)
    an update...

    using dscl to create a localhost/127.0.0.1 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 (6,635 points)
    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 (0 points)
    using tcpdump with the system booted with Tiger I do see just two reverse dns queries for 127.0.0.1 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 (6,635 points)
    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 (0 points)
    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 62.31.176.39 IP address directly I believe Leopard queries the router and extracts the Primary DNS server IP address (and indeed 62.31.176.39 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 (6,635 points)
    So, 62.31.176.39 is not in your Leopard resolv.conf, put there by DHCP processing?

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

    Message was edited by: xnav
  • aBarbieri Level 1 Level 1 (0 points)
    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 62.31.176.39, 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 (6,635 points)
    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 (0 points)
    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