[135499] in North American Network Operators' Group
Re: Understanding reverse DNS better
daemon@ATHENA.MIT.EDU (Hank Nussbacher)
Wed Jan 26 00:37:26 2011
Date: Wed, 26 Jan 2011 07:37:16 +0200
To: Larry Smith <lesmith@ecsis.net>,nanog@nanog.org
From: Hank Nussbacher <hank@efes.iucc.ac.il>
In-Reply-To: <201101250847.10034.lesmith@ecsis.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
At 08:47 25/01/2011 -0600, Larry Smith wrote:
>I use Squish (www.squish.net/dnscheck) for this purpose. Reasonable
>web interface and gives lots of info about where things are breaking
>down...
Seems to be having issues:
Finding servers for . from A.ROOT-SERVERS.NET (198.41.0.4)
Error: Resolve for NSs of . to A.ROOT-SERVERS.NET (198.41.0.4)
failed: query timed out
-Hank
>--
>Larry Smith
>lesmith@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
