From owner-freebsd-stable Sun Oct 10 5: 8: 7 1999 Delivered-To: freebsd-stable@freebsd.org Received: from enya.clari.net.au (enya.clari.net.au [203.8.14.116]) by hub.freebsd.org (Postfix) with ESMTP id 06ABE1591A for ; Sun, 10 Oct 1999 05:05:46 -0700 (PDT) (envelope-from danny@freebsd.org) Received: from localhost (danny@localhost) by enya.clari.net.au (8.9.2/8.9.1) with ESMTP id WAA38431 for ; Sun, 10 Oct 1999 22:05:44 +1000 (EST) (envelope-from danny@freebsd.org) X-Authentication-Warning: enya.clari.net.au: danny owned process doing -bs Date: Sun, 10 Oct 1999 22:05:44 +1000 (EST) From: "Daniel O'Callaghan" X-Sender: danny@enya.clari.net.au To: freebsd-stable@freebsd.org Subject: Bug in DNS implementations? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been trying to track down a problem with reverse DNS lookups on a 3.1 system most of the day, and I may have found it. Has anyone else seen this? The rev DNS for the box is handled by an NT machine, 5.6.7.1, and this box is 5.6.7.190. For some reason 190 could never reverse lookup its own or other IPs in 5.6.7. I started mucking around with nslookup, on .190 and on other machines. 3.1 # nslookup Default Server: localhost Address: 127.0.0.1 > server server1.567.com.au. Default Server: server1.567.com.au Address: 5.6.7.1 > ls 7.6.5.in-addr.arpa. > /tmp/7 [server1.techinfo.com.au] ### Received 168 answers (0 records). <<<<--- note zero records > ls 7.6.5.in-addr.arpa. > /tmp/7 [server1.techinfo.com.au] ### Received 168 answers (0 records). <<<<---- again, same result # cat /tmp/7 [server1.567.com.au] # ---- On a 2.2.8 machine, which runs bind 4.9.x, the results were more as expected: > ls 7.6.5.in-addr.arpa. > /tmp/7 [server1.567.com.au] ### Received 168 answers (168 records). <<<<--- that's better. --- I tried it on 3.2 and got the same result as on 3.1 - probably bind 8 talking to NT problem. Curiously, named on 3.1 was quite happy to secondary the zone, so it appears to be a resolver issue, not named itself. Has anyone seen this problem before? I'm happy to do tcpdumps etc for anyone who wants to investigate this properly. Danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message