It's been awhile since I've had to really dive into DNS.

>From what I can tell, most of the host records do have a PTR record as well.
However, I'm unsure about how the reverse lookup zone was created. There's a
single reverse lookup zone 69.208.in-addr.arpa. Beneath that, there are
folders for 196, 197, 198, 199. I'm assuming these folders were created
automatically when a PTR record was created in that range. Could this be the
reason for the e-mail? There doesn't appear to be a way to specify the zone
as 208.69.0.0/22. Should I create separate reverse lookup zones for each
class C range?

- Sean

On Tue, Apr 7, 2009 at 3:30 PM, Ben Scott <[email protected]> wrote:

> 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/>  ~
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to