nanog mailing list archives

Re: REVERSE DNS Practices.


From: Tom Wright <twright () internode com au>
Date: Thu, 26 Mar 2009 10:26:59 +1030

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



Current thread: