Re: High memory consumption in bind 9.18.2

2022-08-04 Thread Ondřej Surý
What Emmanuel said…

--
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 4. 8. 2022, at 19:15, Emmanuel Fusté  wrote:
> 
> Le 04/08/2022 à 17:48, Dmitri Pavlov a écrit
>> Therefore, a very small request. Would it be possible on your side to run 
>> the same experiment as with (BIND 9.16.32 / BIND 9.18.6 / BIND 9.19.4) one 
>> more time but with BIND 9.16.21 (or any other version in 9.16.x <25 range )?
>> 
>> 
> Why not the opposite ? Why do you insist to run obsolete/inferior patch level 
> version ? Who want to run something older than the latest patch release of 
> one maintained version and even more a more than ten patch level apart ?
> The memory consomption diff is not an argument as it is simply ridiculous vs 
> the used scenario.
> Reproduce the 9.16.32 scenario, and if it reproduce Ondřej result, the 
> conclusion will be evident : bugs in the older patch level as you clearly 
> reproduced the 9.18 usage which you could surely reproduce with the 9.19 
> series too.
> Do you really prefer to run buggy but less memory hungry version ?
> 
> I understand that you want to have answer to you questions. Simply do the 
> complete exercise and you will have answers. Don't ask people to do them for 
> you.
> 
> Emmanuel.
> 
> PS: there where a switch on the default runtime config switch to "big server" 
> mode sometimes during the 9.16 series if I recall correctly. It perhaps 
> explain the diff.
> -- 
> 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: ,Re: caching does not seem to be working for internal view

2022-08-04 Thread Paul Kosinski via bind-users
On Wed, 3 Aug 2022 15:10:39 -0400
Timothe Litt  wrote:

