Search Again:

Re: Reverse DNS

From: Men & Mice Support
Date: Saturday, October 30, 1999
Time: 9:00:00 pm

At 11:32 AM -0700 10/30/99, Warren Michelsen wrote:
>At 11:05 AM -0700 10/30/99, Men & Mice Support wrote:
>>
>>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.
>
>How so. Please elaborate.

If ni.net is az.net's provider, then your provider's provider (a) has screwed up their own reverse (and that of their customers), and (b) can't delegate the class C, because it's delegated directly to them by atmnet.net.

The ideal solution to this would be to talk to atmnet.net. Unfortunately, since in this scenario az.net is not atmnet.net's customer, atmnet.net may not want to talk to them.

I see by a traceroute that the path appears to be:
good.net (who are they?)



Messages In This Thread:



Return to Digital Point Solutions' Home Page