Re: Mailing list questions (DMARC, ARC, more?)
Hi Dan, On Sat 24/Sep/2022 01:10:12 +0200 Dan Mahoney wrote: On Aug 23, 2022, at 07:39, G.W. Haywood via bind-users wrote: On Tue, 23 Aug 2022, Alessandro Vesely wrote: I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? We check the ARC seal and I would be alerted to a failure. That's all. Are there other advantages that ARC brings about? It's a comfort to know that it's all working as designed, but I can't get excited about munged addresses. Otherwise, RFC9057 introduced the Author: header field. Using it to save the original From: would allow trusting receivers to de-munge the message at a later stage. I'm happy to use cut'n'paste for replies, but I can offer to help you with your testing. The milters here can do more or less anything. :) Hey there GW (and others). [...] * We're trying not to deal with the blowback that would occur if we *just decided to* one day start munging everyone's mail addresses. Lots of people would start posting about not-bind-things. Like this :) I apologize again for wasting bandwidth on non-DNS issues. While munging everyone would look more coherent, I propose to stop munging everyone, at least as an option for those recipient who accept broken DMARC. * Mailman 2.x (which we run) has some sender-munging features that have been necessary in the past to ensure delivery, but they haven't been the only problem. We're presently only doing those on domains with p=reject (or p=quarantine, which is rare). ARC was designed to avoid this. [...] DKIM Validation/Arc Sealing: * Everything gets validated at our MXes. However, the list doesn't seem to apply DMARC policies on entry. It would have to be, because only the MX has access to the IP address info required to check SPF. That's the right way to do it. Let me quote Mailman developers about doing ARC sealing: 1. It's a bad idea to do it in Mailman. 2. It was implemented in Mailman 3 three or four years ago as a proof of concept during the development of ARC. 3. There is a milter available for Postfix and Sendmail from the Trusted Domain Project https://github.com/trusteddomainproject/OpenARC as is the basic implementation which I presume is adaptable to Exim, qmail, and other MTAs. This is the preferred approach, as matter of conformance because it should be implemented by the edge MTA(s), and as a practical matter because Mailman *can't* do SPF since it is never an edge MTA. There is also a pure Python implementation on PyPI, I believe (this is the basis for the Mailman 3 plugin, or maybe it was dkimpy). https://mail.python.org/archives/list/mailman-develop...@python.org/message/RLSANJHTFTYQPAQQIBAOK3VDM3U4E5EU/ [...] ARC on lists: * The logic I applied is: What if a message comes in from sender X, is modified through listserv Y, and is sent out to subscribers Z[n]. We want to assert that we received the message with headers A, B, and C, and validated them, and even if they'd been re-written (as often happens on mailing lists) that they were valid at each point in the step. Thus, yes, you need two arc-seals, one in each point where there's a handoff and potential message modification. Can internal handoff modify the message? (Except Mailman, I mean.) [...] To the best of my knowledge, we're the only folks doing this -- mailman 3 is supposed to implement its own arc-sealing, but 2.x won't ever. Mailman 2.x is largely EOL (but receiving security fixes -- XKCD 2347 applies) but there's movements to port it to work on a more modern python. As pointed out above, ARC should not be done by Mailman in any case. For the record, dnswl-users also do ARC sealing. In 2016 they stopped modifying messages, and hence they don't do From: munging. If people want to ask me questions directly, I'm here. And on mailop. What I want to ask is to experiment sending messages without From: munging. That would entail setting up a twin mailing list, configured to not do From: munging. Users would subscribe to the latter if their MX accepts broken DMARC, possibly because of ARC, or some other authentication, or even no authentication check at all; presumably users who can get their hands on their MTA, not Gmail accounts. The idea is outlined as the first one of three methods to get rid of From: munging, here: https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform Best Ale -- -- 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
Bind 9.16.28 upgrade: high memory utiization and OOM
Hi team, We had recently upgraded our bind nameservers from 9.14.10 to 9.16.28. This led to the hosts gradually using up a lot of memory and eventually named was OOM killed as it consumed nearly 7GB out of total 8GB server memory. (This package was built from source for centos 7) I’ve been looking into this and tested the performance of both 9.14 and 9.16 under the traffic of 600 queries per sec for 12 hours, which is the average qps our servers get. It was found that while 9.14 had a surge of around 2GB, 9.16 had a surge of 5.2GB during this time. I wanted to know whether this difference in memory consumption is expected while migrating from 9.14.10 to 9.16.28, or if this could be a memory leak that would keep building over time; it would really help if I can get some insights on what might be causing this, or if there’s any way to avoid this other ram bumping up the RAM. Also I noticed some CVE related to this bind version recently, if anything to do with that ? 1. A memory leak was fixed that could be externally triggered in the DNSSEC verification code for the ECDSA algorithm. (CVE-2022-38177) 2. Memory leaks were fixed that could be externally triggered in the DNSSEC verification code for the EdDSA algorithm. (CVE-2022-38178) I’d be glad to provide more info if needed. Would really appreciate your inputs and suggestions on this. -- Regards, Prasanna. -- 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 9.16.28 upgrade: high memory utiization and OOM
Hi Prasanna, first of all, I would recommend you to conduct all the testing using the latest 9.16.33 release. There is a difference in a memory usage between the versions, but you are not the first person to report the increased memory usage during the resolver operation. We've been unable to reproduce the issue locally. However, you didn't send any details about the configuration, libraries used, operating system, etc. I would suggest that you create a new issue in our gitlab instance, so we can track the information there: https://gitlab.isc.org/isc-projects/bind9/-/issues/new Please summarize your findings, but also attach all relevant data: configuration used, compile time options used, how do you start named, etc.] You should also gather the memory statistics from the named (XML or JSON) at datapoints, so we can look into differences. For detailed memory debugging, I would recommend installing the latest jemalloc version and compiling BIND 9 with it (or `LD_LIBRARY_PRELOAD` it) and setup the heap profiling: https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling I would either use lg_prof_interval for periodic dumps. All the data points should be collected in the newly created GitLab issue. Thanks, Ondrej -- 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 27. 9. 2022, at 16:09, Prasanna Mathivanan (pmathiva) via bind-users > wrote: > > Hi team, > > We had recently upgraded our bind nameservers from 9.14.10 to 9.16.28. This > led to the hosts gradually using up a lot of memory and eventually named was > OOM killed as it consumed nearly 7GB out of total 8GB server memory. (This > package was built from source for centos 7) > > I’ve been looking into this and tested the performance of both 9.14 and 9.16 > under the traffic of 600 queries per sec for 12 hours, which is the average > qps our servers get. It was found that while 9.14 had a surge of around 2GB, > 9.16 had a surge of 5.2GB during this time. I wanted to know whether this > difference in memory consumption is expected while migrating from 9.14.10 to > 9.16.28, or if this could be a memory leak that would keep building over > time; it would really help if I can get some insights on what might be > causing this, or if there’s any way to avoid this other ram bumping up the > RAM. > > Also I noticed some CVE related to this bind version recently, if anything to > do with that ? > > • A memory leak was fixed that could be externally triggered in the > DNSSEC verification code for the ECDSA algorithm. (CVE-2022-38177) > • Memory leaks were fixed that could be externally triggered in the > DNSSEC verification code for the EdDSA algorithm. (CVE-2022-38178) > > I’d be glad to provide more info if needed. Would really appreciate your > inputs and suggestions on this. > -- > Regards, > Prasanna. > -- > 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
