 |  |
At 10:41 AM -0700 10/30/99, Warren Michelsen wrote:
Re: Reverse DNS
From: Men & Mice Support
Date: Saturday, October 30, 1999
Time: 6:05:00 pm
>Back in July when I moved my servers to a new colo provider I right
>away picked up on the fact that their reverse DNS was not working
>right. Only people using their name server (209.75.187.135) actually
>got results. They had previously thought everything was working fine
>because they all use their own name servers. They do have their end
>configured properly as near as I can tell but their DNS is not
>authoritative for their class C (I think).
>
>I pointed this out to them and urged them to get it fixed. They
>haven't yet. Their Hostmaster says the problem is with ARIN. I did
>what little investigating I could and thought the bottleneck was
>imi.net or some-such. (it's been a while.) I have a range of
>addresses in the same class C and all I know is that they're
>supposed to be providing reverse DNS for me and they aren't.
>
>Would one of you folks be able to tell me just who has to do what to
>get authority for reverse DNS for that particular class C assigned
>to the people using it? I'd like to light a fire under their
>hostmaster but I'd like to know more than I do about just what the
>heck needs to be done.
Here's the delegation:
from f.root-servers.net:
75.209.in-addr.arpa. NS ns1.atmnet.net.
75.209.in-addr.arpa. NS ns2.atmnet.net.
from ns1.atmnet.net:
187.75.209.in-addr.arpa. NS ns1.ni.net.
187.75.209.in-addr.arpa. NS ns2.ni.net.
Note that this says that ni.net is responsible for the class C. A query sent to either ns1.ni.net or ns2.ni.net returns a non-authoritative answer, making this a lame delegation.
from ns1.az.net (209.75.187.135):
187.75.209.in-addr.arpa. NS ns1.az.net.
187.75.209.in-addr.arpa. NS ns1.conx.net.
They need to talk to atmnet.net regarding this issue. Hopefully, atmnet.net is their provider; if their provider is ni.net, this could be ugly.
By the way: All of this was discovered using DNS Expert's DNS Query tool. The same thing could be done with nslookup or any other digging tool, so long as the tool tells you when a response is non-authoritative.
It would appear that az.net has your reverse records properly configured, so at least you don't have to worry about getting a classless subnet delegation. Given that your provider can't figure out their own reverse zone problems, they would probably have a hard time figuring out RFC 2317.
Good luck.
____________________________________________________________________
Chris Buxton cbuxton@menandmice.com
Men & Mice http://www.menandmice.com
Makers of: QuickDNS Pro
Messages In This Thread:
Return to Digital Point Solutions' Home Page
| home | |
| products | |
| services | |
| support | |
| email lists |
| optigold isp | |
| optigold isp news | |
| home inspection | |
| inspectrix | |
| java companion | |
| oracle | |
| quickdns pro | |
| search engine | |
| veterinary |
| tips | |
| employees | |
| free tools | |
| portfolio | |
| jobs | |
| contact |
888/4-DPOINTSupport:
858/452-3696