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:
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
Matthew F. Ringel wrote: 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