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 reverselist (such as reserved0, reserved31, reserved32, reserved255), althoughyou will *never* have them in the A records (I always add a remindercomment 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 boundaryrouters! 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 thoughthe forward side hosts don't exist (yet). Security folks sometimesworry that makes scanning targeting easier, but arguably similar effortto 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:
- Re: REVERSE DNS Practices., (continued)
- Re: REVERSE DNS Practices. bmanning (Mar 21)
- Re: REVERSE DNS Practices. jamie rishaw (Mar 21)
- Re: REVERSE DNS Practices. Tom Wright (Mar 22)
- Re: REVERSE DNS Practices. Luke S Crawford (Mar 28)
- Re: REVERSE DNS Practices. William Pitcock (Mar 28)
- RE: REVERSE DNS Practices. Frank Bulk (Mar 21)
- Re: REVERSE DNS Practices. Steven Champeon (Mar 23)
- Re: REVERSE DNS Practices. Mark Tinka (Mar 21)
- Re: REVERSE DNS Practices. Matthew F. Ringel (Mar 24)
- Re: REVERSE DNS Practices. William Allen Simpson (Mar 24)
- Re: REVERSE DNS Practices. Tom Wright (Mar 25)
- Re: REVERSE DNS Practices. Steven Champeon (Mar 25)
- Re: REVERSE DNS Practices. Martin Barry (Mar 26)
- Re: REVERSE DNS Practices. Steven Champeon (Mar 26)
- Re: REVERSE DNS Practices. Adrian Chadd (Mar 26)
- Re: REVERSE DNS Practices. Steven Champeon (Mar 26)
- Re: REVERSE DNS Practices. Tom Wright (Mar 26)
- Re: REVERSE DNS Practices. Steven Champeon (Mar 26)
- Re: REVERSE DNS Practices. Steven Champeon (Mar 27)