Understanding reverse DNS better

Larry Smith lesmith at ecsis.net
Tue Jan 25 14:47:09 UTC 2011


I use Squish (www.squish.net/dnscheck) for this purpose.  Reasonable
web interface and gives lots of info about where things are breaking
down...

-- 
Larry Smith
lesmith at ecsis.net

On Tue January 25 2011 08:38, p8x wrote:
> +1, also a quick check to make sure your name servers are actually set
> can be done with host..  host -t ns 0.168.192.in-addr.arpa
>
> On 25/01/2011 10:34 PM, Jared Mauch wrote:
> > I suggest doing something like:
> >
> > dig +trace -x 204.42.254.5
> >
> > You can watch the delegation authority for the in-addr at each stage.
> >
> > - Jared
> >
> > On Jan 25, 2011, at 9:30 AM, Caleb Tennis wrote:
> >> We have a /24 from one of our upstream providers that we handoff to a
> >> customer.  The /24 has been SWIPd to us, and we have nameservers setup
> >> with ARIN against that record.
> >>
> >> Twice now this information has just "disappeared".  That is, if do
> >> reverse DNS lookups, they returns nothing, whereas they were just
> >> working fine earlier.  If you do an NS lookup on the block, it returns
> >> nothing.  The /24 blocks immediately surrounding us continue to work
> >> just fine.  If we do a lookup directly against our nameserver, it works
> >> just fine.
> >>
> >> It's like the nameserver information against that reverse DNS is just
> >> magically gone.
> >>
> >> The ARIN record looks good, nothing has changed. Last time, our upstream
> >> resubmitted the info so it would repopulate, and it started working
> >> again soon there after.  I admit to not being the smartest one with how
> >> these records work: is the problem with the upstream, or ARIN's
> >> database, or is there not enough information to tell?
> >>
> >> Thanks,
> >> Caleb




More information about the NANOG mailing list