Notice of plan to deprecate map zone file format

[Timothe Litt]

Vicky,

I never reflexively "howl in protest", but it's really hard to have an
opinion on this proposal without some data.

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?

For a case which took 'several hours' before map was introduced, what
would the restart time be for named if raw format was used now?

It's pretty clear to me that if map format saves a few seconds in the
worst case, it's not worth keeping.  If it saves hours for large
operators, then the alternative isn't adequate.  Maybe "map" isn't the
answer - how might 'raw' compare to a tuned database back end?  (Which
has other advantages for some.)  What if operators specified a priority
order for loading zones?  Or zones were loaded on demand during startup,
with low activity zones added as a background task?  Or???

A few data points would get you much more useful responses. 

A fair question for users would be what restart times are acceptable for
their environment - obviously a function of the number and size/content
of zones.  And is a restart "all or nothing", or would some
priority/sequencing of zone availability meet requirements?

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

On 09-Sep-21 15:13, Victoria Risk wrote:
> Greetings bind-users,
>
> The `map` zone file format was introduced in BIND
> 9.10. https://bind9.readthedocs.io/en/v9_16_20/reference.html?highlight=map%20zone#additional-file-formats
> <https://bind9.readthedocs.io/en/v9_16_20/reference.html?highlight=map
> zone#additional-file-formats>
>
> At the time, this format significantly sped up a named restart, which
> could take several hours in some situations. This new file format is
> very complicated, and maintaining it has proven difficult. Meanwhile,
> the performance advantage versus the `raw` format, or the default text
> files, has decreased as we have made other improvements in performance. 
>
> We would like to deprecate the `map` zone file format in future
> branches of BIND. The proposal is to deprecate the feature in the 9.16
> branch, (users will see a warning when this feature is used but it
> will still work through the end of the 9.16 branch), and to disable
> the feature in 9.20.0 (it will no longer work in this and subsequent
> versions). 
>
> Per our policy on deprecating named options, we are notifying the user
> mailing list.  You are welcome now to howl in protest or point out
> something we haven’t considered.  ;-)
>
> Regards,
>
> Vicky Risk
> Product Manager
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210910/bdcfcbb6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210910/bdcfcbb6/attachment-0001.bin>