Re: High memory consumption in bind 9.18.2

2022-07-25 Thread Ondřej Surý
There’s no generic tool. The one that was mentioned in the article was tailored 
for that specific bug in jemalloc.

In any case, the article is only tangential to the topic here. It talks about a 
issue in the jemalloc that was triggered by a specific code in named.

Ondřej
--
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 26. 7. 2022, at 0:14, Doug Whitfield  wrote:
> 
> I see there is a reproducer.c mentioned in 
> https://www.isc.org/blogs/jemalloc-glitch/. I do not see a link to the full 
> code. Is this the testing tool that the community prefers? Where can we find 
> this tool?
-- 
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: CNAME resolution weirdness

2022-07-25 Thread Ondřej Surý
By using host, you are missing the important bits - the packet sizes and the 
header bits. Most probably the response doesn’t fit into 512 bytes, so it’s 
truncated. Which is not a problem because any compliant software will: a) use 
EDNS with at least 1232 buffer size, b) retry over TCP if it sees truncation.

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 26. 7. 2022, at 1:02, Boian Bonev via bind-users 
>  wrote:
> 
> Hello,
> 
> For the Devuan project we use a DNS round robin for mirrors - deb.devuan.org.
> Mostly for cleanliness and separation which part is maintained by humans and
> which by tools, there is a separate zone rr.devuan.org fully maintained by
> tools. deb.devuan.org is CNAME of deb.rr.devuan.org, which in turn is the list
> of all up-to-date mirrors' A and . The master DNS server is not publicly
> visible and the only visible ones are authoritative slaves (for both zones).
> 
> The weird part is that bind is replying with CNAME and  records only 
> (using
> host, because it has shorter output, result is same with other tools):
> 
> # host deb.devuan.org ns4.devuan.dev
> Using domain server:
> Name: ns4.devuan.dev
> Address: 2a01:9e40::108#53
> Aliases: 
> 
> deb.devuan.org is an alias for deb.rr.devuan.org.
> deb.rr.devuan.org has IPv6 address 2801:82:80ff:8000::2
> deb.rr.devuan.org has IPv6 address 2001:4190:801c:1::150
> deb.rr.devuan.org has IPv6 address 2a0a:e5c0:2:2:400:c8ff:fe68:bef3
> deb.rr.devuan.org has IPv6 address 2a01:4f9:2a:fa9::2
> deb.rr.devuan.org has IPv6 address 2a01:9e40::180
> deb.rr.devuan.org has IPv6 address 2a01:4f8:162:7293::14
> deb.rr.devuan.org has IPv6 address 2001:e42:102:1704:160:16:137:156
> deb.rr.devuan.org has IPv6 address 2a01:4f8:140:1102:2b76:955d:b48f:bdf3
> deb.rr.devuan.org has IPv6 address 2607:5300:61:95f:7283:11d9:f86:e691
> deb.rr.devuan.org has IPv6 address 2001:638:a000:1021:21::1
> deb.rr.devuan.org has IPv6 address 2001:4ca0:4300::1:19
> deb.rr.devuan.org has IPv6 address 2a02:2a38:1:400:422a:422a:422a:422a
> 
> # nslookup -class=CHAOS -type=txt version.bind ns4.devuan.dev
> Server:ns4.devuan.dev
> Address:2a01:9e40::108#53
> 
> version.bindtext = "9.16.27-Debian"
> 
> I did check with RFC 1034 and the above does not look like a proper reply as
> per my understanding. If bind does not see itself as auth for rr.devuan.org, 
> it
> should reply only with the CNAME, else it should include the A records too.
> 
> I have tried various options - enabling recursion makes it behave correctly 
> but
> that is not an option for a public DNS. Replacing bind with nsd also fixes the
> behavior. As a side note knot behaves exactly like bind. I would prefer to run
> different software across the slaves. The next thing was to try with the most
> recent Debian package from the testing distribution:
> 
> The only related option in named.conf.options is "recursion no;"
> 
> # host deb.devuan.org 127.0.0.1
> Using domain server:
> Name: 127.0.0.1
> Address: 127.0.0.1#53
> Aliases: 
> 
> deb.devuan.org is an alias for deb.rr.devuan.org.
> deb.rr.devuan.org has IPv6 address 2001:638:a000:1021:21::1
> deb.rr.devuan.org has IPv6 address 2a0a:e5c0:2:2:400:c8ff:fe68:bef3
> deb.rr.devuan.org has IPv6 address 2801:82:80ff:8000::2
> deb.rr.devuan.org has IPv6 address 2001:4ca0:4300::1:19
> deb.rr.devuan.org has IPv6 address 2001:e42:102:1704:160:16:137:156
> deb.rr.devuan.org has IPv6 address 2a01:4f8:162:7293::14
> deb.rr.devuan.org has IPv6 address 2001:878:346::116
> deb.rr.devuan.org has IPv6 address 2001:4190:801c:1::150
> deb.rr.devuan.org has IPv6 address 2a01:4f9:2a:fa9::2
> deb.rr.devuan.org has IPv6 address 2a01:4f8:140:1102:2b76:955d:b48f:bdf3
> deb.rr.devuan.org has IPv6 address 2607:5300:61:95f:7283:11d9:f86:e691
> deb.rr.devuan.org has IPv6 address 2a01:9e40::180
> deb.rr.devuan.org has IPv6 address 2a02:2a38:1:400:422a:422a:422a:422a
> 
> # nslookup -class=CHAOS -type=txt version.bind 127.0.0.1
> Server:127.0.0.1
> Address:127.0.0.1#53
> 
> version.bindtext = "9.18.4-2-Debian"
> 
> 
> Please advise what is happening - is that expected behavior, a configuration
> option is missing or there is a bug in bind?
> 
> With best regards,
> b.
> 
> 
> -- 
> 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
-- 
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

