Re: Notice of plan to deprecate map zone file format

[Ondřej Surý]

I am just going to point out that the 10 second speed up was measured on .net 
zone. Thus the calculations provided below have no practical impact because if 
anybody is loading 100k .net-sized zones on a single server they will have a 
different problem that the loading speed…

The goal of the initial email was to get feedback from serious users of the 
feature (if there are any). It seems that I need to say that we constantly look 
and work on improving BIND 9, and while we are going to drop the map masterfile 
format, the ad how internal benchmarks already show significant speed up when 
loading many zones between 9.11 and 9.16.

The map masterfile format was a smart idea at the time, but it’s extremely 
fragile, and it’s not a good use of the engineering time to spend time caring 
about it. I would rather make BIND 9 faster for everybody than fine tune 
extreme edge case.

Ondrej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 10. 9. 2021, at 19:44, Timothe Litt  wrote:
> 
> 
> I'm not a consumer of this and agree that it's up to users to speak up, so 
> I'll stop here - with one final observation.
> 
> The issue comment containing the benchmarks includes:
> 
>> Speedup provided by the map format does not seem significant enough to 
>> warrant the complexity of map format, especially when we take into account 
>> that the difference measured in terms of "real time" is in order of 10s of 
>> seconds.
> 10s of seconds per zone can certainly add up.  Call it 10 secs/zone * 100,000 
> zones = 1M sec / 3600 = 278 hrs saved.
> Suppose loading zones is not disk limited, and cores scale linearly (e.g. no 
> lock conflicts & an index lets each core find a zone to work on for free).  
> So give it 16 cores (each taking on one complete zone), and it's still 17 hrs 
> saved.  Real life won't be that efficient - meaning cores won't help that 
> much.
> 
> A new memory mapped data structure that didn't require "updating node 
> pointers" (e.g. that used offsets instead of pointers) may be worth 
> considering.  In current hardware and with a decent compiler and coding, the 
> apparent cost of this over absolute pointers may well be vanishingly small.
> 
> OK, that was two.
> 
> Timothe Litt
> ACM Distinguished Engineer
> --
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed. 
> On 10-Sep-21 12:56, Victoria Risk wrote:
>> 
> 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. 
>> 
>> 
>> I was wrong, and in fact we have benchmarked it. See 
>> https://gitlab.isc.org/isc-projects/bind9/-/issues/2882 for details. Map 
>> format is still faster than raw, but not so much faster that it warrants 
>> retaining it, given it is riskier, harder to maintain and we have no 
>> feedback from users that it is important to them.  It also seems not to work 
>> with large numbers of zones, (>100K) at least in current versions of 9.11 
>> and 9.16, which is further indication that it isn’t in wide use or we would 
>> have had complaints. 
>> 
>> We also have discussed internally that there are other factors, other than 
>> loading the zone files, that may have more impact on the time it takes a 
>> BIND server to restart.
>> 
>> If anyone out there is using it successfully, and wants us to keep this 
>> feature, this would be the time to speak up!
>> 
>> Thank you,
>> 
>> Vicky
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Notice of plan to deprecate map zone file format

[Ondřej Surý]

For the record, there’s small typo below - the stable major version where we 
plan to remove the map format is 9.18. E.g. this will happen in the next stable 
release rather than in 9.20 that’s going to be released in ~2024.

Ondrej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 9. 9. 2021, at 21:13, Victoria Risk  wrote:
> 
> 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). 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Notice of plan to deprecate map zone file format

[Evan Hunt]

On Fri, Sep 10, 2021 at 01:58:41PM -0400, Timothe Litt wrote:
> In fact, were you to come up with a data structure and loading scheme
> that made raw as fast as map, you could treat "map" as a hint that a
> user values speed over size & portability - and just write raw format
> instead.  Until the pendulum swings again.

Yep, I think that's how we'll do this, if we do it.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Notice of plan to deprecate map zone file format

[Timothe Litt]

On 10-Sep-21 13:11, Evan Hunt wrote:
> 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.)

Thanks for the history/data.

In my experience, the bigger the operator (of any system), the more
slowly they are likely to update it.

A month doesn't seem like a long time - everyone wants to be second to
update (except for CVEs, and even there I don't rush to update for CVEs
related to features I don't use).

> it would be nice not to have to worry about map files when it came to
> maintaining feature parity.)

