On Tue, Apr 7, 2009 at 2:48 PM, Sean Martin <[email protected]> wrote:
> I'm first trying to determine the legitimacy of the e-mail.
Examine the RFC-822 headers, specifically the "Received:" headers.
Look to see what server *your* server got the message from.
But the claims in the email seem to be true, and none of the links
or instructions are suspicious. I'd say it's legit.
> ... it appears that we're claiming we own an entire 16 bit address
> space, which we don't.
The way I read it, they're giving you a common cause of this sort of
trouble, not a specific diagnosis for this situation. So that may not
apply.
> We do own the address space 208.69.196.0 - 208.69.199.255
The "dig" utility from the ISC BIND distribution kit (available for
Win32 these days) is enormously useful for these sorts of situations.
Specifically, you'd want:
dig +trace @a.root-servers.net. -x 208.69.196
That will trace the delegation chain all the way from the root
nameservers. The "-x" means do the reverse lookup for an IP address.
I find that ARIN has delegated 208.69.196.0/22 to two nameservers:
ns1.alaskausa.org.
ns2.alaskausa.org.
Both of those nameservers, when queried about that IP address space,
return NXDOMAIN (non-existent domain). That may be what ARIN is upset
about.
Nominally, PTR records map IP addresses back to forward domain
names. If all those IP addresses have corresponding forward names,
add the PTR records. This I've done before and can help you with.
If those IP addresses don't have corresponding names, I don't know
what the right thing to do is. I've never had to worry about that.
FWIW, this is prolly addressed in RFC-1035 or one of it's many
follow-on updates.
http://tools.ietf.org/html/rfc1035
-- Ben
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