CNAME resolution weirdness

2022-07-25 Thread Boian Bonev via bind-users
Hello,

For the Devuan project we use a DNS round robin for mirrors - deb.devuan.org.
Mostly for cleanliness and separation which part is maintained by humans and
which by tools, there is a separate zone rr.devuan.org fully maintained by
tools. deb.devuan.org is CNAME of deb.rr.devuan.org, which in turn is the list
of all up-to-date mirrors' A and . The master DNS server is not publicly
visible and the only visible ones are authoritative slaves (for both zones).

The weird part is that bind is replying with CNAME and  records only (using
host, because it has shorter output, result is same with other tools):

# host deb.devuan.org ns4.devuan.dev
Using domain server:
Name: ns4.devuan.dev
Address: 2a01:9e40::108#53
Aliases: 

deb.devuan.org is an alias for deb.rr.devuan.org.
deb.rr.devuan.org has IPv6 address 2801:82:80ff:8000::2
deb.rr.devuan.org has IPv6 address 2001:4190:801c:1::150
deb.rr.devuan.org has IPv6 address 2a0a:e5c0:2:2:400:c8ff:fe68:bef3
deb.rr.devuan.org has IPv6 address 2a01:4f9:2a:fa9::2
deb.rr.devuan.org has IPv6 address 2a01:9e40::180
deb.rr.devuan.org has IPv6 address 2a01:4f8:162:7293::14
deb.rr.devuan.org has IPv6 address 2001:e42:102:1704:160:16:137:156
deb.rr.devuan.org has IPv6 address 2a01:4f8:140:1102:2b76:955d:b48f:bdf3
deb.rr.devuan.org has IPv6 address 2607:5300:61:95f:7283:11d9:f86:e691
deb.rr.devuan.org has IPv6 address 2001:638:a000:1021:21::1
deb.rr.devuan.org has IPv6 address 2001:4ca0:4300::1:19
deb.rr.devuan.org has IPv6 address 2a02:2a38:1:400:422a:422a:422a:422a

# nslookup -class=CHAOS -type=txt version.bind ns4.devuan.dev
Server: ns4.devuan.dev
Address:2a01:9e40::108#53

version.bindtext = "9.16.27-Debian"

I did check with RFC 1034 and the above does not look like a proper reply as
per my understanding. If bind does not see itself as auth for rr.devuan.org, it
should reply only with the CNAME, else it should include the A records too.

I have tried various options - enabling recursion makes it behave correctly but
that is not an option for a public DNS. Replacing bind with nsd also fixes the
behavior. As a side note knot behaves exactly like bind. I would prefer to run
different software across the slaves. The next thing was to try with the most
recent Debian package from the testing distribution:

The only related option in named.conf.options is "recursion no;"

# host deb.devuan.org 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

deb.devuan.org is an alias for deb.rr.devuan.org.
deb.rr.devuan.org has IPv6 address 2001:638:a000:1021:21::1
deb.rr.devuan.org has IPv6 address 2a0a:e5c0:2:2:400:c8ff:fe68:bef3
deb.rr.devuan.org has IPv6 address 2801:82:80ff:8000::2
deb.rr.devuan.org has IPv6 address 2001:4ca0:4300::1:19
deb.rr.devuan.org has IPv6 address 2001:e42:102:1704:160:16:137:156
deb.rr.devuan.org has IPv6 address 2a01:4f8:162:7293::14
deb.rr.devuan.org has IPv6 address 2001:878:346::116
deb.rr.devuan.org has IPv6 address 2001:4190:801c:1::150
deb.rr.devuan.org has IPv6 address 2a01:4f9:2a:fa9::2
deb.rr.devuan.org has IPv6 address 2a01:4f8:140:1102:2b76:955d:b48f:bdf3
deb.rr.devuan.org has IPv6 address 2607:5300:61:95f:7283:11d9:f86:e691
deb.rr.devuan.org has IPv6 address 2a01:9e40::180
deb.rr.devuan.org has IPv6 address 2a02:2a38:1:400:422a:422a:422a:422a

# nslookup -class=CHAOS -type=txt version.bind 127.0.0.1
Server: 127.0.0.1
Address:127.0.0.1#53

