Edit all of the zone files comprising a domain

Edit only one zone file

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

vidns -u domain.com

• • /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.

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

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

vidns domain.com

vidns db.domain.com

vidns storage/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 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:
  • /etc/namedb - The base directory
  • /etc/namedb/internal - Zone files for internal (private) views
  • /etc/namedb/external - Zone files for external (public) views
  • /etc/namedb/common - Segments of files to be included in internal and external zone files

-- KirkStrauser - 07 Jan 2003