HostDB: The Best Damn host2DNS/DHCP Script Ever Written Thomas Limoncelli – Cibernet Corp.
ABSTRACT HostDB is a system for generating DNS zone files, BIND configurations, and ISC DHCP server configurations. It is extremely simple yet powerful, which makes it easy to deploy. It is not so complicated that it requires an SQL database or web server. It is not a single generation script but a complete system that includes tools for deploying the files that are generated. The system is written in Perl and shell and makes heavy use of make. The zone files that it generates look hand- made, except that they are clean. Powerful tools are also provided to aid in the conversion from legacy systems. HostDB is the third generation of my DNS maintenance systems and embodies not just superior software but also best practices in system administration. HostDB uses small tools that combine to achieve large goals. Initial deployment can be done in stages to reduce risk. Deployment of updates is fully automated. It rocks.
Introduction Many generate zone files that are not pretty: hand- edited zone files would be more readable (if we only The goal of HostDB is to create a DNS zone had the time to maintain them that way!). HostDB generator that is full-featured without requiring com- fixes all these issues. It does this without introducing a plicated databases and web services. The system uses complicated syntax plus it generates your DHCP con- simple configuration files and automates deployment. figuration file ‘‘for free’’! The code is written in Perl, It is easy to deploy whether you are converting a legacy system one zone at a time or setting up a new shell, and make and is freely available. system from scratch. Setup time is fast. Really fast. The system can be Many small and medium sites (dozens or hun- used to generate zone files that can be individually dreds of machines) hand-edit DNS zone files. This is inserted into your legacy systems within minutes of an error-prone practice which requires a high skill installing the software. HostDB breaks from the Free level. The smallest typo can cause big outages. and Open Source Software (F/OSS) tradition of pro- viding a default configuration that is an arrogant dis- Many large sites (multiple IT teams, locations, play of the most complicated features. Instead the and internet connections) use DNS management sys- default configuration is a useful example that can tems that provide no revision control and very little often by used ‘‘out of the box’’ with only small audit trail of who made what changes. Many also changes. Documentation is included for migrating require external (outside the firewall, or ‘‘public’’) from a legacy system in small steps with plenty of zone files to be maintained by hand, which adds the testing along the way. risk that they will become out of date with internal (inside the firewall, or ‘‘private’’) zones. Audience The problem with most DNS generation scripts HostDB seeks to fill the void between simple is that they are either too simplistic to be useful or so DNS zone generation scripts and massive DNS/DHCP complicated that they are intimidating to install. The database-driven applications. It is perfect for a site that simple ones are fine for doing an initial conversion is starting fresh, or for one that currently hand-edits from /etc/hosts to zone files that will be hand-edited in zone files and wishes to introduce automation. the future. Many are ‘‘point tools’’ that require a lot of integration work. The complex ones are so unwieldy The learning curve and installation curve for that small sites find them too scary to install. Most HostDB is very small. Thus, it is appropriate for sites don’t handle complicated DNS idioms such as having that do not have the need, expertise, or resources special MX records for mail servers, proper handling required by systems that have a web-based front-end of multi-homed hosts, or templates for ranges of simi- or use a SQL database as the backend. larly named hosts. They don’t handle generating dif- HostDB is good for sysadmins that need an ferent zone files for inside the firewall versus outside extremely good solution but don’t have a lot of time. the firewall (i.e., ‘‘host hiding’’) resulting in hand- Migration from a legacy system is extremely easy edited external zone files that are prone to errors. because the files that are generated are put into a
19th Large Installation System Administration Conference (LISA ’05) 209 HostDB: The Best Damn host2DNS/DHCP Script Ever Written Limoncelli repository before they are copied to their final destina- deployed as well, making it possible to maintain the tion. Thus, comparisons between the legacy zones and all files related to DNS and DHCP configuration for the HostDB-generated zones can be done as part of multiple servers around a network from one central acceptance testing. Tools for comparing zones are pro- administration host. vided. Individual zone files can be put into service Major tools are written in Perl, with many helper permitting an incremental deployment methodology programs in BASH shell. Shell glues them together in (rather than a ‘‘flash-cut’’), thus reducing risk. a way that is easy for sysadmins to understand. The HostDB is not appropriate for extremely large system tries not to re-invent the wheel, thus it uses organizations with many separate IT groups or sites standard UNIX tools: make, SSH, sed and awk. Sed with complicated dynamic DNS configurations. Their and awk have been feeling ignored lately so we threw needs would be better served with other, larger, sys- some work their way. tems. It doesn’t directly support a sophisticated autho- rization schemes, a web-based interface, or assistance How to Configure for dynamic DNS updates. However, HostDB does There are three configuration files. Each encap- have some hooks that make it easy for simple dynamic sulates information that would be updated by a partic- DNS to be used. Also, large organizations are often ular audience. The format is either simple or compli- composed of many smaller IT organizations which cated based on the audience as summarized in Table 1. would find HostDB entirely appropriate. These orga- nizations often have one team that manages all inter- The syntax of hostdb.txt is simple because a non- net connectivity and HostDB is excellent for maintain- DNS expert needs to be able to edit it without intro- ing the related DNS zones. ducing errors. Rather than designing a syntax by and At this time HostDB has no support for IPv6. for DNS experts, much effort was spent in designing a I’m okay with this. syntax that made sense to the junior engineers that would be using the system. The filename ends with What Does It Do? ‘‘.txt’’ to facilitate non-UNIX admins editing these files through non-UNIX tools like Notepad. I have seen many exceptional DNS/DHCP con- figuration management systems that provide excellent zoneconf.txt requires a little more knowledge of web front ends and are so powerful that implementa- how DNS zones work, which is appropriate because tion requires an SQL database. HostDB isn’t one of this file should only be edited by a person with those. advanced DNS knowledge. HostDB lets you track all DNS and DHCP infor- destinations.txt is extremely simple because it mation about all your hosts in a single, simple file. simply states where files are to be copied after they From that file, it generates DNS zones, BIND configu- are generated. It permits files to be renamed as they ration files (named.conf) and host entries that can be are copied, which makes inserting a generated file into included in an ISC DHCP server configuration a pre-existing legacy system very easy. (dhcpd.conf). Two helper configuration files guide Standard UNIX protections can be used to con- zone creation and file deployment, but they are basi- trol who can edit these files. They are all plain ASCII cally static after the system is stable. files, appropriate for maintaining under revision con- The system generates the complete zones and trol systems like RCS, SCCS, CVS or Subversion. configurations. No hand-editing after the fact is Any system administrator maintaining key files such required. Thus, automation using make and other tools as these without a revision control system is taking an is possible. undue risk. Revision control means knowing what The system handles complicated DNS idioms changed when. When a change is introduced that such as: causes an outage, one can undo a change, investigate • Special MX records for mail servers. who made the change, mentor them so they do not • Proper DNS records for multi-homed hosts and repeat the mistake, and optionally ridicule them during routers. staff meetings. • Templates for ranges of similarly named hosts. DNS Zone Generation • Host-hiding (generating different zones for DNS zones are generated using ‘‘mkzones’’. external DNS servers). Mkzones parses the entire hostdb.txt file, storing the • Clean, human-readable zone files are generated important bits into various data structures. It then reads (as if they were human-generated, but neater) zoneconf.txt which is ‘‘executed’’ line by line, setting HostDB includes a tool called ‘‘mkdestinations’’ options and generating zones as instructed. Because of which generates a Makefile that will efficiently deploy this design, an option can be set one way before a par- (push) individual files to local and remote hosts. It ticular zone is generated and then another way before recognizes zone files and treats them specially to pre- the next zone is generated. This is a powerful feature, vent zone-transfer storms. Non-zone files can be letting one system generate zones with very different
210 19th Large Installation System Administration Conference (LISA ’05) Limoncelli HostDB: The Best Damn host2DNS/DHCP Script Ever Written needs. For example, if one sub-domain requires differ- 3. Any records for the current zone name (the ent default MX records than all the others, it is very domain without any host) simple to achieve that goal. Other DNS generation 4. All the DNS information related to a particular systems assume the same options for all zones. That host (with hosts listed in IP address order) makes them inappropriate for very large sites. You may notice that the examples from The power of mkzones’ algorithms comes from hostdb.txt always specify Fully Qualified Domain the fact that the parsing of hostdb.txt is decoupled Names (FQDNs). That is, foo.example.com, not just from the generation of the zones. This permits more simply ‘‘foo’’. Usually DNS systems assume a label is sophisticated zone generation since the generation simply a hostname (sans domain) unless it ends with a algorithms understands ‘‘the big picture,’’ i.e., all host single period. However, humans tend to forget the information is available at once. period. After many iterations of trying to solve this problem by being fancy, we decided it was better to Decoupling parsing from generation also had the require the users to always enter FQDNs and output benefit that the input syntax could be changed without warnings if something was not a FQDN. affecting the generation code. We were able to experi- The decision to group the records in the zone file ment with different syntaxes over time without worry- by hostname (yet stay in numerical IP address order) ing about how this would break the generation code. was something of a small breakthrough discovered The syntax for hostdb.txt was developed with after many trials. To do this all DNS information has massive user input. Users were presented with options to be in memory before the first zone is generated. for syntax and their feedback altered the evolution of This way decisions can be made by checking in-mem- the system. Most DNS zone generation systems tend ory data structures and flags that were built up during to be designed for the DNS expert. HostDB has the parsing. Items from the in-memory data structures are benefit of a host list which is in a format that is perfect deleted as each DNS resource-record is output into the for junior sysadmins and the complicated options are zone file, thus eliminating the possibility of outputting kept far away in a different file where only the experts the same line twice. can make changes. BIND Configuration File Generation The users quickly lined up behind a syntax that mknamedconf uses the information in looked like /etc/hosts, not a fancy recursive syntax like zoneconf.txt to generate ISC BIND configuration files ISC’s BIND and DHCP configuration files. They for DNS masters and slaves inside the firewall, plus requested a single line per IP address because when it DNS masters outside the firewall. It does not generate is time to allocate an IP address (their most frequent configurations for slaves outside the firewall (exter- task) the procedure they are most comfortable with is nal) because the author has not yet found the need for finding an unused IP address in a long list, sorted by such a thing. External slaves tend to be owned and IP address. They also didn’t want to be bothered with managed by separate organizations, often ISPs. We do having to keep the file perfectly indented or brackets not know enough to generate their entire bind configu- matched. ration, nor can we assume they use BIND. Configura- tion updates are usually done via manual (emailed) What Makes the Generation So Cool? requests of the owner of the slave server. To make a zone file look readable took quite a DHCP Generation long time. After many iterations we finally realized The DHCP generation is very simple. Mkzones is that the most readable zone file stripped hostnames called with a flag that tells it to parse the hostdb.txt file (removed the domain, when possible), were formatted as usual, but then output a ISC DHCP ‘‘host’’ statement with tabs (not spaces), grouped records related to a for each machine with DHCP-related data. This infor- particular host, and ordered the hosts by IP address. mation can be included in a ISC DHCP ‘‘dhcpd.conf ’’ Therefore, when generating zone files, we output: file, which must be manually created. DHCP configura- 1. The SOA information tions are usually too custom to warrant generating them 2. The NS records automatically, except for the host statements.
File Name Audience Contents Skills required hostdb.txt Anyone on your Info about all hosts Edit text files, maintain a format set sysadmin team up for them, understand IP addresses zoneconf.txt DNS engineers How the zone files and BIND Understanding of DNS zones and configuration files are generated terminology destinations.txt UNIX admins setting Where zone files and other files Knows where zone files are stored up BIND are copied and has root access on DNS servers Table 1: HostDB configuration files.
19th Large Installation System Administration Conference (LISA ’05) 211 HostDB: The Best Damn host2DNS/DHCP Script Ever Written Limoncelli
The Syntax Multiple ANAMEs and CNAMEs can be listed by separating them by colons. For example one might The systems works in two phases. First, the list ‘‘ANAME=pitchfork.example.com:branch.example. zoneconf.txt and hostdb.txt files are used to generate com:divide.example.com’’. all the files that are generated. Next the new files are copied to the appropriate hosts/directories based on a ANAMEs and CNAMEs can both appear on the map described in destinations.txt. same host line. You might think of this as: The plural ANAMES is the same as ANAME, as Hostdb.txt + zoneconf.txt → generated files is CNAMES the same as CNAME. This makes the Generated files + destinations.txt → deployed files. hostdb.txt file slightly more readable. Multihomed Hosts hostdb.txt Syntax HostDB understands that multihomed hosts need The hostdb.txt file looks like a /etc/hosts file special treatment. For example, a router has many augmented with flags and parameters. Display 1 interfaces. The best practice is to have one DNS label demonstrates the syntax of hostdb.txt: or name that will return all ‘‘A’’ records; one for each The zone file ‘‘example.com’’ that would be gen- interface. However network engineers and others need erated would be a simple ‘‘A’’ record for each host to be able to specify a particular interface when they plus appropriate NS and MX records as configured in want. HostDB likes it both ways. zoneconf.txt. The reverse zone (1.1.10.in-addr.arpa) Suppose the .1 address of each network was an would be one PTR file as appropriate for each host. interface for our router, zathras. We could specify that Notice that each host is listed by its fully quali- as shown in Display 2. fied domain name (FQDN). For example, spoon. The DNS zone information generated would be: example.com instead of just ‘‘spoon’’. During user zathras IN A 10.1.10.1 testing, it was discovered that it was too difficult to IN A 10.1.20.1 come up with a syntax that permitted ‘‘short’’ host- IN A 10.1.30.1 names to be used and still permit multiple domains to IN A 10.1.40.1 be described in the same file. Various formats were zathras-red IN A 10.1.10.1 attempted. In the end, it was decided that it was zathras-blue IN A 10.1.20.1 cleaner to make every host be listed as a FQDN. zathras-green IN A 10.1.30.1 zathras-purple IN A 10.1.40.1 ‘‘kettle.example.com’’ has a special option on it: ‘‘MAC=00:b0:d0:a6:cf:f1’’. This identifies its Media (MX info deleted for brevity, but I assure you they are Access Control (MAC) address, or Ethernet, address. awesome.) When a DHCP configuration file is generated, this Someone that wanted to reach any interface host will have a ‘‘static assignment’’ or ‘‘permanent would use ‘‘zathras’’. A network engineer that needed lease’’ for 10.1.1.2. We have found it useful to assign to refer to the zathras interface on the ‘‘red’’ network static assignments to all known hosts, and use ‘‘pools’’ would specify ‘‘zathras-red.example.com.’’ of randomly allocated addresses only for transient The reverse-lookup zone indicates the individual hosts. This makes log files more accurate since most interface names (zathras-red, not zathras). machines will always appear at the same IP address. HostDB also has ‘‘ISMULTIHOMED=’’ which ‘‘ f o r k . e x a m p l e . c o m ’’ has a CNAME of ‘‘pitchfork. is the same thing but for servers. Currently it is exactly example.com’’. This generates a DNS CNAME record. the same thing as ‘‘ISROUTER=’’. The separate direc- In addition to CNAME=, there is also tives are provided should different functionality be ANAME=. This generates multiple DNS A records required for routers and hosts in future versions. pointing to the same IP address. HostDB generates the Host-hiding reverse lookup to be the first host on the line, which Host hiding is where, for either real or perceived seems to be the most common practice. security reasons, most sites do not want to expose the 10.1.1.1 pot.example.com 10.1.1.2 kettle.example.com MAC=00:b0:d0:a6:cf:f1 10.1.1.3 spoon.example.com 10.1.1.4 fork.example.com CNAME=pitchfork.example.com 10.1.1.5 spatula.example.com Display 1: Syntax of hostdb.txt .
10.1.10.1 zathras-red.example.com ISROUTER=zathras.example.com 10.1.20.1 zathras-blue.example.com ISROUTER=zathras.example.com 10.1.30.1 zathras-green.example.com ISROUTER=zathras.example.com 10.1.40.1 zathras-purple.example.com ISROUTER=zathras.example.com Display 2: Specifying .1 addresses as a router interface.
212 19th Large Installation System Administration Conference (LISA ’05) Limoncelli HostDB: The Best Damn host2DNS/DHCP Script Ever Written names of their hosts to the outside world. Inside their @EXTERNALONLY and @INBOUNDNAT. Display 3 firewall, a host may be called patentdatabase.exam- shows a hostdb.txt that demonstrates all three. ple.com, but outside it should be simply known as database.example.com is a normal host. Insiders h64-32-179-55.example.com. Obscuring the host name have the usual forward and reverse DNS data. Out- like this prevents external users from being able to siders can not look up the host’s IP address, and the make educated guesses about good attack targets. It reverse DNS information is the anonymous name of prevents internal host names from being exposed out- d64-32-179-55.example.com. Lookups of side the network, which might prevent embarrassment d64-32-179-55.example.com return a proper A record. by preventing ceo-pc.example.com from appearing in www.example.com is an externally exposed host. the Apache log files of www.sexyteens.com. Therefore, the forward and reverse lookups work as For forward DNS lookups one generally sets up one would expect for both internal and external users. an external DNS zone file that lists only the hosts that Since ‘‘example.com’’ is an ANAME for this host, it the public internet needs access to. This is used on behaves the same way. external DNS servers and is often managed separately vpn3000 and vpn demonstrate the @EXTER- from the internal of DNS zones. Any time two separate NALONLY scope. This keyword exposes a host exter- databases are used to store information about the same nally but not internally. It is rarely used. In the above thing you are asking for trouble; they will get out of example we use it for a VPN (RAS) server which sync. It is my experience that even sites with very full- external people use to access internal resources. Thus, featured commercial DNS management systems use a they shouldn’t use it when they are inside the com- hand-edited zone-file for their external DNS zones. pany. We wanted to be able to construct a client con- Reverse DNS lookups are another matter. Some figuration that would fail when used inside the fire- sites simply do not provide any reverse-DNS records. wall, where use of the VPN should be unneeded. Thus As a result, other sites refuse to talk to them because, for we marked vpn.example.com as @EXTERNAL- real or perceived security reasons, other sites are weary ONLY so that the DNS entry would appear in external zone files, but not in internal zone files. This achieved of accepting connections from sites without proper the goal. However, network administrators still needed reverse DNS. Other sites simply use statically generated to access the VPN server for administrative reasons. reverse labels that encode the IP address to keep them They could use the name vpn3000.example.com unique. For example, at this time Optimum Online’s which resolves properly internally. reverse DNS for 67.82.128.6 is ool-43528006.dyn. optonline.net (the digits are the hex interpretation of the The last two rows of the table demonstrate that IP address, the ‘‘ool’’ is Optimum OnLine). reverse lookups for the anonymous hostnames are properly generated. Any A record that is generated To that end, HostDB generates a different set of needs a proper PTR record, even when host hiding. zone files for ‘‘internal’’ DNS servers (those inside the Not pictured in Display 3 is @INBOUNDNAT firewall) and ‘‘external’’ servers (those accessible to which solves a very common, but specific, problem. the public). HostDB generates both sets of zone files Suppose you have an internal host on a RFC1918 from the same hostdb.txt, thus preventing them from address (unrouted) network and someone has decided getting out of sync. to poke a hole in the firewall to let outsiders access it. To make this work, HostDB assumes that a host The firewall will do some kind of ‘‘reverse NAT’’ so should be hidden from outsiders unless marked otherwise. that packets destined to a particular public address will To change the default, add a ‘‘scope qualifier’’ to the end be re-written and sent to an internal host. While the of the hostname. The scope qualifiers are @EXTERNAL, author feels this has risky security implications, at 64.32.179.55 database.example.com 64.32.179.56 www.example.com@EXTERNAL ANAMES=example.com@EXTERNAL 64.32.179.57 vpn3000.example.com ANAMES=vpn.example.com@EXTERNALONLY Internal DNS Records External DNS Records Host A PTR A PTR database.example.com 64.32.179.55 database.example.com FAILS d64-32-179-55.example.com www.example.com 64.32.179.56 www.example.com 64.32.179.56www.example.com example.com 64.32.179.56 www.example.com 64.32.179.56www.example.com vpn3000.example.com 64.32.179.57 vpn3000.example.com 64.32.179.57 vpn.example.com vpn.example.com FAILS vpn3000.example.com64.32.179.57 vpn.example.com D64-32-179-55.example.com FAILS FAILS 64.32.179.55 d64-32-179-55.example.com D64-32-179-56.example.com FAILS FAILS 64.32.179.56 vpn.example.com
Display 3: Demonstration of scopes.
19th Large Installation System Administration Conference (LISA ’05) 213 HostDB: The Best Damn host2DNS/DHCP Script Ever Written Limoncelli least HostDB lets you get the DNS records correct HostDB does not create duplicates, even in when you choose to use this technique. Here’s how tricky situations like when the default MX record for a one would do this with HostDB: subnet is the same as the host. For example, if 64.32.9.8 host.example.com@INBOUNDNAT zoneconf. txt specifies that all hosts are to receive MX 10.1.1.5 host.example.com records of priority 10 for mta1.example.com and pri- ority 20 for mta2.example.com and hostdb.txt contains Scopes can pertain to each hostname listed on a the code in Display 5, then the example.com zone file line, whether it is the host, a CNAME or an ANAME. would resemble Display 6. A host can have multiple ANAMES and CNAMES Host ‘‘normal’’ receives both MX records. ‘‘msex- and each name can be normal, external, externalonly, or change’’ receives the MX records and the best priority inboundnat independently of the others. The generation MX pointing to itself. ‘‘mta1’’ and ‘‘mta2’’ have the process becomes quite complicated. What is the right best priority pointing to itself with a worse priority MX PTR record to generate if a host is externalonly but has pointing to either mta2 or mta1 as appropriate. an ANAME alias that is normal? (Our answer: the DHCP Pools ANAME on the inside, the externalonly name on the HostDB provides assistance to anyone creating outside). As new situation cropped up we had to fine- large DHCP pools. DHCP pools usually assign tune the algorithms. ‘‘generic’’ names to each IP address such as Mail Servers ool-24-12-12-12.comcast.net. Repetitive jobs should Marking a host as a mail server means the MX always be automated, thus there is a syntax for auto- records should be slightly different. It should have the matically generating such hostnames. A DHCP pool in default MX records but also an MX record pointing to the middle of a subnet might look like Display 7. itself that is better priority than the others. You specify This would generate a host name called this in hostdb.txt with the ISMAILSERVER flag; see dhcp-10-1-40-4-pool.example.com for the first DHCP_ Display 4. POOL entry, and similar entries for the rest. 198.65.112.13 mta1.example.com ISMAILSERVER Display 4: Mail server specification via ‘‘ISMAILSERVER’’.
198.65.112.9 normal.example.com 198.65.112.10 msexchange.example.com ISMAILSERVER 198.65.112.11 mta1.example.com ISMAILSERVER 198.65.112.12 mta2.example.com ISMAILSERVER Display 5: Mail servers with varying priorities in zoneconf.txt .
normal IN A 198.65.112.9 IN MX 10 mta1 IN MX 20 mta2 msexchange IN A 198.65.112.10 IN MX 0 msexchange IN MX 10 mta1 IN MX 20 mta2 mta1 IN A 198.65.112.11 IN MX 0 mta1 IN MX 20 mta2 mta2 IN A 198.65.112.12 IN MX 0 mta2 IN MX 10 mta1 Display 6: Resulting example.com zone file.
10.1.40.1 zathras-purple.example.com ISROUTER=zathras.example.com 10.1.40.2 server2.example.com 10.1.40.3 server3.example.com DHCP_POOL_TEMPLATE dhcp-$a-$b-$c-$d-pool.example.com 10.1.40.4 DHCP_POOL 10.1.40.5 DHCP_POOL 10.1.40.6 DHCP_POOL 10.1.40.7 DHCP_POOL 10.1.40.8 DHCP_POOL 10.1.40.9 DHCP_POOL 10.1.40.10 host10.example.com Display 7: DHCP pool in the middle of a subnet.
214 19th Large Installation System Administration Conference (LISA ’05) Limoncelli HostDB: The Best Damn host2DNS/DHCP Script Ever Written
The template takes effect from the point in the file purview of senior DNS engineers. By keeping these it appears and continues until another DHCP_POOL_ options separate we avoid accidental modifications by TEMPLATE line overrides it. For example, at one loca- junior engineers. The lines of this file are executed in tion they wanted to have slightly different hostnames order, like a sequential programming language. for a DHCP pool for IP phones. In that address range, The file usually starts by setting some options: they put the lines shown in Display 8. # When a hAAA-BBB-CCC-DDD external name There is no coordination between the DHCP_ # is created, what domain is it in? POOL template and the DHCP configuration file that is OBSCUREZONE example.com generated. That is, if you use the DHCP_ POOL feature OBSCUREZONE indicates the domain name to use to generate a range of similarly-named systems, you for obscured, or anonymous, hostnames in external must manually update the DHCP configuration file to zone files. include those ranges. SOA, MX, and ZONESERVERS sets the SOA A future enhancement would be to have the tem- values, default MX records, and NS records to be plate be a stack, permitting one to more easily switch included in any zone file created after this point; see to a new template and switch back when one is done. Display 9. While it might be useful to be able to specify a Notice that most commands are repeated once for range of IP addresses (rather than to list one per line) INTERNAL and once for EXTERNAL. These settings this feature has been delayed until a clear syntax can are different for internal and external zones. There is be developed. A range would violate the ‘‘one line per also ‘‘SLAVE’’, which is an internal secondary. There address’’ rule that the sysadmins preferred. It turns out is no support for external slave servers at this time as they often use their text editor’s command to cursor- they tend to be at ISPs and don’t let customers update down 256 times to jump from subnet to subnet. Thus, their DNS server configurations directly. any command that consolidates repetitive lines makes When the system generates the named.conf file it navigation more difficult. will need to know some parameters to insert into any However, a command-line tool is provided to ‘‘ z o n e ’’ setting. For example, we need to specify who generate lists of IP addresses with a template. The is allowed to do zone transfers and who is allowed to command was used to create the above range: do dynamic DNS updates. We set those values as genrange 10.1.100.4 10.1.100.100 \ shown in Display 10. ’$ip
SOA INTERNAL hostmaster.example.com 1H 15M 30D 60M SOA EXTERNAL hostmaster.example.com 1H 15M 30D 60M MX INTERNAL 10 lucy.example.com ; 20 ingw2.example.com MX EXTERNAL 10 exgw2.example.com ; 10 exgw4.example.com ZONESERVERS INTERNAL lucy3.example.com ingw2.example.com ZONESERVERS EXTERNAL exgw4.example.com exgw2.example.com Display 9: SOA, MX, and ZONESERVERS examples.
ALLOW-TRANSFER INTERNAL "primary_servers" ALLOW-TRANSFER SLAVE "primary_servers" ALLOW-TRANSFER EXTERNAL "rev65_servers" ALLOW-UPDATE INTERNAL "none" ALLOW-UPDATE SLAVE "none" ALLOW-UPDATE EXTERNAL "none" Display 10: Zone transfer and dynamic DNS update permissions.
19th Large Installation System Administration Conference (LISA ’05) 215 HostDB: The Best Damn host2DNS/DHCP Script Ever Written Limoncelli
Order is important here. After a host’s DNS Special Cases records are output they will not be output again. If While HostDB generates a file named.conf file it example.com precede corp.example.com, the zone file generates a very standard ‘‘zone {}’’ stanza for each for corp.example.com would be nearly empty, contain- DOMAIN command. If you need something very spe- ing only the required SOA and NS records. cialized, one can use CUSTOMDOMAIN instead. Notice that ex.com is only an external zonefile. This will generate no ‘‘zone {}’’ stanza and rely on That’s permitted. Domains can be internal-only too. If you to add one in manually using other means you mix and match HostDB will do the right thing. explained later. This can be useful for subdomains that exist only This is particularly important for supporting inside the company. Dynamic DNS updates. HostDB supports you by giv- Now we can generate the reverse lookup zone ing you enough rope to hang yourself. files; see Display 12. The REVDOMAIN options indi- Summary cate what size in-addr.arpa zone file to create (class A, That’s all there is to it! You specify what zone B, or C), the starting IP address, and whether this is files to create and it generates them plus the internal only or both internal and external. named.conf file. All the hard work is done for you. If There are a few tricks one can do. For example, extra lines need to be added to a zone file or configu- since the configuration is ‘‘executed’’ line by line, you ration file, that can be done with the notation can change settings between zones. For example, if described in the next section. When the system is fully you had different MX records for a particular domain, configured it should be able to generate all files with- you can change along the way; see Display 13. out any manual intervention. This would generate corp.example.com with lucy Header and Footer Files and ethel as the default MXs. Then the default MXs HostDB can’t be all things to all people, so there would changed to betty and wilma before prod.exam- is an ‘‘emergency escape hatch’’ that lets you cus- ple.com is generated. Then the SOA defaults would be tomize any file that is generated. You can add a header changed before the reverse domain 197.32.64.in- file and footer file to any file created by HostDB. For addr.arpa would be generated. any file X generated by HostDB, the file that is actu- Rudimentary support for RFC 2317-style ‘‘class- ally created is made up of: less’’ delegations is implemented but not complete. 1. The contents of file $TEMPLATES/X-head (if Eventually there will be a REVRANGE command that this file exists). accepts a range like that shown in Display 14. This 2. The content generated by the HostDB system. will generate a zone file with the specific contents 3. The contents of the file $TEMPLATES/X-tail required for RFC 2317. (if this file exists). DOMAIN corp.example.com INTERNAL EXTERNAL DOMAIN example.com INTERNAL EXTERNAL DOMAIN ex.com EXTERNAL Display 11: Creating zone files using DOMAIN.
REVDOMAIN CLASSC 64.32.197.0 INTERNAL EXTERNAL REVDOMAIN CLASSC 64.32.198.0 INTERNAL EXTERNAL REVDOMAIN CLASSC 10.1.0.0 INTERNAL REVDOMAIN CLASSC 10.1.255.0 INTERNAL REVDOMAIN CLASSB 10.100.0.0 INTERNAL REVDOMAIN CLASSC 10.254.0.0 INTERNAL REVDOMAIN CLASSC 172.17.17.0 INTERNAL Display 12: Creating reverse look up zone files using REVDOMAIN.
SOA EXTERNAL hostmaster.example.com 1H 1H 30D 60M MX INTERNAL 10 lucy.example.com ; 20 ethel.example.com DOMAIN corp.example.com INTERNAL EXTERNAL MX INTERNAL 10 betty.example.com ; 20 wilma.example.com DOMAIN prod.example.com INTERNAL EXTERNAL SOA EXTERNAL hostmaster.example.com 2H 2H 30D 60M REVDOMAIN CLASSC 64.32.197.0 INTERNAL EXTERNAL Display 13: Specifying varied MX records for a particular domain.
REVRANGE 22.33.44.32 22.33.44.63 32-63.44.33.22.in-addr.arpa INTERNAL EXTERNAL Display 14: Future style of RFC 2317-style range specification.
216 19th Large Installation System Administration Conference (LISA ’05) Limoncelli HostDB: The Best Damn host2DNS/DHCP Script Ever Written
(The file name suffixes ‘‘head’’ and ‘‘tail’’ are If the template includes a hyphen, the text after used instead of ‘‘footer ’’ and ‘‘header ’’ because they the hyphen is passed to the template as a parameter. sort better that way.) Thus templates can be smart. Suppose there is a This feature is useful for: default netboot server and a special one for develop- • Sneaking special records into a zonefile. If ers. Templates can be constructed that produce proper HostDB won’t generate a zone the way you DHCP configuration for each; see Display 19. want it, add the lines to a -tail file. Currently the templates are written as subrou- • Adding custom zones to a named.conf file. If tines in Perl and are hard coded into the mkdhcp there are zones not under HostDB management script. Future versions will move these templates to you can still add information about them in their own files, though this work has been deferred to named.conf later because (1) the need for special templates to han- • Coarsely approximating an ‘‘include file’’ dle broken DHCP clients is reduced over time as more mechanism. If a DHCP server configuration vendors figure out how to write DHCP clients that file doesn’t have an ‘‘include’’ mechanism, you aren’t broken, (2) nobody’s really complained about can wrap the contents of a file around the out- the system as it is. put of HostDB’s dhcpd.conf Deployment (Phear My Aw4z0m3 Makefile Skilz!) DHCP Generation Generating zone files and configuration files is HostDB parses the hostdb.txt file and creates the not enough. They must be deployed to be useful. ‘‘host’’ statements appropriate for ISC’s DHCP server. One stanza is created for each host that has a MAC= Rather than generate files directly where they setting. No stanzas are created for hosts without will be used, HostDB generates all files in a directory MAC= settings. called ‘‘out’’ (short for output). Sites with a very large legacy system for DNS/DHCP management can sim- A hostdb.txt line that looks like Display 15 ply copy the newly generated files (or just the files would generate the default template like that shown in that are useful to them) out of this directory. However, Display 16. This is appropriate for most systems. HostDB includes a tool that makes this even easier (Note that the MAC address is reformatted to be pretty by capitalizing the letters and zero-padding.) called mkdestination. It generates a Makefile that ‘‘does the right thing.’’ However, if TYPE=foo is included, as alternate template is used. For example we might want a differ- Mkdestination takes ‘‘destination.txt’’ for input, ent template if we know the machine has a broken and generates ‘‘destination.mk’’ which can be used in DHCP client that gets confused by extra data. A the Makefile that drives your DNS/DHCP service. hostdb.txt line like this would select the template Consider short example destination.txt file called ‘‘win95’’ which is intentionally minimal (see shown in Display 20. The format is a simple list Display 17) generates the code shown in Display 18. source files, the ‘‘->’’, then destinations. Destinations 10.10.244.14 dell4.example.com MAC=00:5:3b:F1:21:7a Display 15: Sample hostdb.txt file.
host dell4.example.com { hardware ethernet 00:05:3B:F1:21:7A; fixed-address 10.10.244.14; option host-name "dell4.example.com"; ddns-hostname "DELL4"; } Display 16: Generated default template from hostdb.txt file above.
10.10.244.14 dell4.example.com MAC=00:5:3b:F1:21:7a TYPE=win95 Display 17: Minimal template for ‘‘win95’’.
host dell4.example.com { hardware ethernet 00:05:3B:F1:21:7A; fixed-address 10.10.244.14; } Display 18: Code generated by template above.
10.10.244.13 human1.example.com MAC=00:05:3B:F1:21:7A TYPE=netboot 10.10.244.14 human2.example.com MAC=00:05:3C:E3:32:A4 TYPE=netboot-main 10.10.244.15 human3.example.com MAC=00:05:32:A2:01:12 TYPE=netboot-dev Display 19: DHCP configuration templates.
19th Large Installation System Administration Conference (LISA ’05) 217 HostDB: The Best Damn host2DNS/DHCP Script Ever Written Limoncelli can be a file name or directory on the local machine or ‘‘push’’ to all other hosts, simply ‘‘make clean’’ then some other. There is no macro expansion or other sub- ‘‘make push’’ and all files will be copied whether they stitution mechanism because we want to keep the for- need it or not. mat simple. Efficient Zone Serial Number Updates The first line says that to deploy INTER- The other interesting feature of mkdestination is NAL.example.com and INTERNAL.198.32.64.in-addr. that it is smart about zone serial numbers. arpa one should copy it into the local directory DNS zone files have an embedded serial number /var/named, and scp it to a /var/named on a machine which is used to determine when zone transfers are to called ‘‘betty’’. The next two lines specify that a file is happen. If a secondary has a zone of serial number X, to be copied to a particular filename. This permits one and is told that the primary has a higher serial number, to rename files as they are copied. it requests a download of that zone (a ‘‘zone trans- Display 21 shows how one might use mkdestina- fer ’’). Zone transfers are a CPU- and (possibly) net- tions in a master Makefile. work-intensive operation. We want to prevent gratu- Invoking ‘‘make push’’ would generate the desti- itous zone transfers. nations.mk file (if needed) then run the ‘‘all’’ recipe. The problem, however, is that the only way to The recipes in the destinations.mk file ‘‘do the right know if a zone file will change is to generate the new thing’’ for all files mentioned in destinations.txt. one and compare it to the old one. The comparison ‘‘make push-local’’ is similar but runs the ‘‘all-local’’ can’t be a simple ‘‘cmp’’ or ‘‘diff’’ because the serial recipe, which only deploys files destined for the local number inserted into the zone file will be different machine. This is useful for testing purposes. every time. Most changes to hostdb.txt tend to affect only a few zone files. Mkdestinations is needed to overcome limita- tions in ‘‘make’’. ‘‘Make’’ has no awareness of remote Again, mkdestination to the rescue. mkdestina- file timestamps, nor can ‘‘make’’ handle a dynamic tion knows about serial numbers and can do compar- list of zones and files with multiple destinations. isons that ignore the serial number line of a zonefile. The methodology is as follows. Efficient Updates of Remote Files HostDB generates all files in a directory called Make has no idea if betty:/var/named/named. ‘‘out’’. Any file that needs a serial number contains conf is up to date because it is on a different machine. the text ‘‘:serial:’’ anywhere a serial number is to be Therefore, mkdestination compensates by creating placed. This makes comparison of zone files easier. local timestamp files after a remote operation is com- Any file that did change is copied to a directory called plete (that is, after a remote file is updated success- MP and another copy is placed in a directory called fully it touches a local file whose name encapsulates MS. The MP directory contains a plain copy of the the destination server and filename). Future timestamp zone but the MS directory contains a copy of the file comparisons can be done against the local file. Rather with ‘‘:serial:’’ changed to the serial number used for than recopying a file to a remote machine ‘‘just in all files generated at that time. When deciding which case’’, the timestamps can be compared. In the case of files need to be deployed, the timestamp of MS is used copying a file to betty:/var/named/named.conf, the to determine if the file needs to be copied but the file timestamp file ds/ betty__var_named_named.conf is that is copied comes from MP. created. (The actual filename is much more compli- After a file is successfully deployed, a timestamp cated to encode special characters that might cause file is created in the DS directory marking the comple problems.) tion. In the case of copying a file to betty:/var/named Mkdestination also creates a recipe called named.conf, the timestamp file with a name like DS/ ‘‘clean’’ which deletes all timestamps. Thus, to force a betty__var_named_named.conf is created. The result is INTERNAL.example.com INTERNAL.198.32.64.in.addr.arpa -> \ /var/named/. secondary:/var/named/. INTERNAL.named.conf -> /etc/named/named.conf SLAVE.named.conf -> betty:/etc/named/named.conf Display 20: Sample destination.txt file.
destinations.mk: ../destinations.txt mkdestinations <../destinations.txt >destinations.mk push: destinations.mk make -f destinations.mk all push-local: destinations.mk make -f destinations.mk all-local Display 21: Using mkdestinations in a Makefile.
218 19th Large Installation System Administration Conference (LISA ’05) Limoncelli HostDB: The Best Damn host2DNS/DHCP Script Ever Written that files are only copied when absolutely needed. It is Example 1: Starting from Scratch optimal. In this example we are starting from scratch. At a site with dozens of zones the DNS servers Imagine we are setting up a new network for a new were being hit fairly hard by all the zone transfers. company. We have one external network (64.32.179.0/ After mkdestination’s technique was deployed the 24) and one internal network (10.1.1.0/24). There will administrators were very happy to see that very few be a dhcp pool from .140 to .250 in the first network. zones were actually being transferred after typical We begin by generating the hostdb.txt file. We updates. It was quite impressive to see many, many generate a list of each IP address. That way when a zone files with an assortment of serial numbers as junior engineer goes to allocate an IP address, they diverse as the history of updates had dictated. Yet, no don’t have to understand anything but (1) find an tool more complicated than ‘‘mkdestination’’ and unused address on the right subnet, (2) remove the ‘‘make’’ was needed. comment symbol and change the hostname as appro- If this sounds confusing to you, just be happy in priate. This prevents them from introducing typos into the knowledge that you don’t have to understand it to the list of IP addresses, and prevents mistakes such as benefit from the efficiencies. Files that don’t need to thinking they can create new IP subnets by simply be copied across your network aren’t copied. editing this file. It also keeps the file neat and orderly in case you work with people that can not be trusted to Deployment Examples keep a file in numerical order. Here are two examples of how to deploy Display 22 shows commands that will generate a HostDB. First we will consider a new site starting hostdb.txt that is a good starting point. from scratch. Then we will see how easy it is to • Line 1 creates commented-out sample lines for the first 140 addresses. deploy in a pre-existing environment. • Line 2 creates addresses for our DHCP pool. We need a place to put our files. The HostDB Note the custom template. files can be put in any directory as your site’s require- • Line 3 completes the internal network’s addresses. ments dictates (/var/hostdb or /home/adm/hostdb is • Line 4 uses a different template for the external typical). HostDB assumes that all executables will be hosts. It also demonstrates that if the second IP found in the shell’s PATH. As a result, test datasets address is replaced by an integer, it is inter- can be placed anywhere (even /tmp). When testing preted as a count of how many lines to output new executables, one can simply put the newer ver- instead of an end address. sions ahead of the older ones in the shell’s PATH. Display 23 shows the output. In these examples we will use /var/hostdb and Now edit the hostdb.txt to include the initial assume the PATH is set correctly. hosts that will be installed. To make sure that nobody genrange >hostdb.txt -d example.com 10.1.1.0 10.1.1.139 genrange >>hostdb.txt -d example.com 10.1.1.140 10.1.1.250 ’$ip\tDHCP_POOL’ genrange >>hostdb.txt -d example.com 10.1.1.251 10.1.1.255 genrange >>hostdb.txt -d example.com 64.32.179.0 256 ’#$ip\tex$hex.$DOMAIN\@EXTERNAL’ Display 22: Generating hostdb.txt from scratch.
#10.1.1.0 UNUSED0A010100.example.com #10.1.1.1 UNUSED0A010101.example.com ...elided for space... #10.1.1.138 UNUSED0A01018A.example.com #10.1.1.139 UNUSED0A01018B.example.com 10.1.1.140 DHCP_POOL 10.1.1.141 DHCP_POOL ...elided for space... 10.1.1.249 DHCP_POOL 10.1.1.250 DHCP_POOL #10.1.1.251 UNUSED0A0101FB.example.com #10.1.1.252 UNUSED0A0101FC.example.com #10.1.1.253 UNUSED0A0101FD.example.com #10.1.1.254 UNUSED0A0101FE.example.com #10.1.1.255 UNUSED0A0101FF.example.com 64.32.179.0 ex4020B300.example.com 64.32.179.1 ex4020B301.example.com ...elided for space... 64.32.179.254 ex4020B3FE.example.com 64.32.179.255 ex4020B3FF.example.com Display 23: Output from above commands.
19th Large Installation System Administration Conference (LISA ’05) 219 HostDB: The Best Damn host2DNS/DHCP Script Ever Written Limoncelli tries to allocate a broadcast address, we mark the ‘‘all values for the internal and external version. Next we zeros’’ address as ‘‘foo-net.example.com’’ and the ‘‘all generate the reverse lookup zone for 10.1.1.0/24, ones’’ address as ‘‘foo-bcast.example.com’’ where which only generates an internal zone file. Lastly we ‘‘foo’’ is a unique name for each subnet. Display 24 generate the 64.32.179.0/24 zone reverse lookup shows the non-comment lines. which has different internal and external values. Display 25 shows our zoneconf.txt file, which Copy the template Makefile into the main direc- is almost the same as the example provided with the tory and we are ready for our first attempt at generat- software. Most sites can use this template and simple ing our zones. To save ourselves typing, we’ll create change ‘‘example.com’’ to their domain and edit an alias for bash/sh/ksh or csh/tcsh (see Display 26). their MX records and ZONESERVERS to suit their Then we can do ‘‘makeh’’ to generate a new set of needs. files. If we are happy we can do ‘‘makeh push’’ to The last three lines show which zones to generate. deploy the files. As a result, the ‘‘out’’ directory now First the zone for example.com, which has different contains: 10.1.1.0 main-net.example.com 10.1.1.1 zathras-main.example.com ISROUTER=zathras.example.com 10.1.1.2 fileserver.example.com 10.1.1.3 mailserver.example.com ISMAILSERVER 10.1.1.4 vector.example.com 10.1.1.10 staffpc1.example.com MAC=00:b0:d0:a6:cf:f1 10.1.1.11 staffpc2.example.com MAC=00:b0:d1:a7:c0:d1 10.1.1.11 staffpc2.example.com MAC=00:b0:c2:b3:c3:d3 TYPE=freebsd 10.1.1.140 DHCP_POOL 10.1.1.141 DHCP_POOL 10.1.1.142 DHCP_POOL ...elided for space... 10.1.1.249 DHCP_POOL 10.1.1.250 DHCP_POOL 10.1.1.255 main-bcast.example.com@EXTERNAL 64.32.179.0 ext-net.example.com@EXTERNAL 64.32.179.1 isp-router.example.com@EXTERNAL 64.32.179.2 zathras-ext.example.com@EXTERNAL ISROUTER=zathras.example.com@EXTERNAL 64.32.179.3 mailqueue.example.com@EXTERNAL ISMAILSERVER 64.32.179.4 vector.example.com@INBOUNDNAT 64.32.179.5 exweb.example.com ANAME=www.example.com@EXTERNAL 64.32.179.255 ext-bcast.example.com@EXTERNAL Display 24: Edited hostdb.txt file.
TEMPLATEDIR .. OBSCUREZONE example.com SOA INTERNAL hostmaster.example.com 3h 1h 1w 1h SOA EXTERNAL hostmaster.example.com 3h 1h 1w 1h MX EXTERNAL 10 mailserver.example.com MX INTERNAL 10 mailqueue.example.com ; 20 s1.isp.com ZONESERVERS INTERNAL fileserver.example.com mailserver.example.com ZONESERVERS EXTERNAL mailqueue.example.com exweb.example.com ALLOW-UPDATE INTERNAL done ALLOW-UPDATE INTERNAL none ALLOW-UPDATE SLAVES none ALLOW-UPDATE EXTERNAL none DOMAIN example.com INTERNAL EXTERNAL REVDOMAIN CLASSC 10.1.1.0 INTERNAL REVDOMAIN CLASSC 64.32.179.0 INTERNAL EXTERNAL Display 25: Example zone.txt file.
# bash/sh/ksh alias: alias makeh=’cd /var/hostdb/out && make -f ../Makefile’ # csh/tcsh alias alias makeh ’cd /var/hostdb/out && make -f ../Makefile’ Display 26: Shell ‘makeh’ alias definitions.
220 19th Large Installation System Administration Conference (LISA ’05) Limoncelli HostDB: The Best Damn host2DNS/DHCP Script Ever Written
$ls-1 This command will generate a makefile that will do the EXTERNAL.179.32.64.in-addr.arpa actual copying: makeh destinations.mk . Finally, EXTERNAL.example.com ‘‘ m a k e h push’’ will actually copy the files into place. A EXTERNAL.named.conf few rounds of debugging and the system is deployed. EXTERNAL.named.root INTERNAL.1.1.10.in-addr.arpa Example 2: Replacing a Legacy System INTERNAL.179.32.64.in-addr.arpa In this scenario we have a working system where INTERNAL.example.com we hand-edit zone files and copy them using a shell INTERNAL.named.conf script. To move from a legacy system to HostDB SLAVE.named.conf requires a lot of testing. HostDB includes utilities that Notice that each filename is prefixed with ‘‘INTER- help every step. NAL.’’, ‘‘EXTERNAL.’’ or ‘‘SLAVE.’’ . All other The first and most difficult step is to convert the files are tagged as being appropriate for either the inside or the outside. EXTERNAL.named.root is the zone files and turn them into hostdb.txt format. This is NIC’s ‘‘root cache’’ file which the Makefile automati- the reverse of what HostDB does! Sadly, we can’t cally retrieves via FTP. reverse the polarity of the flux capacitor and have everything ‘‘just work.’’ Luckily, the HostDB package Now check the zone files by manual inspection. includes zone2hostdb which does 90% of the work for Correct any errors by editing ../hostdb.txt and re-run- you. It takes a zone file as input: ning ‘‘makeh’’ until you are satisfied. zone2hostdb
19th Large Installation System Administration Conference (LISA ’05) 221 HostDB: The Best Damn host2DNS/DHCP Script Ever Written Limoncelli
The next step is to use genrange to enumerate destinations.txt file can be used to roll out just the spe- every IP address that should be listed in your cific zones you are confident in. hostdb.txt file, whether it is commented out or not. We Suppose your legacy system loads your main use the same ‘‘genrange’’ commands as in the first zone from a file called /var/named/zone.example. example except we save the output to a file called com..zone, you can replace that file with the HostDB- hostdb.txt-enum. generated file with a statement like that shown in Dis- HostDB includes a utility called ‘‘mergeiplists’’ play 28. Obviously you should make good backups that will merge these two lists properly even though before deploying any new zones. some of the lines are commented out. It assumes the To push that zone out, ‘‘makeh push’’. first appearance of an IP address is the authoritative line and throws the others away. Thus, we list the Te s t , test, test. Be ready to revert to the legacy hostdb.txt-base first because our hand-edited file zone if the problems you find are insurmountable. Fol- should be authoritative; hostdb.txt-enum is just to fill low any in-house procedures related to change windows in the gaps; see Display 29. Now we have a pretty and so on. For example, do not introduce new zones: decent draft of our hostdb.txt file. • Right before you leave for vacation The same week as the quarterly results or taxes Before we can put it into use, we should test it • are being prepared extensively and then only switch to it incrementally. • The week of a major deadline for your company Testing is made easier by a utility that is included • The week raises and promotions are being called ‘‘canonzone’’. Comparing two zone files can be decided difficult because of small changes in white space, sort- ing, and so on. ‘‘canonzone’’ reads a zone file and out- Lastly, you can replace your named.conf files with puts it in a very specific, clean, regular, format (a the ones that are generated by HostDB (though if your canonical format). If you are comparing a legacy zone zone filenames change, be very careful!). You should file and a generated zone file, pass both thought also integrate the Makefile into your system so that it canonzone first and the comparison will be much eas- controls all DNS-related activity from one central point. ier. The distribution includes a file called ‘‘Exam- Related Work ple_comparezones’’ which takes two files, passes them through canonzone, strips them down to just There are many other open source systems that DNS A records, and compares them. do some or part of what HostDB does. There are even Here are some tips for testing your new zones: a few that do a lot more, especially where dynamic • Use Example_comparezones as a template for registration is involved. However, the goal of HostDB your own comparison scripts. is to maximize features without having to resort to • Review each email server and verify the MX requiring a web front-end or SQL backend. The author records are as required. believes HostDB is superior to all systems that don’t • Review all other servers and verify their DNS require an SQL backend, and easier and faster to install records are as expected. than any of the systems that require SQL databases. • Review each external host and verify all of its Here is my comparison to some popular utilities: records (test from inside and outside). • h2n – O’Reilly’s ‘‘DNS and BIND’’ by Paul • Set up a new DNS server and load the zones. Albitz and Cricket Liu comes with h2n (and an Make sure they load without outputting any enhanced version is called h2n-hp). These are errors or warnings in BIND’s logfile. fine DNS generator scripts. While it can be • Query the DNS server to make sure you get used for one-time conversion, there are features expected results for mail servers and other that let you maintain the host list as a /etc/hosts- important hosts. When you are satisfied, ask like file. However, this is a ‘‘kit’’, not a com- co-workers to do the same. plete system. It does not include anything like • When you are satisfied, configure yourself and mkdestinations for deployment. No DHCP sup- a few trusted users’ machines to use this new port. Source: www.oreilly.com/catalog/dns3 . DNS server. If anything breaks, fix it. After a • DNSDusty – While this system does automate few days, have your coworkers switch to this deployment of the files it generates, it requires DNS server. Make sure they know to report a web interface (but no SQL database). It problems to you. makes adding a host very easy for a junior When you are satisfied with the zone files, you sysadmin once it is set up. No DHCP support. can slowly migrate them into your legacy system. The Source: www.poochiereds.net/dnsdusty . INTERNAL.example.com -> dnsserver:/var/named/zone.example.com..zone Display 28: Replacing a legacy zone file.
mergeiplists hostdb.txt-base hostdb.txt-enum >hostdb.txt Display 29: Merging lists.
222 19th Large Installation System Administration Conference (LISA ’05) Limoncelli HostDB: The Best Damn host2DNS/DHCP Script Ever Written
• dnscvsutil – Maintains your DNS zone files under the scenes. It does not offer complicated features such as CVS control and automatically updates reverse real-time host authorization, web front-ends, or any fea- zones. Helping someone do a better job of main- ture that required sophisticated and difficult to maintain taining hand-edited zone files is exactly the oppo- databases. site of what I want to encourage. Though, revi- Deploying the files is made easier through the sion control is better than no revision control. No use of a simple Makefile that is generated for you. The DHCP support. Source: freshmeat.net/projects/ updates are very sophisticated, doing the minimal dnscvsutil . number of updates locally and to remote machines, • Sauron – Sauron is a free DNS/DHCP manage- even being careful not to create ‘‘zone transfer ment system with Web and command line inter- storms’’ by not updating a new serial number for a faces. It can manage multiple servers and gen- zone that does not warrant it. erates complete dhcpd and named configura- tions from the database. This is a very complete Availability and impressive package. It manages deploy- The software open source and is available at ment of generated files. However, it does http://www.everythingsysadmin.com/hostdb on the web. require a web interface and SQL database. Source: http://sauron.jyu.fi/ . Acknowledgements • Updatehosts – A very comprehensive system for managing DNS information. This is popular at I would like to thank Glenn Sieb for his feedback many large commercial sites. However, the when designing the file formats, David H. Potter for learning curve seems overly steep as it requires assistance developing the mkdestination algorithm, understanding of database relations. This is not Joe Gross who read the most painful early drafts of for the neophyte or someone trying to set up a this paper and helped me turn it into a much better new site quickly. Requires SQL. No DHCP sup- paper, and Josh Simon for his editing and proofread- port. Source: ftp://ftp.tic.com/pub/updatehosts . ing assistance. The Future References New features are added to HostDB on a regular Albitz, Paul, Cricket Liu, DNS and BIND, Fourth Edi- basis.These projects are being considered: tion, O’Reilly, April, 2001. • Make testing even easier: mkdestination should Cheswick, William R., Steven M. Bellovin, Aviel D. create a ‘‘diff’’ recipe that diffs the last distrib- Rubin, Firewalls and Internet Security: uted against the most recently generated files. Repelling the Wiley Hacker, 2nd Edition, Addi- • Eliminate the need to modify the default Make- son-Wesley, February, 2003. file: Move ‘‘restart commands’’ to the mkdesti- Christiansen, Tom, Nathan Torkington, Perl Cook- nation system. book, Second Edition, O’Reilly, August, 2003. • Add classless delegation support: Complete sup- Limoncelli, Thomas A. and Christine Hogan, The port for RFC 2317-style ‘‘classless’’ delegations. Practice of System and Network Administration, • Add IPv6 support: Add support for IPv6 Addison-Wesley, 2002. records. (Those long addresses aren’t going to Wall, Larry, Tom Christiansen, Jon Orwant, Program- be fun to type. We need some human-factors ming Perl (third edition), O’Reilly, July, 2000. help here.) • Improve legacy conversion: Update zone2hostdb to read multiple zones, including reverse DNS zones, and use the information to do a better job. In particular, PTR records could be an indicator of which name is a canonical name and which is an ANAME. Conclusion HostDB generates really cool DNS zone files with all the features required by sites with complicated DNS configurations, such as aliases, ‘‘external only’’ names, ‘‘ h o s t hiding’’ and multihomed hosts. It also generates the ISC BIND configuration files required for primaries, secondaries, and external DNS servers. DHCP configu- ration for static leases are generated for ISC DHCP using a very flexible template-based mechanism. It is easy to configure and deploy, yet sophisticated behind
19th Large Installation System Administration Conference (LISA ’05) 223