Thanks once again to all for their help. I received a number of useful
replies, but special thanks to Arthur Hyan for assistance
above-and-beyond the call.
First, my original post:
>
> I think I have done everything that should be needed to support reverse
> DNS queries to my site, and yet when I try to (for example) ftp to
> ftp.uu.net, they still complain that they can't do a reverse lookup on
> me. Someone suggested to me that the problem may be that some
> intermediate routing site is blocking the queries through over-zealous
> filtering.
>
> 1) Is such a thing possible?
>
> 2) Is yes, is there some reasonable way to figure what device along the
> communications path is doing this?
>
> [FWIW: I base my conclusion that I've done what I have to on the fact
> that nslookups using any of the authoritative servers for my domain
> correctly return either a name or address as appropriate based on my
> input. It is entirely possible that I have an overly simplistic idea of
> what is required - what I know is nicely summarized in ORA's "DNS and
> BIND", so if it ain't in there I'm at a loss. I am by no means a
> grognard on this kind of stuff!]
Suggestions were made to look at the following:
1) Confirm that any changes to my db files had been accompanied by
incrementing the serial # in the SOA record and followed by HUPing the
named process. (Not the problem.)
2) Make sure our firewall wasn't filtering out DNS packets. (It wasn't)
3) Make sure that name --> IP resolution was properly delegated back to
us (it is - this is actually the reverse of the problem we're having).
4) Make sure that IP --> name resolution was properly delegated back to
us - BINGO!
To explain (since I just learned this):
It is possible to file two different registration forms with the
Internic - one says that "nameserver <blah> is authoritative for domain
<mydomain>". This allows your nameserver to be the final authority on
translating "foo.mydomain" into an IP address for the rest of the world.
We had correctly done this long ago. What we had NOT apparently done
is file the second reg form (the so-called in-addr.arpa reg form) which
says "nameserver <blah> is authoritative for network <IPaddr>". This is
the form which authorizes your site respond correctly to reverse DNS
lookups.
As a result, when someone out in the world asked "Who is IPAddr
a.b.c.d?", the root nameserver went "Dunno. Don't know who is in charge
of that network. Go away." The way that I eventually confirmed this
was to get out dig (nslookup would have also worked) and set dig to use
my name server to resolve the domains firstfloor.com (us) and sun.com (a
domain I expected would be correctly set up). Then I set dig to use
a.root-servers.net to resolve the query and did the same thing. Since
both runs gave the same result I figured this part was set up correctly.
Next, I did the same kind of test, but this time looked up
a.b.c.in-addr.arpa, where a.b.c was alternately our network and Sun's.
When I used Sun, I got back a list of nameservers that were obviously
run by Sun and/or their secondary nameservers. When I did ours, I got
back a response showing only the root nameserver and an error that it
couldn't find anything else of interest. This led me back to Internic
who emailed me the proper form.
----------
Doug Stein Voice: 415-968-1101
FirstFloor Software, Inc. Fax: 415-968-1193
444 Castro Street, Suite 200 Email: dstein@firstfloor.com
Mountain View, CA 94041 Web: http://www.firstfloor.com
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:56 CDT