> Hmm.  Your resolv.conf says that it's written by NetworkManager.
> 
> What I suggested should have stopped it from updating resolv.conf.
> 
> See 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/manually-configuring-the-etc-resolv-conf-file_configuring-and-managing-networking
> 
> After restarting the service, did you edit (or replace) resolv.conf to 
> remove the AT address?
> 
> If not, stop here & edit the file.
> 
> If so, perhaps some other manager is editing the file without replacing 
> the comment.
> 
> Check to see if resolv.conf is a symlink - some managers (e.g. 
> systemd-resolved) will do that.  Not sure when/if it found its way to 
> centos (I don't run it), but if it's there, systemctl stop & disable 
> it.  It would be running on 127.0.0.53:53, but it usually points 
> resolv.conf to itself.
> 
> The other managers that I know of aren't in redhat distributions.
> 
> You may need to use auditing to identify what is writing the file.
> 
> Timothe Litt
> ACM Distinguished Engineer


"Helpful" software such as NetworkManager has a habit of getting in the way of 
figuring out what is wrong with systems, especially networked ones. Since none 
of the 8 computers on my home LAN are ever used in different locations, I don't 
use NetworkManager (etc.): I don't see why such add-ons are useful unless the 
computer is used on multiple networks. But distros install a lot of stuff in an 
attempt to "simplify" Linux for newbies. (Even Windows, which now may have more 
millions of experienced users than brand new users, acts as if no one has ever 
used a computer before.)

-- 
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: Stopping ddos

2022-08-04 Thread Ed Daniel

On 02/08/2022 22:04, Saleck wrote:

Dne úterý 2. srpna 2022 22:02:58 CEST, Robert Moskowitz napsal(a):

Recently I have been having problems with my server not responding to my
requests.  I thought it was all sorts of issues, but I finally looked at
the logs and:

Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 114.29.194.4#11205
(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
114.29.216.196#64956 (.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 64.68.114.141#39466
(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
209.197.198.45#13280 (.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
114.29.202.117#41955 (.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 62.109.204.22#4406
(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:49 onlo named[6155]: client @0xa9420720 64.68.104.9#38518
(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:50 onlo named[6155]: client @0xaa882dc8 114.29.202.117#9584
(.): view external: query (cache) './A/IN' denied

grep -c denied messages
45868

And that is just since Jul 31 3am.

This is fairly recent so I never looked into what I might do to protect
against this.  I am the master for my domain, so I do need to allow for
legitimate queries.

Any best practices on this?

I am running bind 9.11.4

thanks


You could think about adding fail2ban to your server with some custom rules.
Helped us in a similar situation.

Kind regards,
David




I'm also a longtime and happy Fail2Ban user, more infos here:
https://www.linode.com/docs/guides/using-fail2ban-to-secure-your-server-a-tutorial/
https://ixnfo.com/en/configuring-fail2ban-for-bind9.html

HTH,
Ed.
--
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-08-04 Thread Emmanuel Fusté

Le 04/08/2022 à 17:48, Dmitri Pavlov a écrit

Therefore, a very small request. Would it be possible on your side to run the same 
experiment as with (BIND 9.16.32 / BIND 9.18.6 / BIND 9.19.4) one more time but 
with BIND 9.16.21 (or any other version in 9.16.x <25 range )?


Why not the opposite ? Why do you insist to run obsolete/inferior patch 
level version ? Who want to run something older than the latest patch 
release of one maintained version and even more a more than ten patch 
level apart ?
The memory consomption diff is not an argument as it is simply 
ridiculous vs the used scenario.
Reproduce the 9.16.32 scenario, and if it reproduce Ondřej result, the 
conclusion will be evident : bugs in the older patch level as you 
clearly reproduced the 9.18 usage which you could surely reproduce with 
the 9.19 series too.

Do you really prefer to run buggy but less memory hungry version ?

I understand that you want to have answer to you questions. Simply do 
the complete exercise and you will have answers. Don't ask people to do 
them for you.


Emmanuel.

PS: there where a switch on the default runtime config switch to "big 
server" mode sometimes during the 9.16 series if I recall correctly. It 
perhaps explain the diff.

--
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-08-04 Thread Dmitri Pavlov
Hi Ondřej,

Sorry to bother you one more time regarding the same topic.
I have looked through your shared logs one more time. This is what you have 
shared

YOUR LAB RESULTS ARE:
BIND 9.16.32 / BIND 9.18.6 / BIND 9.19.4
RSS:30454872 / RSS:29451056 / RSS:29066580

OUR LAB RESULTS ARE:
BIND 9.16.21 / BIND 9.18.5
RSS:27406208 / RSS:29416180

Therefore, the results 9.18.6: RSS 29451056 (your lab) vs 9.18.5: RSS 29416180 
(our lab) are very close.
However the KB https://kb.isc.org/docs/bind-memory-consumption-explained -> 
BIND Memory Consumption Explained, it is about "increased memory consumption in 
BIND 9.16 up to and including 9.16.24" vs 9.18.x.
As you see the results provided by you from 9.16.32, they neither prove nor 
disapprove what the article describes.

Therefore, a very small request. Would it be possible on your side to run the 
same experiment as with (BIND 9.16.32 / BIND 9.18.6 / BIND 9.19.4) one more 
time but with BIND 9.16.21 (or any other version in 9.16.x <25 range )?

Thank you very much in advance,
Kind regards,
Dmitri.





-Original Message-
From: Ondřej Surý 
Sent: Tuesday, August 2, 2022 6:30 PM
To: Dmitri Pavlov 
Cc: bind-users@lists.isc.org
Subject: Re: High memory consumption in bind 9.18.2

Well, then I don’t know the reason for the difference in your case. And I don’t 
personally see a compelling reason to investigate a 10% increase in artificial 
scenario like this since it apparently doesn’t apply to all scenarios. However, 
you are free to do the further investigation yourself.

We are refactoring the database for storing the resource records in 9.20 and 
it's probably better spent time to work on the refactoring than look at this. 
As usual, we would accept any well commented and well thought patches.

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 2. 8. 2022, at 17:23, Dmitri Pavlov  wrote:
>
> Hi,
>
> Resending ... bad format.
>
> dnf install wget bzip2 gcc make -y
> wget
> https://github.com/jemalloc/jemalloc/releases/download/5.3.0/jemalloc-
> 5.3.0.tar.bz2
> bzip2 -d jemalloc-5.3.0.tar.bz2 && tar -xf jemalloc-5.3.0.tar && cd
> jemalloc-5.3.0 ./configure make make install reboot -f
>
> Dmitri.
>
>
>
> -Original Message-
> From: Dmitri Pavlov
> Sent: Tuesday, August 2, 2022 6:14 PM
> To: Ondřej Surý 
> Cc: bind-users@lists.isc.org
> Subject: RE: High memory consumption in bind 9.18.2
>
> Hi,
>
> Thank you very much for your feedback, Ondrej.
>
> Sharing the steps. Very simple: configure -> make -> make install. Very 
> simple configuration. Just the zone file is big.  Please, see the attached.
>
> 1. I followed the instructions from here
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbind
> 9.readthedocs.io%2Fen%2Fv9_18_4%2Fchapter10.htmldata=05%7C01%7Cdp
> avlov%40perforce.com%7Cbefcaa04b0ed465b614908da749be1b0%7C95b666d19a75
> 49ab95a38969fbcdc08c%7C0%7C0%7C637950510129140945%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7Csdata=fY1tDUrmD8F7a2dmMCxKjzoibMjq6oKQr7%2FBF7tvi
> 6E%3Dreserved=0
> No git.
>
> 2. Rocky 9
> uname -a
> Linux server.test.zone 5.14.0-70.17.1.el9_0.x86_64 #1 SMP PREEMPT Wed
> Jul 13 18:23:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Package
> gcc-11.2.1-9.4.el9.x86_64
>
> 9.18.5
> = OUTPUT =
> pmap -x 27821 | tail -n 1
> total kB 34853832 29425312 29416180
>
> smemstat -p named
>PID  Swap   USS   PSS   RSS User   Command
>  27821 0.0 B28.1 G28.1 G28.1 G root   
> /usr/local/sbin/named
> Total:  0.0 B28.1 G28.1 G28.1
> = = =
>
> 9.16.21
> = OUTPUT =
> pmap -x 18026 | tail -n 1
> total kB 28161152 27414164 27406208
>
> smemstat -p named
>PID  Swap   USS   PSS   RSS User   Command
>  18026 0.0 B26.1 G26.1 G26.1 G root   
> /usr/local/sbin/named
> Total:  0.0 B26.1 G26.1 G26.1 G
> = = =
>
> 2 GB diff is still there.
>
> Steps have been attached.
>
> Will be very grateful,  could you please, have a look at the steps provided? 
> They are quite straightforward and self-explanatory. What is that "magic 
> souse" I should apply, when there is Rocky 9 or RHEL 9 machine in front of 
> me.  I believe if I replicate your setup/steps, most likely I'll get the same 
> output. However, if looking at the articles available to the wide audience 
> (like this 
> 

Re: Stopping ddos

2022-08-04 Thread Lyle Giese

Just my opinion.

Don't rate limit tcp.  The RRL feature in Bind only rate limits UDP.  
UDP is connection-less and the source address can be forged, generating 
DDOS traffic to a 3rd party.


Proper DNS software will fall back to TCP.  Because TCP is connection 
based, much harder to forge source address.


Lyle

On 8/3/22 08:30, Robert Moskowitz wrote:

Thanks.  I will look into this.

On 8/3/22 07:47, Victor Johansson via bind-users wrote:


Hey,

I just want to add that there is a better way to do this in iptables 
with hashlimit. The normal rate limit in iptables is too crude.


Below is an example from the rate-limit-chain, to which you simply 
send all port 53 traffic from the INPUT chain (make sure to exclude 
127.0.0.1/127.0.0.53 though :) ).



-A INPUT -p udp -m udp --dport 53 -j DNS-RATE-LIMIT
-A INPUT -p tcp -m tcp --dport 53 -j DNS-RATE-LIMIT

-A DNS-RATE-LIMIT -s 127.0.0.1/32 -m comment --comment "Dont 
rate-limit localhost" -j RETURN
-A DNS-RATE-LIMIT -m hashlimit --hashlimit-upto 100/sec 
--hashlimit-burst 300 --hashlimit-mode srcip --hashlimit-name 
DNS-drop --hashlimit-htable-expire 2000 -j ALLOW

-A DNS-RATE-LIMIT -m limit --limit 1/sec -j LOG --log-prefix "DNS-drop: "
-A DNS-RATE-LIMIT -m comment --comment "ansible[dns rate limiting]" 
-j DROP



//Victor


On 8/2/22 23:16, Michael De Roover wrote:
For my servers I'm using iptables rules to achieve ratelimiting. 
They look as follows:
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent 
--update --seconds 600 --hitcount 4 --name DEFAULT --mask 
255.255.255.255 --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent 
--set --name DEFAULT --mask 255.255.255.255 --rsource


It should be fairly trivial to convert these to use UDP 53, and 
tweak the timings you want. These rules are intended to allow 4 
connections (which normally should be entire SMTP transactions) 
every 10 minutes. Since I have 2 edge nodes with these rules, that 
is doubled to 8 connections total. If you're an authoritative name 
server only, realistically mostly recursors / caching servers would 
query your servers and not too often. You can easily restrict 
traffic here. If you're a recursor too, this becomes a bit more 
complicated.


Regarding the legitimate queries, it would be prudent to allow 
common recursors (Google, Cloudflare, Quad9 etc) to have exceptions 
to this rule. Just allow their IP addresses to send traffic either 
unrestricted, or using a more relaxed version of the above.


HTH,
Michael

On Tue, 2022-08-02 at 16:02 -0400, Robert Moskowitz wrote:
Recently I have been having problems with my server not responding 
to my
requests.  I thought it was all sorts of issues, but I finally 
looked at

the logs and:

Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
114.29.194.4#11205

(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
114.29.216.196#64956 (.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
64.68.114.141#39466

(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
209.197.198.45#13280 (.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
114.29.202.117#41955 (.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
62.109.204.22#4406

(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:49 onlo named[6155]: client @0xa9420720 64.68.104.9#38518
(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:50 onlo named[6155]: client @0xaa882dc8 
114.29.202.117#9584

(.): view external: query (cache) './A/IN' denied

grep -c denied messages
45868

And that is just since Jul 31 3am.

This is fairly recent so I never looked into what I might do to 
protect
against this.  I am the master for my domain, so I do need to allow 
for

legitimate queries.

Any best practices on this?

I am running bind 9.11.4

thanks







-- 
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: DNSSEC signing of an internal zone gains nothing (unless??)

2022-08-04 Thread Petr Špaček

On 01. 08. 22 18:15, John W. Blue via bind-users wrote:
As some enterprise networks begin to engineer towards the concepts of 
ZeroTrust, one item caught me unaware:  PM’s asking for the DNSSEC 
signing of an internal zone.


Granted, it has long been considered unwise by DNS pro’s with a commonly 
stated reason that it increasing the size of the zone yadda, yadda, yadda.


While that extra overhead is true, it is more accurate to say that if 
internal clients are talking directly to an authoritative server the AD 
flag will not be set.  You will only get the AA flag.  So there is 
nothing to be gained from signing an internal zone.


However, I have not tested it yet, I would assume that if a 
non-authoritative internal server was queried it would be able to walk 
the chain of trust and return AD.


Thoughts?


I think it's worth reading
https://datatracker.ietf.org/doc/html/draft-krishnaswamy-dnsop-dnssec-split-view

Keep in mind it is 15 years old, but it will give you an idea about 
various points of view.


--
Petr Špaček
--
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