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