Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

constant DNS querying for 127.0.0.1

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)

Posted on Mar 2, 2008 6:50 AM

Reply
31 replies

Mar 2, 2008 3:38 PM in response to xnav

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.

Mar 2, 2008 4:12 PM in response to xnav

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.

Mar 2, 2008 4:37 PM in response to aBarbieri

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

Mar 2, 2008 4:50 PM in response to xnav

/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)

Mar 3, 2008 4:52 AM in response to aBarbieri

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).

Mar 3, 2008 7:40 AM in response to xnav

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.

Mar 3, 2008 8:13 AM in response to xnav

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.

constant DNS querying for 127.0.0.1

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.