version.bindtext = "9.18.4-2-Debian"


Please advise what is happening - is that expected behavior, a configuration
option is missing or there is a bug in bind?

With best regards,
b.


-- 
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: High memory consumption in bind 9.18.2

2022-07-25 Thread Doug Whitfield
Hi Ondřej,

I see there is a reproducer.c mentioned in 
https://www.isc.org/blogs/jemalloc-glitch/. I do not see a link to the full 
code. Is this the testing tool that the community prefers? Where can we find 
this tool?

I wonder if a lot of this user confusion could be fixed by simply rewording the 
documentation at https://kb.isc.org/docs/bind-memory-consumption-explained . 
There is this piece: “There is a change in BIND 9.18.0, which is partly 
backported to 9.16.25, which reduces BIND's memory consumption down to levels 
similar to those with 9.11.“

I wonder if simply adding the words “in most cases” to the end of the sentence 
might make it more clear that the 10% increase in memory is not so much a bug 
as a different use case.

Best Regards,
Doug Whitfield

From: bind-users  on behalf of Ondřej Surý 

Date: Monday, July 25, 2022 at 08:54
To: Raman kumar 
Cc: ML BIND Users 
Subject: Re: High memory consumption in bind 9.18.2
I can’t really parse your message. I’ve repeatedly asked you to provide a 
reproducer. And yet again you come and ask that we do the debugging for you.

The currency here that you need to pay to get help is sharing - sharing the 
information, sharing the experience. Don’t mistake free software for free 
buffet where you come and just take.

And don’t be mistaken - I was not helping you specifically, I was just 
disputing your claim that BIND 9.18 takes more memory than 9.16 because that 
claim didn’t match our own measurements.

Have a nice day,
--
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 25. 7. 2022, at 15:11, Raman kumar  wrote:

Thanks Ondřej
We really appreciate your help in debugging this issue.

Observations that we have shared are with 32M data of 15 characters and we have 
configured jemalloc and bind using.
Downloaded the jemalloc-5.3.0.tar.bz2 and configure using below command
# ./configure --prefix=/usr
Downloaded bind 9.18.3 from ISC website
# ./configure --prefix=/opt/bind --sysconfdir=/etc/opt/bind --with-openssl=no 
--disable-doh

•   Bind compiled with openssl 1.0 and openssl 1.1 behavior was the same, 
in 9.18.3 memory usage was high wrt 9.16.21.
Can you please guide us about your configuration and compilation process after 
which you observed low memory usage?

If possible can you please share the named.conf files and the loading mechanism 
followed.

Regards,
Raman

On Thu, Jul 21, 2022 at 9:00 PM Ondřej Surý 
mailto:ond...@isc.org>> wrote:
Hey,

I did a measurement with 1M small generated zones that we are
using internally for the performance testing and here are some numbers:

The measured values are USS/PSS/RSS using `smem -P named -k`

BIND 9.16 w/o jemalloc: 10.9G/10.9G/10.9G (default configuration)
BIND 9.16 with jemalloc: 10.1G/10.2G/10.2G [1]

BIND 9.18 w/o jemalloc: 10.7G/10.7G/10.7G (not recommended)
BIND 9.18 with jemalloc: 9.9G/9.9G/9.9G (default configuration)

BIND 9.19 w/o jemalloc: 10.5G/10.5G/10.6G
BIND 9.19 with jemalloc: 9.8G/9.8G/9.8G [2]

This is consistent with our other measurements that the memory
usage is slightly lower with 9.18 compared to 9.16.

As you hadn’t shared any other details, there’s not much we can
do here, so you are pretty much on your own. But I would say that
1GB extra of memory in the context of loading 1M zones is not
worth too much effort.

1. just preloading jemalloc saves some memory as compared to the default system 
allocator
2. our expectations are to go even lower during the 9.19/9.20 development 
cycle, but no promises yet

Cheers,
--
Ondřej Surý (He/Him)
ond...@isc.org

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

> On 11. 7. 2022, at 6:25, Ondřej Surý mailto:ond...@isc.org>> 
> wrote:
>
> Hi,
>
> yes, I did. And I see no problem here. The software changes between the 
> versions and roughly 10% increase doesn’t seem like something that should be 
> worrying or worth any deep investigation. You simply cannot expect “faster”, 
> “better”, “contains new features” and *“same”* together.
>
> Ondřej
> --
> 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 11. 7. 2022, at 6:09, Raman kumar 
>> mailto:kumarraman@gmail.com>> wrote:
>>
>> 
>> Hello,
>>
>> Did you get a chance to look into the data that I shared above? The 
>> tools(ps_mem, pmap ) that you recommended to compare the RAM consumption 
>> between 9.18.x and 9.16.x are also showing that memory consumption is more 
>> in 9.18.x compared to 9.16.x.
>>
>> Thanks in advance.
>>
>> Regards,
>> Raman
>>
>>
>>
>>
>> On Fri, Jul 1, 2022 at 9:08 PM Raman kumar 
>> mailto:kumarraman@gmail.com>> wrote:
>> Hello,
>>
>> In continuation to my previous mails, sharing memory usage by bind 9.16.21 
>> 

