REVERSE DNS Practices.
Tom Wright
twright at internode.com.au
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
More information about the NANOG
mailing list