...and sorry for not stating it before.....these are Windows 2003 SP2 DNS
servers.

On Thu, Apr 9, 2009 at 7:33 AM, Sean Martin <[email protected]> wrote:

>  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