Re: How to make SRV records work with caching resolvers?

2022-07-25 Thread Peter
On Thu, Jul 14, 2022 at 06:22:47PM +0200, Ondřej Surý wrote:
! Could you for the purpose of the debugging share the DNS traffic between the 
phone device and the resolver?
! 
! I think stepping back a little might help debug the issue. Perhaps people on 
the list might notice something that might help.
! 
! Ondrej

Hi Ondrej,

thanks for Your reply. I tried to obtain something reproducible, but
with no luck. These failures are a bit difficult to catch, they happen
mostly deep at night, for whatever reason. (And in any case a reset of
the phone does fix the issue.) Once I tried to analyze the failure and
noticed the partial information in the additional section, as
described - so I thought I had identified the issue (and should
occasionally learn how this should actually work - as I did now).

Now when I log the entire DNS traffic, I don't see the same pattern
appearing again. (Obviousely there can be many other reasons for a
temporary outage.)
The plan is now to put this on hold until it appears at annoying daytimes
again, and ideally obtain a kind of VoIP-proxy or PBX to put in between.

-- PMc


! > On 13. 7. 2022, at 13:18, Peter  wrote:
! > 
! > 
! > My Telco has removed the A record for their VoIP server, and now has
! > only SRV data there - which seems not to work properly.
! > 
! > The SRV data contains various services (SIP via UDP, TCP, secure
! > TCP, whatever), and these get individual expiry counters in the
! > caching resolver.
! > So when a telephone sends a query, the caching resolver will provide
! > that data in the "Additional section" - but only those records that
! > have not yet expired. 
! > 
! > If the configured service (the one the telephone should use) is no
! > longer contained in the answer (but others are still present), the
! > telephone goes offline until all the records have expired and a new
! > authoritative query is made.
! > 
! > The Telco is of no help - they just want to sell their own equipment.
! > 
! > The telphones (Alcatel) are the usual linux plastic box, and I cannot
! > easily hack these. It probably does not behave fully correct, but
! > also not fully wrong.
! > 
! > In BIND/named I didn't find an easy approach to fix the issue - it
! > doesn't look like it is supposed to be fixed there. And before I go
! > for the more difficult approaches, I would like to ask how this
! > is actually supposed to work, at all.
! > 
! > 
! > -- PMc
! > -- 
! > 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
! 
-- 
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: Basic setup instructions

2022-07-25 Thread G.W. Haywood via bind-users

Hi there,

On Mon, 25 Jul 2022, Gene Ammerman wrote:


I am on a Mac running macOS 10.10 with server 5.7 and I just need to
setup DNS for this.


Your meaning is not clear to me.  When you say

"I just need to setup DNS"

which of the following do you mean:

(a) I need applications which run on the Mac to be able to resolve
domain names so that I can for example send email and browse the Web.

(b) I need to host a DNS server of my own, which will serve requests
for information about my own domains from machines all over the planet.
I will be responsible for providing that information, for keeping both
it and the DNS server up to date, for ensuring that the host is secure,
and for the hundred and one other things a DNS administrator has to do.

(c) something else.

--

73,
Ged.
--
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: Basic setup instructions

2022-07-25 Thread Ondřej Surý
Sorry, but you are being too terse. What is DNS setup? Which website? What 
*exactly* are you doing? Would you be able to help yourself with such little 
information you gave us?

Ondřej 
--
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 25. 7. 2022, at 16:19, Gene Ammerman  wrote:
> 
> So I have tried this even with macOS to even 12.4. But I am still not able 
> to get DNS setup on my machine using the instructions from the web site. Is 
> there any other instructions to follow?
> 
> 
> Respectfully,
> 
> Gene Ammerman 
> Apple Support Senior Advisor
> Business & Education
> 
>> On Jul 25, 2022, at 8:11 AM, Ondřej Surý  wrote:
>> 
>> macOS 10.10 reach end-of-life 5 years ago. You can try installing recent 
>> enough compiler with C11/C17 support and up-to-date libraries, but you are 
>> mostly on your own.
>> 
>> Ondřej
>> --
>> 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 25. 7. 2022, at 16:02, Gene Ammerman via bind-users 
  wrote:
>>> 
>>> Is there a more basic setup instruction guide than what is provided on the 
>>> web site?
>>> 
>>> I am on a Mac running macOS 10.10 with server 5.7 and I just need to setup 
>>> DNS for this.
>>> 
>>> Thank you
>>> 
>>> 
>>> Respectfully,
>>> 
>>> Gene Ammerman 
>>> Apple Support Senior Advisor
>>> Business & Education
>>> 
>>> -- 
>>> 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
> 
-- 
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: Basic setup instructions