I wouldn't worry all that much about blowing away old map files with a
version upgrade; they're pretty well documented as a cache, not a
primary format.  And you supply the tools to convert to a stable format.

In fact, were you to come up with a data structure and loading scheme
that made raw as fast as map, you could treat "map" as a hint that a
user values speed over size & portability - and just write raw format
instead.  Until the pendulum swings again.




OpenPGP_signature
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Notice of plan to deprecate map zone file format

[Timothe Litt]

I'm not a consumer of this and agree that it's up to users to speak up,
so I'll stop here - with one final observation.

The issue comment containing the benchmarks includes:

> Speedup provided by the |map| format does not seem significant enough
> to warrant the complexity of map format, especially when we take into
> account that the difference measured in terms of "real time" is in
> order of 10s of seconds.
10s of seconds *per zone* can certainly add up.  Call it 10 secs/zone *
100,000 zones = 1M sec / 3600 = 278 hrs *saved*.

Suppose loading zones is not disk limited, and cores scale linearly
(e.g. no lock conflicts & an index lets each core find a zone to work on
for free).  So give it 16 cores (each taking on one complete zone), and
it's still 17 hrs saved.  Real life won't be that efficient - meaning
cores won't help that much.

A new memory mapped data structure that didn't require "updating node
pointers" (e.g. that used offsets instead of pointers) may be worth
considering.  In current hardware and with a decent compiler and coding,
the apparent cost of this over absolute pointers may well be vanishingly
small.

OK, that was two.

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

On 10-Sep-21 12:56, Victoria Risk wrote:
>
 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.
>
>
> I was wrong, and in fact we have benchmarked it.
> See https://gitlab.isc.org/isc-projects/bind9/-/issues/2882
>  for details.
> Map format is still faster than raw, but not so much faster that it
> warrants retaining it, given it is riskier, harder to maintain and we
> have no feedback from users that it is important to them.  It also
> seems not to work with large numbers of zones, (>100K) at least in
> current versions of 9.11 and 9.16, which is further indication that it
> isn’t in wide use or we would have had complaints. 
>
> We also have discussed internally that there are other factors, other
> than loading the zone files, that may have more impact on the time it
> takes a BIND server to restart.
>
> If anyone out there is using it successfully, and wants us to keep
> this feature, this would be the time to speak up!
>
> Thank you,
>
> Vicky
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: 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 -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Notice of plan to deprecate map zone file format

[Victoria Risk]

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


I was wrong, and in fact we have benchmarked it. See 
https://gitlab.isc.org/isc-projects/bind9/-/issues/2882 
 for details. Map 
format is still faster than raw, but not so much faster that it warrants 
retaining it, given it is riskier, harder to maintain and we have no feedback 
from users that it is important to them.  It also seems not to work with large 
numbers of zones, (>100K) at least in current versions of 9.11 and 9.16, which 
is further indication that it isn’t in wide use or we would have had 
complaints. 

We also have discussed internally that there are other factors, other than 
loading the zone files, that may have more impact on the time it takes a BIND 
server to restart.

If anyone out there is using it successfully, and wants us to keep this 
feature, this would be the time to speak up!

Thank you,

Vicky___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Notice of plan to deprecate map zone file format

[Timothe Litt]

On 10-Sep-21 08:36, Victoria Risk wrote:
>
>
>> On Sep 10, 2021, at 7:24 AM, 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.
>>
> 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?
>
Well, if the answer is "no one", that simplifies matters :-)

I do remember that startup time was a big issue before map came out, and
that the complaints subsided thereafter.  No personal knowledge as to
whether that was cause and effect or a realignment of the planets.  In
general, I don't look to Astrology for answers :-)

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

IIRC, when I did some work on the stats channel & was concerned with
scalability, Evan said that you keep some large datasets (1M+zones)
around for testing and produced some numbers for that.  So it ought to
be possible to get some basic data.

