Securing DNS and BIND
Our secure DNS service, trapped in its padded cell and very particular about what it says to whom, is shaping up nicely. But what about the actual zone databases?
The good news here is that since our options are considerably more limited than with named.conf, there's less to do. The bad news is that there's at least one type of Resource Record that's both obsolete and even dangerous, and must be avoided by the security-conscious.
Here's a sample zone file for the hypothetical domain “boneheads.com” (see Figure 4.)
The first thing to consider is the Start-of-Authority (SOA) record. In the above example, the serial number follows the convention yyyymmdd##, which is both convenient and helps security, as it reduces the chances of accidentally loading an old (obsolete) zone file—the serial number serves as both an index and a time stamp.
The refresh interval is set to three hours, a reasonable compromise between bandwidth conservation and paranoia. That is, the shorter the refresh interval, the less damage a DNS-spoofing (cache-poisoning) attack can do, since any “bad records” propagated by such an attack will be corrected each time the zone is refreshed.
The expiry interval is set to two weeks. This is the length of time the zone file will still be considered valid, should the zone's master stop responding to refresh queries. There are two ways a paranoiac might view this parameter. On one hand, a long value ensures that should the master server be bombarded with denial-of-service attacks over an extended period of time, its slaves will continue using cached zone data and the domain will continue to be reachable (except, presumably, for its main DNS server!). But on the other hand, even in the case of such an attack, zone data may change, and sometimes old data causes more mischief than no data at all.
Similarly, the Time to Live interval should be short enough to facilitate reasonably speedy recovery from an attack or corruption, but long enough to prevent bandwidth cluttering. (The TTL determines how long the individual zone's Resource Records may remain in the caches of other name servers retrieving them via queries.)
Our other concerns in this zone file have to do with minimizing the unnecessary disclosure of information. First, we want to minimize aliases (“A records”) and canonical names (“CNAMEs”) in general, so that only those hosts who need to be are present. (Actually, we want split DNS, but when that isn't feasible or applicable, we should still try to keep the zone file sparse.)
Second, we want to minimize the amount of (recursive) glue-fetching that goes on. This occurs when a requested name-server (NS) record contains a name whose IP address (via an A record) is not present on the server answering the NS query. In other words, if server X knows that Y is authoritative for domain WUZZA.com but X doesn't actually know Y's IP address, life can get weird: this scenario paves the way for DNS-spoofing attacks. Therefore, if you really want to eliminate all recursion (and I hope you do by now), make sure none of your Resource Records require recursive glue-fetching, and then set the “fetch-glue” option to “no”.
Finally, we need to use RP and TXT records judiciously if at all, but must never, ever put any meaningful data into an HINFO record. RP, or Responsible Person, is used to provide the e-mail address of someone who administers the domain. This is best set to as uninteresting an address as possible, e.g., “email@example.com” or “firstname.lastname@example.org”. Similarly, TXT records contain text messages that have traditionally provided additional contact information (phone numbers, etc.) but should be kept only specific enough to be useful, or better still, omitted altogether.
HINFO is a souvenir of simpler times: HINFO records are used to state the operating system, its version, and even hardware configuration of the hosts to which they refer! Back in the days when a large percentage of Internet nodes were in academic institutions and other open environments (and when computers were exotic and new), it seemed reasonable to advertise this information to one's users. Nowadays, HINFO has no valid use on public servers, other than obfuscation (i.e., intentionally providing false information to would-be attackers). In short, don't use HINFO records!
Returning to Figure 3, then, we see that the last few records are unnecessary at best and a cracker's gold mine at worst. And although we decided the SOA record looks good, the NS record immediately following points to a host on another domain altogether—remember, we don't like glue-fetching, and if that's the case here, we may want to add an A record for ns.otherdomain.com.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server