Notice of plan to deprecate map zone file format

Victoria Risk vicky at isc.org
Fri Sep 10 12:36:43 UTC 2021



> On Sep 10, 2021, at 7:24 AM, Timothe Litt <litt at acm.org> 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.
> 
Actually, we are not sure there ARE any users. In fact, the one example I could come up with was Anand, who has replied to the list that he is in fact NOT using map zone.  I should have asked directly - is anyone on this list USING MAP ZONE format?

> After all the "other improvements in performance" that you cited, what is the performance difference between map and the other formats?

I don’t know that, to be honest. We don’t have the resources to benchmark everything. Maybe someone on this list could?  We would also like to be able to embark on a wholesale update to the rbtdb next year and this is the sort of thing that might complicate refactoring unnecessarily. 
> 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?
> 
>> If I knew that I would have said. 'Raw’ was much faster than the text version. Map was faster than raw. Raw is apparently not a problem to maintain.  I believe the improvement with raw was ~3x.
>> 

> 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???

Well, back when we added map zone format, startup time was a major pain point for some users. Now, it seems as though large operators are updating their zones all the time (also updating RPZ feeds) and efficiency in transfers seems to be a bigger issue. 

We don’t have any direct data on what features are being used, we can only judge based on complaints we receive via bug tickets or posts on this list. 
> 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?
> 
That is a good question. Can you answer it for yourself?

Thank you!

Vicky


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210910/945cb753/attachment.htm>


More information about the bind-users mailing list