From owner-freebsd-questions Thu Aug 14 04:38:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA12429 for questions-outgoing; Thu, 14 Aug 1997 04:38:01 -0700 (PDT) Received: from BIGFUN.vwcom.com ([151.197.101.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA12424 for ; Thu, 14 Aug 1997 04:37:59 -0700 (PDT) Received: from WillsCreek.COM (gw.willscreek.com [151.197.101.46]) by BIGFUN.vwcom.com (8.8.6/8.8.6) with ESMTP id HAA03933; Thu, 14 Aug 1997 07:32:56 -0400 (EDT) Received: from current.willscreek.com (root@current.willscreek.com [172.16.87.1]) by WillsCreek.COM (8.8.5/8.7.3) with ESMTP id HAA21257; Thu, 14 Aug 1997 07:37:20 -0400 (EDT) Received: (from bmc@localhost) by current.willscreek.com (8.8.5/8.7.3) id HAA01943; Thu, 14 Aug 1997 07:37:18 -0400 (EDT) Date: Thu, 14 Aug 1997 07:37:18 -0400 (EDT) Message-Id: <199708141137.HAA01943@current.willscreek.com> From: Brian Clapper MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Charles Owens CC: questions@freebsd.org Subject: Re: fw natd and failed double reverse DNS lookups In-Reply-To: <15317291@toto.iv> X-Mailer: VM 6.23 under Emacs 19.34.1 Sender: owner-freebsd-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Charles Owens wrote: > Consider a configuration where natd on a firewall server provides the NAT > function between a private network and the Internet. Suppose a client on > the private net opens an ftp connection to an ftp server on the Internet. > Thanks to natd, is it not true that the ftp server will be 100% convinced > that the ftp client is the firewall _itself_? And, that, if proper > forward and reverse DNS records exist for the firewall, if the server > insists on doing double reverse DNS lookups it will be satisfied? That is 100% correct. > This makes pretty clear sense to me... am I missing something? If so, > what is the optimum way to satisfy these reverse lookups in the NAT > situation I describe? > > I thought that I had this all sorted out, but in my testing I've run > across some ftp sites (ftp.tis.com, for example) for which connections > from my NAT'd clients fail, with the server claiming that reverse lookups > failed. First, try making an ftp connection from the firewall *itself*. If you get the same error from ftp.tis.com (or ftp.uu.net -- another good one to try), then the remote ftp server cannot resolve your *firewall* machine's address to a name. If that's the case, natd has nothing to do with it. Next, log onto a machine *outside* your domain and use `dig' or `nslookup' to do a reverse lookup against your firewall machine's address (i.e., against the `in_addr.arpa' name corresponding to your firewall's IP address). If it fails, do a reverse lookup for the SOA record to see what machine is responsible for that `in_addr.arpa' domain. Possibilities: 1. The address won't resolve, but you get *your* SOA record for the `in_addr.arpa' domain. Problem: Your DNS isn't properly handling reverse lookups. Solution: Fix your DNS. 2. The address won't resolve, and you *don't* get yo ur SOA record for the `in_addr.arpa' domain. Possible problem: Your provider hasn't delegated your class C address to you in their DNS. I've seen this happen a lot. A firm contracts with a network provider for connectivity. The provider allocates the firm a class C address from the provider's CIDR block, but they neglect to delegate the corresponding `in_addr.arpa' domain to the firm. Solution: Contact your network provider and request that they properly delegate the `in_addr.arpa' reverse-lookup domain for your class C address. ----- Brian Clapper, bmc@WillsCreek.COM, http://WWW.WillsCreek.COM/ Like so many Americans, she was trying to construct a life that made sense from things she found in gift shops. -- Kurt Vonnegut, Jr.