2022-07-25 Thread Greg Choules via bind-users
Hi Gene.
Please can you post a link to 'the website' you refer to?
Where have you got to so far? BIND requires one config file - named.conf -
which, at its simplest, doesn't need to contain much at all; the defaults
should pretty much just work. But let's start with what you have now and,
if possible, any error messages you see when trying to start it.

Greg

On Mon, 25 Jul 2022 at 15:19, Gene Ammerman via bind-users <
bind-users@lists.isc.org> wrote:

> So I have tried this even with macOS to even 12.4. But I am still not able
> to get DNS setup on my machine using the instructions from the web site. Is
> there any other instructions to follow?
>
>
> Respectfully,
>
> Gene Ammerman
> Apple Support Senior Advisor
> Business & Education
>
> > On Jul 25, 2022, at 8:11 AM, Ondřej Surý  wrote:
> >
> > macOS 10.10 reach end-of-life 5 years ago. You can try installing recent
> enough compiler with C11/C17 support and up-to-date libraries, but you are
> mostly on your own.
> >
> > Ondřej
> > --
> > 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 25. 7. 2022, at 16:02, Gene Ammerman via bind-users <
> bind-users@lists.isc.org> wrote:
> >>
> >> Is there a more basic setup instruction guide than what is provided on
> the web site?
> >>
> >> I am on a Mac running macOS 10.10 with server 5.7 and I just need to
> setup DNS for this.
> >>
> >> Thank you
> >>
> >>
> >> Respectfully,
> >>
> >> Gene Ammerman
> >> Apple Support Senior Advisor
> >> Business & Education
> >>
> >> --
> >> 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
>
> --
> 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
>
-- 
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: Basic setup instructions

2022-07-25 Thread Gene Ammerman via bind-users
So I have tried this even with macOS to even 12.4. But I am still not able to 
get DNS setup on my machine using the instructions from the web site. Is there 
any other instructions to follow?


Respectfully,

Gene Ammerman 
Apple Support Senior Advisor
Business & Education

> On Jul 25, 2022, at 8:11 AM, Ondřej Surý  wrote:
> 
> macOS 10.10 reach end-of-life 5 years ago. You can try installing recent 
> enough compiler with C11/C17 support and up-to-date libraries, but you are 
> mostly on your own.
> 
> Ondřej
> --
> 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 25. 7. 2022, at 16:02, Gene Ammerman via bind-users 
>>  wrote:
>> 
>> Is there a more basic setup instruction guide than what is provided on the 
>> web site?
>> 
>> I am on a Mac running macOS 10.10 with server 5.7 and I just need to setup 
>> DNS for this.
>> 
>> Thank you
>> 
>> 
>> Respectfully,
>> 
>> Gene Ammerman 
>> Apple Support Senior Advisor
>> Business & Education
>> 
>> -- 
>> 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

-- 
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: Basic setup instructions

2022-07-25 Thread Ondřej Surý
macOS 10.10 reach end-of-life 5 years ago. You can try installing recent enough 
compiler with C11/C17 support and up-to-date libraries, but you are mostly on 
your own.

Ondřej
--
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 25. 7. 2022, at 16:02, Gene Ammerman via bind-users 
>  wrote:
> 
> Is there a more basic setup instruction guide than what is provided on the 
> web site?
> 
> I am on a Mac running macOS 10.10 with server 5.7 and I just need to setup 
> DNS for this.
> 
> Thank you
> 
> 
> Respectfully,
> 
> Gene Ammerman 
> Apple Support Senior Advisor
> Business & Education
> 
> -- 
> 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
-- 
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


Basic setup instructions

2022-07-25 Thread Gene Ammerman via bind-users
Is there a more basic setup instruction guide than what is provided on the web 
site?

I am on a Mac running macOS 10.10 with server 5.7 and I just need to setup DNS 
for this.

Thank you


Respectfully,

Gene Ammerman 
Apple Support Senior Advisor
Business & Education

-- 
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: High memory consumption in bind 9.18.2

2022-07-25 Thread Ondřej Surý
I can’t really parse your message. I’ve repeatedly asked you to provide a 
reproducer. And yet again you come and ask that we do the debugging for you.

The currency here that you need to pay to get help is sharing - sharing the 
information, sharing the experience. Don’t mistake free software for free 
buffet where you come and just take.

And don’t be mistaken - I was not helping you specifically, I was just 
disputing your claim that BIND 9.18 takes more memory than 9.16 because that 
claim didn’t match our own measurements.

