[135429] in North American Network Operators' Group
Re: Understanding reverse DNS better
daemon@ATHENA.MIT.EDU (Caleb Tennis)
Tue Jan 25 09:45:31 2011
From: Caleb Tennis <caleb.tennis@gmail.com>
In-Reply-To: <AE81CBB4-6CE4-484C-BE53-FA96D29A28F2@puck.nether.net>
Date: Tue, 25 Jan 2011 09:44:37 -0500
To: Jared Mauch <jared@puck.nether.net>
Cc: North American Network Operators Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Excellent, the +trace option is most helpful, thank you.
On Jan 25, 2011, at 9:34 AM, Jared Mauch wrote:
> I suggest doing something like:
>=20
> dig +trace -x 204.42.254.5
>=20
> You can watch the delegation authority for the in-addr at each stage.
>=20
> - Jared
>=20
> On Jan 25, 2011, at 9:30 AM, Caleb Tennis wrote:
>=20
>> 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.
>>=20
>> 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.
>>=20
>> It's like the nameserver information against that reverse DNS is just =
magically gone.
>>=20
>> 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?
>>=20
>> Thanks,
>> Caleb
>=20
