Using the 'map' zone file format in BIND

What is a zone file format?

A zone file is used to store the resource records for a zone. On a primary server, the zone file is created externally to BIND 9, and is usually kept in text format for convenience and flexibility in maintaining it. A primary server reads in the information that it finds in zone files without needing to know how that information got there. Primary zone data can be maintained using dynamic updates, or it can be maintained by using some third-party software (such as a text editor or an IPAM system) to edit the zone file. Dynamic update protocols enable BIND's in-memory zone information to be updated while BIND is running; the updated zone information is then written to the zone file(s). If a primary zone file is updated by some means external to BIND, then BIND must reload the entire zone file in order for those updates to take effect.

A secondary server receives its zone data from the primary server and saves that data by writing it to stable storage as a zone file. That is what makes it a secondary. The zones that it receives are stored locally as files, so that they do not need to be retrieved from the primary every time BIND restarts. When they are stored locally, they will be both written and read by the same software (BIND) and therefore can be encoded in a very specialized format if such a format can provide some advantage.

If a zone file is stored on a server in text format, that format must be encoded each time it is stored, and decoded each time the stored copy is loaded. For small zones this is not an issue, but a zone file with a million records in it can take quite a long time to encode and decode.

A zone file can be stored on a  server in raw format, which is the "wire format" in which a zone file is transmitted from primary to secondary. Unless specified otherwise, BIND 9 primary servers expect to find zone files in text format and BIND 9 secondary servers keep their zone files in raw format. (An aside: where DLZ is used, or where inline DNSSEC signing is used, the notion of zone files varies somewhat from what is described here.)

BIND 9.10 and later supports a map format for zone files, which is much faster but much more sensitive to changes in its processing environment. It can be used either on primary or secondary servers, but it is simplest to use text format on primary servers.

What is the "map" format for zone files and how do you use it?

While BIND is running, it keeps zone information in the computer's memory. What it means to decode a zone file is to read it from disk, find the information, and store that information in memory. If the zone file is written out to the disk exactly as it is stored in memory, using a technique called memory mapping, then it does not need to be decoded to be used. BIND can simply link to the file as if it were in memory, and the operating system will shortly ensure that it is in memory.

To specify map format for a zone file on a secondary server, just add the term

    masterfile-format map;

to the zone declaration, resulting in something resembling this:

    zone third.example.com {
         type secondary;
         file "sec/third.example.com";
         masterfile-format map;
         primaries {192.168.1.100;};
    };

The map format is much faster than raw format, because the zone file does not need to be processed before it is used. The zone data is just there. Exactly how fast it is depends on many details of the host operating system and hardware. The speed of accessing a map-format zone file depends on disk speeds, disk cache sizes and speeds, operating system memory management algorithms, hardware memory bus speeds, and other activity on the computer's backplane. ISC has observed speedups of 50x of map format over raw format, but has also observed speedups far less than that.

Deciding whether to use "map" format for zone files

There is little risk or inconvenience in using the map format on a secondary server. Zones enter a secondary server via zone-transfer protocols and are written to files by BIND and then read back by BIND. In normal operation there is no need for a person to look at a zone file stored on a secondary server, but if it does need to be inspected, the named-compilezone program can be used to encode and decode a map-format zone file. If BIND is upgraded, the operating system upgraded, or the server hardware replaced, you should delete the zone files and let them be re-created as part of BIND's normal secondary-to-primary synchronization.

You can use map format on a primary server, which will enable it to be started or restarted more quickly. But if you do, then you must have a way of creating and editing those files outside BIND. You can create an empty zone file in map format and then manage it via dynamic updates, or you can use a conversion tool that will translate between text and map format. The software tool named-compilezone will convert back and forth between map format and text format, so it is possible to set up a workflow for a primary server using map-format zone files. Whether this is too much of an inconvenience is something you will have to decide for yourself. If you do this, you must be certain to use the version of named-compilezone that was packaged with your version of BIND. They must match exactly.