Have a nice day,
--
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 25. 7. 2022, at 15:11, Raman kumar  wrote:
> 
> 
> Thanks Ondřej
> We really appreciate your help in debugging this issue.
> 
> Observations that we have shared are with 32M data of 15 characters and we 
> have configured jemalloc and bind using.
> Downloaded the jemalloc-5.3.0.tar.bz2 and configure using below command
> # ./configure --prefix=/usr
> Downloaded bind 9.18.3 from ISC website
> # ./configure --prefix=/opt/bind --sysconfdir=/etc/opt/bind --with-openssl=no 
> --disable-doh
> 
> ·   Bind compiled with openssl 1.0 and openssl 1.1 behavior was the same, 
> in 9.18.3 memory usage was high wrt 9.16.21.
> 
> Can you please guide us about your configuration and compilation process 
> after which you observed low memory usage?
> 
> If possible can you please share the named.conf files and the loading 
> mechanism followed.
> 
> Regards,
> Raman
> 
>> On Thu, Jul 21, 2022 at 9:00 PM Ondřej Surý  wrote:
>> Hey,
>> 
>> I did a measurement with 1M small generated zones that we are
>> using internally for the performance testing and here are some numbers:
>> 
>> The measured values are USS/PSS/RSS using `smem -P named -k`
>> 
>> BIND 9.16 w/o jemalloc: 10.9G/10.9G/10.9G (default configuration)
>> BIND 9.16 with jemalloc: 10.1G/10.2G/10.2G [1]
>> 
>> BIND 9.18 w/o jemalloc: 10.7G/10.7G/10.7G (not recommended)
>> BIND 9.18 with jemalloc: 9.9G/9.9G/9.9G (default configuration)
>> 
>> BIND 9.19 w/o jemalloc: 10.5G/10.5G/10.6G
>> BIND 9.19 with jemalloc: 9.8G/9.8G/9.8G [2]
>> 
>> This is consistent with our other measurements that the memory
>> usage is slightly lower with 9.18 compared to 9.16.
>> 
>> As you hadn’t shared any other details, there’s not much we can
>> do here, so you are pretty much on your own. But I would say that
>> 1GB extra of memory in the context of loading 1M zones is not
>> worth too much effort.
>> 
>> 1. just preloading jemalloc saves some memory as compared to the default 
>> system allocator
>> 2. our expectations are to go even lower during the 9.19/9.20 development 
>> cycle, but no promises yet
>> 
>> Cheers,
>> --
>> Ondřej Surý (He/Him)
>> ond...@isc.org
>> 
>> My working hours and your working hours may be different. Please do not feel 
>> obligated to reply outside your normal working hours.
>> 
>> > On 11. 7. 2022, at 6:25, Ondřej Surý  wrote:
>> > 
>> > Hi,
>> > 
>> > yes, I did. And I see no problem here. The software changes between the 
>> > versions and roughly 10% increase doesn’t seem like something that should 
>> > be worrying or worth any deep investigation. You simply cannot expect 
>> > “faster”, “better”, “contains new features” and *“same”* together.
>> > 
>> > Ondřej
>> > --
>> > 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 11. 7. 2022, at 6:09, Raman kumar  wrote:
>> >> 
>> >> 
>> >> Hello,
>> >> 
>> >> Did you get a chance to look into the data that I shared above? The 
>> >> tools(ps_mem, pmap ) that you recommended to compare the RAM consumption 
>> >> between 9.18.x and 9.16.x are also showing that memory consumption is 
>> >> more in 9.18.x compared to 9.16.x.
>> >> 
>> >> Thanks in advance.
>> >> 
>> >> Regards,
>> >> Raman
>> >> 
>> >> 
>> >> 
>> >> 
>> >> On Fri, Jul 1, 2022 at 9:08 PM Raman kumar  
>> >> wrote:
>> >> Hello,
>> >> 
>> >> In continuation to my previous mails, sharing memory usage by bind 
>> >> 9.16.21 and 9.18.3 using pmap and ps_mem tools.
>> >> 
>> >> We have observed memory usage in 9.18.3 is higher by approximately 1.10 
>> >> GB with the same amount of data loaded on both bind versions.
>> >> Attaching pmap output for both bind versions in this mail which also 
>> >> shows memory used by heap/mmap on 9.18.3 is ~10.16GB whereas 9.16.21 was 
>> >> consuming ~9.05GB
>> >> 
>> >> 9.16.21
>> >> ==
>> >> ps_mem 7543
>> >> Private  +   Shared  =  RAM used Program
>> >> 9.1 GiB + 262.5 KiB =   9.1 GiB named
>> >> 
>> >> 9.18.3
>> >> =
>> >> ps_mem 8456
>> >> Private  +   Shared  =  RAM used Program
>> >> 10.2 GiB + 162.0 KiB =  10.2 GiB named
>> >> 
>> >> Regards,
>> >> Raman
>> >> 
>> >> On Fri, Jun 24, 2022 at 10:06 AM Ondřej Surý  wrote:
>> >> 
>> >>> On 24. 6. 2022, at 

Re: High memory consumption in bind 9.18.2

2022-07-25 Thread Gregory Sloop
Top posting...
 
I'm no BIND guru, so I'm of no real help on the technical aspects of your query 
- but I'm puzzled by the direction this has gone.
 
>·   Bind compiled with openssl 1.0 and openssl 1.1 behavior was the same, 
>in 9.18.3 memory usage was high wrt 9.16.21.
 
The claim that BIND 9.18 is taking a lot more memory just seems incorrect. (And 
to keep talking about it that way seems kind of inflammatory too.)
 
