Date: Thu, 14 Aug 1997 07:37:18 -0400 (EDT) From: Brian Clapper <bmc@WillsCreek.COM> To: Charles Owens <owensc@enc.edu> Cc: questions@freebsd.org Subject: Re: fw natd and failed double reverse DNS lookups Message-ID: <199708141137.HAA01943@current.willscreek.com> In-Reply-To: <15317291@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708141137.HAA01943>