ViDns (vidns elsewhere) is a program to allow convenient editing of DNS zone files.

Normal and complex zones

In an ideal world, there would be a one-to-one correspondence between zone files and domain names. In reality, this isn"t adequate. For example, suppose that an entity wishes to have separate "views" of their DNS namespace depending on whether the system asking for an address is on the company LAN or the InterNet. In this case, a domain may be represented by more than one zone file: one for queries from the InterNet^?, and one for internal queries. Furthermore, if the views differ only slightly (say that only one or two hosts in a domain differ, and the rest are the same), then the zone files may include the contents of a file common between them, and only specify the records that are dissimilar.

A real-world example

Subwiki is part of the honeypot.net domain. The server it lives on, and other computers on the same LAN, are behind a NatFirewall^? and have PrivateAddresses^?. When a computer on the LAN requests the address of "subwiki.honeypot.net", they are expecting the answer to be "10.0.5.16". However, when would-be visitors from the InterNet look up "subwiki.honeypot.net", they are looking for the PublicAddress^? "208.162.254.122". To complicate matters, honeypot.net also supports IpV6, and those addresses are the same regardless of what machine is asking for them. To fully represent the domain, three files are used:

• internal/db.honeypot.net - Records that are only visible to machines on the LAN
• external/db.honeypot.net - Records that are only visible to external visitors
• common/db.honeypot.net - Records that exist in both internal and external views

Managing these records can become rather complicated. Imagine the case where "foo.honeypot.net" currently exists and is the same in both views, but that it needs to be altered so that it resolves differently in each. The following steps have to be coordinated:

1. Remove the "foo.honeypot.net" entry from common/db.honeypot.net
2. Add a new record to internal/db.honeypot.net and increment the zone file"s serial number
3. Add a new record to external/db.honeypot.net and increment the zone file"s serial number

For a real treat, suppose that you also need to change bar.honeypot.net and baz.honeypot.net at the same time.

By hand, this involves editing three separate files and remembering to delete the entries where appropriate and add them back in, modified, where needed. If entries are accidentally left in common/db.honeypot.net, then both the old and new values will be served to every machine asking. If entries are accidentally not added to one of the internal or external zone files, then machines on the corresponding networks will be unable to resolve those hosts.

Enter ViDns.

With ViDns, this is simplified tremendously to one single command: vidns honeypot.net. It appends the three zone files together into one file (separated by highly visible comments), calls an editor to allow altering the file(s), splits out the results into the original three zone files, updates the serial number of every file that was changes, and writes out only the changes zone files. The editing process, then, is changed to:

1. vidns honeypot.net
2. Select the records to be moved and delete them.
3. Paste them into the appropriate zones and edit the values.
4. Save the file.

Usage

Edit all of the zone files comprising a domain

vidns domain.com

vidns db.domain.com

Edit only one zone file

vidns storage/domain.com

Update the serial numbers in a domain"s zone files without editing them

vidns -u domain.com

Why ViDns?

For "normal" zones

• ViDns knows where your zone files live. There"s no need to specify the full pathname to a file when you edit it.
• Automatically update serial numbers whenever any changes are made to a file. Conversely, don"t update the serial numbers when not necessary.

For "complex" zones

• See the able real-world example for details. In a nutshell, you can simplify an annoyingly complex process into a single command, and let ViDns do the bookkeeping for you.

For the future

ViDns was written in such a way that it would be very easy to add a syntax checker into the pipeline at a later date.

Notes

ViDns was written for the personal use of KirkStrauser to simplify the task of routine updates to DNS records on a FreeBSD server. Although it may readily be adapted to other settings, minor changes will probably be required.

• ViDns is available under the terms of the BSD license. Basically, you can do with it as you see fit, including using it as part of a commercial product.
• Requires Perl (any recent version should do)
• Requires the File::MkTemp module (easily available from CPAN)
• All zone file names are expected to begin with "db."
• It is currently HardCoded^? to call ViM^? to edit the files.
• All path names are currently HardCoded^?. By default, they are:
  • /var/named - The base directory
    • ./internal - Zone files for internal (private) views
    • ./external - Zone files for external (public) views
    • ./common - Segments of files to be included in internal and external zone files

Changes

• 1.5 - 2003-09-08
  • Added dependency checking for serial updates. If a file uses the $INCLUDE directive to insert the contents of another file, and the included file changes, then the parent"s serial number will be updated regardless of whether it was independently changed.
  • A new backup system stores the last several versions of each zone files for easy restoration or auditing.

-- KirkStrauser - 08 Sep 2003