Even by the data *you* gathered, you're only showing 10% more memory usage. 
While 10% isn't nothing, it's pretty small.
And the BIND team even humored you and did their own analysis and in their 
tests showed essentially negligible differences between the two versions.
(I'd argue that 10% is negligible too, unless one could show that multiple 
recent versions had 10% gains each.)
 
I think I'm mainly worried that we'll rob the dev team of time, looking at 
trivial memory differences for, at best, very little gain.
 
Do you really believe that continuing to expend time on this makes sense, 
especially in the "free as in beer" context?
 
  

> Thanks Ondřej
> We really appreciate your help in debugging this issue.

> Observations that we have shared are with 32M data of 15 characters and we 
> have configured jemalloc and bind using.
> Downloaded the jemalloc-5.3.0.tar.bz2 and configure using below command
> # ./configure --prefix=/usr
> Downloaded bind 9.18.3 from ISC website
> # ./configure --prefix=/opt/bind --sysconfdir=/etc/opt/bind --with-openssl=no 
> --disable-doh


> ·   Bind compiled with openssl 1.0 and openssl 1.1 behavior was the same, 
> in 9.18.3 memory usage was high wrt 9.16.21.Can you please guide us about 
> your configuration and compilation process after which you observed low 
> memory usage?

> If possible can you please share the named.conf files and the loading 
> mechanism followed.

> Regards,
> Raman


> On Thu, Jul 21, 2022 at 9:00 PM Ondřej Surý  wrote:

>> Hey,

>> I did a measurement with 1M small generated zones that we are
>> using internally for the performance testing and here are some numbers:

>> The measured values are USS/PSS/RSS using `smem -P named -k`

>> BIND 9.16 w/o jemalloc: 10.9G/10.9G/10.9G (default configuration)
>> BIND 9.16 with jemalloc: 10.1G/10.2G/10.2G [1]

>> BIND 9.18 w/o jemalloc: 10.7G/10.7G/10.7G (not recommended)
>> BIND 9.18 with jemalloc: 9.9G/9.9G/9.9G (default configuration)

>> BIND 9.19 w/o jemalloc: 10.5G/10.5G/10.6G
>> BIND 9.19 with jemalloc: 9.8G/9.8G/9.8G [2]

>> This is consistent with our other measurements that the memory
>> usage is slightly lower with 9.18 compared to 9.16.

>> As you hadn’t shared any other details, there’s not much we can
>> do here, so you are pretty much on your own. But I would say that
>> 1GB extra of memory in the context of loading 1M zones is not
>> worth too much effort.

>> 1. just preloading jemalloc saves some memory as compared to the default 
>> system allocator
>> 2. our expectations are to go even lower during the 9.19/9.20 development 
>> cycle, but no promises yet

>> Cheers,
>> --
>> Ondřej Surý (He/Him)
>> ond...@isc.org

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

>>> On 11. 7. 2022, at 6:25, Ondřej Surý  wrote:
>>> 
>>> Hi,
>>> 
>>> yes, I did. And I see no problem here. The software changes between the 
>>> versions and roughly 10% increase doesn’t seem like something that should 
>>> be worrying or worth any deep investigation. You simply cannot expect 
>>> “faster”, “better”, “contains new features” and *“same”* together.
>>> 
>>> Ondřej
>>> --
>>> 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 11. 7. 2022, at 6:09, Raman kumar  wrote:
 
 
 Hello,
 
 Did you get a chance to look into the data that I shared above? The 
 tools(ps_mem, pmap ) that you recommended to compare the RAM consumption 
 between 9.18.x and 9.16.x are also showing that memory consumption is more 
 in 9.18.x compared to 9.16.x.
 
 Thanks in advance.
 
 Regards,
 Raman
 
 
 
 
 On Fri, Jul 1, 2022 at 9:08 PM Raman kumar  
 wrote:
 Hello,
 
 In continuation to my previous mails, sharing memory usage by bind 9.16.21 
 and 9.18.3 using pmap and ps_mem tools.
 
 We have observed memory usage in 9.18.3 is higher by approximately 1.10 GB 
 with the same amount of data loaded on both bind versions.
 Attaching pmap output for both bind versions in this mail which also shows 
 memory used by heap/mmap on 9.18.3 is ~10.16GB whereas 9.16.21 was 
 consuming ~9.05GB
 
 9.16.21
 ==
 ps_mem 7543
 Private  +   Shared  =  RAM used Program
 9.1 GiB + 262.5 KiB =   9.1 GiB named
 
 9.18.3
 =
 ps_mem 8456
 Private  +   

Re: High memory consumption in bind 9.18.2

2022-07-25 Thread Raman kumar
Thanks Ondřej
We really appreciate your help in debugging this issue.

Observations that we have shared are with 32M data of 15 characters and we
have configured jemalloc and bind using.
Downloaded the jemalloc-5.3.0.tar.bz2 and configure using below command
# ./configure --prefix=/usr
Downloaded bind 9.18.3 from ISC website
# ./configure --prefix=/opt/bind --sysconfdir=/etc/opt/bind
--with-openssl=no --disable-doh