I'm not suggesting a full benchmarking campaign -but one or two
datapoints are a lot better than none.  E.g. If there's no difference
with 1 or 10M zones with, say, 10K records each, it's pretty clear that
map's time is past.  If it's orders of magnitude faster (and it's used),
it's not.

I don't remember - did your user survey ask about how many/how large
zones people serve?  I vaguely think so, but it's been a while...

>> 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.
>>>
>
I think the questions are: (a) is startup time an issue (however it's
solved)?, (b) if so, is map format the solution? (c) If it is and people
are using it, what would the consequences be to them if it went away?
(d) If it is, and people aren't using it - is the documentation too
scary (as Anand said it is for him)?
>> 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. 
>
What I was getting as is how hard the definition of "startup time" is. 
Time to serving all zones?  Important zones? Is it OK for responses to
be slow during startup, or is startup only complete when responses are
at nominal speed?

I wonder if this comes from large operators using a database(DLZ)  back
end.  Database developers tend to have a single-minded focus on
performance, and direct updates are probably faster than going thru
named & its generalized authentication/validation.  Plus, depending on
how you set up your server architecture, DB replication can replace DNS
zone transfers.

> 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.
You did a survey a while back...
>>
>> 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?

Sure.  I'm not a large operator, but I've always thought big and
implemented smaller.  About 350 zones, 2 real views and 2 static-stub
recursive views.  50-a couple of hundred records/zone - not counting the
DNSSEC signatures & overhead that named generates.  ~10 servers.  Plus a
3rd party backup service.  Anything under a minute is a reasonable
startup time for named - though most of my servers are underpowered.

Re: Notice of plan to deprecate map zone file format

[Victoria Risk]

> On Sep 10, 2021, at 7:24 AM, 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.
> 
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


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 'max-cache-size' Value on FreeBSD-13.0

[Mark Tinka]

On 9/10/21 12:35, sth...@nethelp.no wrote:


Freebsd 12.2-STABLE here with servers running BIND 9.16.15, 9.16.18
and 9.16.20, all using libuv 1.41.0, all installed from ports. Typical
query load from around 3k qps to around 14k qps. No sign of any memory
leak.


Would be interesting to hear your experiences when/if you do move to 
FreeBSD-13.0.


Still going nice and stable with 9.11.

Mark.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: 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
>  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


OpenPGP_signature
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 'max-cache-size' Value on FreeBSD-13.0

[sthaug]

>> 2.5 days in, and 9.11 is still running good, with no crashing.
>> 
>> Safe to say that this memory leak is definitely an issue with 9.16.
> 
> Which version of libuv are you using? I am running 1.41 and the latest is 
> 1.42.
> 
> I haven’t seen that behavior and my recursives handle about 100,000 requests 
> per minute.

Freebsd 12.2-STABLE here with servers running BIND 9.16.15, 9.16.18
and 9.16.20, all using libuv 1.41.0, all installed from ports. Typical
query load from around 3k qps to around 14k qps. No sign of any memory
leak.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 'max-cache-size' Value on FreeBSD-13.0

[Mark Tinka]

On 9/10/21 10:29, Borja Marcos wrote:


Which version of libuv are you using? I am running 1.41 and the latest is 1.42.


I'm running libuv-1.41.0.



I haven’t seen that behavior and my recursives handle about 100,000 requests 
per minute.

Just in case I have updated libuv on one of them.


I see 1.42.0 was released 4 days ago.



Also, did you install bind 9.16 from ports or from a package? From ports, which 
options
did you enable?


From ports with default options:

    - DNSTAP
    - DOCS
    - IDN
    - JSON
    - MANPAGES
    - TCP_FASTOPEN
    - DLZ_FILESYSTEM

Mark.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 'max-cache-size' Value on FreeBSD-13.0

[Borja Marcos]

> On 9 Sep 2021, at 06:59, Mark Tinka  wrote:
> 
> 2.5 days in, and 9.11 is still running good, with no crashing.
> 
> Safe to say that this memory leak is definitely an issue with 9.16.

Which version of libuv are you using? I am running 1.41 and the latest is 1.42.

I haven’t seen that behavior and my recursives handle about 100,000 requests 
per minute.

Just in case I have updated libuv on one of them.

Also, did you install bind 9.16 from ports or from a package? From ports, which 
options
did you enable?

Cheers,




Borja.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Notice of plan to deprecate map zone file format

[Anand Buddhdev]

On 09/09/2021 21:13, Victoria Risk wrote:

Hi Vicky,


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).
When I read about the "map" format, I didn't feel comfortable using it, 
because it felt risky.


I think you're making the right decision here, and I welcome the 
deprecation and eventual removal of this feature.


Regards,
Anand
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users