nanog mailing list archives
Re: REVERSE DNS Practices.
From: William Allen Simpson <william.allen.simpson () gmail com>
Date: Tue, 24 Mar 2009 13:42:53 -0400
Matthew F. Ringel wrote:
Derivability: Being able to synthesize the name with a few pieces ofdata 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.
Current thread:
- Re: REVERSE DNS Practices., (continued)
- Re: REVERSE DNS Practices. bruce (Mar 21)
- 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. bruce (Mar 21)
- 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)