·   Bind compiled with openssl 1.0 and openssl 1.1 behavior was the
same, in 9.18.3 memory usage was high wrt 9.16.21.
Can you please guide us about your configuration and compilation process
after which you observed low memory usage?

If possible can you please share the named.conf files and the loading
mechanism followed.

Regards,
Raman

On Thu, Jul 21, 2022 at 9:00 PM Ondřej Surý  wrote:

> Hey,
>
> I did a measurement with 1M small generated zones that we are
> using internally for the performance testing and here are some numbers:
>
> The measured values are USS/PSS/RSS using `smem -P named -k`
>
> BIND 9.16 w/o jemalloc: 10.9G/10.9G/10.9G (default configuration)
> BIND 9.16 with jemalloc: 10.1G/10.2G/10.2G [1]
>
> BIND 9.18 w/o jemalloc: 10.7G/10.7G/10.7G (not recommended)
> BIND 9.18 with jemalloc: 9.9G/9.9G/9.9G (default configuration)
>
> BIND 9.19 w/o jemalloc: 10.5G/10.5G/10.6G
> BIND 9.19 with jemalloc: 9.8G/9.8G/9.8G [2]
>
> This is consistent with our other measurements that the memory
> usage is slightly lower with 9.18 compared to 9.16.
>
> As you hadn’t shared any other details, there’s not much we can
> do here, so you are pretty much on your own. But I would say that
> 1GB extra of memory in the context of loading 1M zones is not
> worth too much effort.
>
> 1. just preloading jemalloc saves some memory as compared to the default
> system allocator
> 2. our expectations are to go even lower during the 9.19/9.20 development
> cycle, but no promises yet
>
> Cheers,
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> > On 11. 7. 2022, at 6:25, Ondřej Surý  wrote:
> >
> > Hi,
> >
> > yes, I did. And I see no problem here. The software changes between the
> versions and roughly 10% increase doesn’t seem like something that should
> be worrying or worth any deep investigation. You simply cannot expect
> “faster”, “better”, “contains new features” and *“same”* together.
> >
> > Ondřej
> > --
> > 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 11. 7. 2022, at 6:09, Raman kumar  wrote:
> >>
> >> 
> >> Hello,
> >>
> >> Did you get a chance to look into the data that I shared above? The
> tools(ps_mem, pmap ) that you recommended to compare the RAM consumption
> between 9.18.x and 9.16.x are also showing that memory consumption is more
> in 9.18.x compared to 9.16.x.
> >>
> >> Thanks in advance.
> >>
> >> Regards,
> >> Raman
> >>
> >>
> >>
> >>
> >> On Fri, Jul 1, 2022 at 9:08 PM Raman kumar 
> wrote:
> >> Hello,
> >>
> >> In continuation to my previous mails, sharing memory usage by bind
> 9.16.21 and 9.18.3 using pmap and ps_mem tools.
> >>
> >> We have observed memory usage in 9.18.3 is higher by approximately 1.10
> GB with the same amount of data loaded on both bind versions.
> >> Attaching pmap output for both bind versions in this mail which also
> shows memory used by heap/mmap on 9.18.3 is ~10.16GB whereas 9.16.21 was
> consuming ~9.05GB
> >>
> >> 9.16.21
> >> ==
> >> ps_mem 7543
> >> Private  +   Shared  =  RAM used Program
> >> 9.1 GiB + 262.5 KiB =   9.1 GiB named
> >>
> >> 9.18.3
> >> =
> >> ps_mem 8456
> >> Private  +   Shared  =  RAM used Program
> >> 10.2 GiB + 162.0 KiB =  10.2 GiB named
> >>
> >> Regards,
> >> Raman
> >>
> >> On Fri, Jun 24, 2022 at 10:06 AM Ondřej Surý  wrote:
> >>
> >>> On 24. 6. 2022, at 5:28, Nagaraju Amarana 
> wrote:
> >>>
> >>> 
> >>> Hi Ondrej,
> >>>
> >>> As per the BIND stats usage is lower than the 9.16 however it is in
> the other way when compared with the system stats. Any idea on this
> difference?
> >>
> >> Hi,
> >>
> >> I already mentioned some below - memory fragmentation plays a role.
> Using jemalloc helps with that.
> >>
> >> Other factors are mentioned in the resources I’ve sent - have you read
> it? - shared libraries are also accounted in this space. Using the numbers
> from statm (or even ps/top) is only informative and makes sense only as
> hint - f.e. when memory leaks. Or comparing the exactly same builds with
> same libraries linked etc.
> >>
> >>> I think user need to consider the memory allocation based on the
> system usage otherwise OS may crash the process due to out of memory.
> >>
> >> No, not really. First of all, OOM killer makes sure it doesn’t crash
> the operating system, but kills a selected process to free up the memory.
> >>
> >>>