constant DNS querying for 127.0.0.1

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.

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.

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

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

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.

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.

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.

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.