REVERSE DNS Practices.

Wed Mar 25 23:56:59 UTC 2009

Don't be afraid to create zones for each
location, DNS lends itself to this kind of
hierarchy naturally.

I find this is tidier than lengthy A records.

I.e, hostname.location.domain

This also makes your zones a little more
manageable (although on all accounts, some
simple automation will ensure happiness forever
more).

I guess I'm speaking more from an ISP point of
view.

On 25/03/2009, at 4:12 AM, William Allen Simpson wrote:

> Matthew F. Ringel wrote:
>> Derivability: Being able to synthesize the name with a few pieces of
>> data makes naming and debugging easier.
> I agree.  Remember, this is mostly going to show up in log files, and
> they need to be easily skimmed by even the newest staff.
>
>
>> Longer is okay: Barring software limitations on name length, a longer
>> name is not a problem if a person knows that they're going to get it
>> right on the first try.  We used CNAMEs if we wanted abbreviations.
> Clarity and consistency are paramount!
>
> I'm of the mind that you (we) should always setup the reverse *first*
> for each block.  Only after that's propagated, then add the A records
> and CNAMEs.
>
> When you change from dynamic or unused assignments to static or a
> specific customer domain, update the reverse *first*, then the A or
> CNAME.  The reverse lists become your assurance that you haven't
> accidentally added duplicate assignments.
>
> Another hint (from the days we had a lot of directed broadcast  
> attacks):
> indicate never used addresses and broadcast addresses in the reverse
> list (such as reserved0, reserved31, reserved32, reserved255),  
> although
> you will *never* have them in the A records (I always add a reminder
> comment line on the forward side).  That makes them stand out in the  
> log.
>
> Don't forget to block (and log) your reserved addresses at your  
> boundary
> routers!  A script to check the ACL against the reverse DNS is good,
> although many routers will handle this semi-automatically now.
>
> So, you'll have a fully defined and propagated reverse list, even  
> though
> the forward side hosts don't exist (yet).  Security folks sometimes
> worry that makes scanning targeting easier, but arguably similar  
> effort
> to ping those addresses will yield similar results.
>
> It's most important for security to document the vulnerabilities
> (reverse addresses help with self-documentation).  Sometimes, folks
> deliberately hide their systems in a sparsely populated block of fully
> defined reverse addresses.
>
>

-- 
Kind Regards,

Tom Wright
Internode Network Operations
P: +61 8 8228 2999
W: http://www.internode.on.net