Notice of plan to deprecate map zone file format

[Evan Hunt]

On Fri, Sep 10, 2021 at 07:24:19AM -0400, Timothe Litt wrote:
> Clearly map format solved a big problem for some users.  Asking whether
> it's OK to drop it with no statement of what those users would give up
> today is not reasonable.
> 
> After all the "other improvements in performance" that you cited, what
> is the performance difference between map and the other formats?

In recent benchmarks, map loaded about 1.5x faster than raw.  When we
first implemented it in 2014, it was coming out closer to 4x faster.

I suspect what's happened is that improvements to memory management, and
perhaps also changes in hardware used for benchmarking (SSD vs spinning
disk, for example?), have eroded the advantage that map had over raw - in
other words, it's not that map's slower now, but that raw has gotten faster.
And I'm not sure we would have chosen to incur the complexity cost of the
map format if it had only been a 1.5x speedup at the time.

Map has always been fragile - you can't copy files from one machine to
another, and it doesn't even reliably keep working on the same machine when
you upgrade BIND. It's always been recommended only for secondary zones,
so that if you upgrade BIND and your old map files stop working, it can
automatically retransfer the zones. Using map for primary zones is possible
but requires a lot of caution when upgrading or migrating; I don't think
very many people do that.

Recently a critical bug was discovered in which map files that were
generated by a previous version of BIND caused a crash in newer versions.
It took over a month for anybody to report the bug to us, which suggests
that the number of people willing to put up with such a finicky format
must be pretty small. (Or that the people who use it aren't keeping up with
regular software updates, I guess.)

So, this thread is to ask if anyone is currently relying on map format for
reasonable startup speed, and if so, could you compare it against raw and
see if you still really need it?

If the feature is not being used to any significant degree then it would be
good to simplify. It would also make it easier, maybe someday, to replace
our database structure with something more performant. (Not that we have any
specific plans for that, but it's something we talk about occasionally, and
it would be nice not to have to worry about map files when it came to
maintaining feature parity.)

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.