Verizon email problems

[bscott at ntisys.com]

On 12 Nov 2003, at 2:20pm, jbd at codemeta.com wrote:
>>   Okay, things are looking better.  Reverse DNS for 199.232.38.4 now comes 
>> back with a valid, if possibly non-standard, response:
> 
> Has this been true all along?

  Well, what has been true is that, if you traced the delegation path for
<4.38.232.199.in-addr.arpa.> (the reverse lookup name for 199.232.38.4), you
eventually got to NIC.CENT.NET, which was responding with the following
resource record:

	4.38.232.199.in-addr.arpa.	CNAME	4.threeofus.com.

  However, the authoritative nameservers for <threeofus.com> would respond
with NXDOMAIN when asked about <4.threeofus.com.>.  So, reverse lookup was
not working, but it appeared that Joshua S. Freeman had been given the
control that was needed to make it work.

  (I've never seen a lookup for an "*.in-addr.arpa" name respond with a
CNAME with a RHS that was not also a subdomain of <in-addr.arpa> before.  
Thinking about it, that should work just like a CIDR delegation.  I'm not
sure, though, and I don't have the time to check the RFCs right now.  But it
does appear to work for BIND and Linux, at least.)

  A very useful idiom when checking reverse lookups is

	dig +trace -x 199.232.38.4

The "-x" is a dig shortcut that turns an IP address into a "in-addr.arpa"  
name.  The "+trace" tells dig to trace and print the delegation path, from
the root servers on down.

-- 
Ben Scott <bscott at ntisys.com>
| The opinions expressed in this message are those of the author and do  |
| not represent the views or policy of any other person or organization. |
| All information is provided without warranty of any kind.              |