SoylentNews is people
SoylentNews
NCommander is publishing a Meta story today: https://soylentnews.org/article.pl?sid=22/11/20/0342250 It will be published on the front page with all of the restrictions that apply to such stories and discussions.
In it NCommander explains how he sees the future of the site developing with regards to software, hardware and administration. Some of those views are different now from the views that many of us held in 2014. The requirement for some of our servers is no longer justified, and there are better technologies available for achieving what we are trying to do thus also reducing our running costs. The administration of the site is placing an increasing burden on the relatively few administrators that remain in the support team. Society has also changed. Some discussion has been replaced by intimidation and threats. It is much more polarised than it was in 2014. In many ways this is the same as for numerous other web sites. However, the abuse and toxic atmosphere created by a small number of Anonymous Cowards is unacceptable and must be reversed if the site is to survive. The responsibility for some of the problems that we are experiencing, and the resulting actions that we have had to take, is placed entirely at their feet.
A few months ago the majority of the community opted - albeit very reluctantly - to remove AC posts from the front pages of the site. This action has successfully removed the vast majority of the abuse from our discussions. We are seeing a slow increase in the number of comments week-on-week and the signal-to-noise ratio is now much higher. It is only right that we also reconsider the implications of that change.
This journal entry is to enable anyone who wishes to remain anonymous to express their views. I promise that I will read it and will ensure that genuine views are considered when the community decides which path it wishes to follow. I cannot make any assurances that other members of the site's administration will read it - although I expect that at least some will. If you have an account then I strongly encourage you to leave your views under NCommander's Meta story and not here.
I further my promise that I will try to represent your views as honestly and fairly as I can.
If you abuse this journal then you are simply giving more support to the alternative options that might be considered than you are to the status quo. I encourage you to expresses sensible, logical and considered views but should you decide that abuse is what you prefer then this journal entry can simply be removed. You are being given an opportunity - do not throw it away.
(Score: 2) by fab23 on Monday November 21 2022, @04:35PM (2 children)
What I can see from outside, the mail server is running, it sure may have some missing parts yet, as it was rebuilt from scratch. It has a proper hostname with corresponding PTR, A, AAAA and MX DNS entries even with DNSSEC enabled. Also a SPF TXT record is present. And it has a (still valid) certificate from Let's Encrypt.
Unfortunately its IPv4 address is listed in some DNS Block Lists, I will send details to the team.
I do not know all the details on how they are currently renewing the LE certificate. I only know that they have a wildcard certificate and so need to do this through DNS challenge and are doing it kind of manually.
For my personal infrastructure I already have it fully automated. But it took a quite long time to improve it and fix little things, mostly in the process afterwards to distribute the certificates to all needed systems and services. I have created an acme.example.com subdomain where my ACME tool (go-acme/lego) is able to create the temporary entries for the challenge. All domains, for which I am responsible to create certificates, have a _acme-challenge CNAME entry in their domain (e.g. in example.net) pointing to a corresponding example-net.acme.example.com name. The acme.example.com subdomain is only on one server (in my case the same where lego is running), so there is no delay with the distribution to all other name servers.
Regarding DANE (IN TLSA DNS entries) it is not so easy any more since using certificates from LE, as they have to be renewed quite often. I did had DANE entries in the past when still using certificates from commercial CA with validity of 1 year and even longer. To add / modify the multiple TLSA entries you already need to have the signed certificate to create the needed checksum/hash. Then you need to add the new entries and still keep the old ones. Then you need to wait until all the TTLs for the TLSA entries have expired and then you can deploy the new certificate to all services and reload/restart them. After that you can remove the TLSA entries for the old certificate.
I was already thinking about this, but to automate it, it is a major undertaking and currently probably not worth the effort as almost no software checks for this entries.
(Score: 2) by fab23 on Monday November 21 2022, @08:36PM
This was a false alarm and the IPv4 address of mail.soylentnews.org is clean and not listed in any DNB BLs checked. This affected BLs are offline since a few years, but my check when run in shell did report them, but when used through Nagios it did not report any failure. So in the end it helped me to also improve my own infrastructure as I did found an updated version of this check.
(Score: 0) by Anonymous Coward on Tuesday November 22 2022, @12:17AM
It is possible for this site to fully automate their usage of LE, which is what the TSIG is for. Because SN is using BIND, you can use TSIG to alter the _acme-challenge DNS entries in a secure manner without affecting anything else in the zone.
As a bonus, it also allows you to create the TLSA entries for the new certs and delete the old ones, again in a secure manner without affecting anything else on the zone. Your deployment script can handle all of that for you, and there are a couple of examples out there (I think ARIN or USCERT have one) and I know people who do so at scale already using such a script. The basic process is to start certbot. It can use its TSIG mode to create the proper challenge entries and get the wildcard certificate. Your deployment script generates the hash for whatever TLSA entry you chose. You use TSIG to add the new TLSA record. You wait 2.5 times your DNS value (which would be 2.5 hours according to the current SOA but you could do 2 days for safety). Then you add the new certificates and keys to nginx and remove the old ones. Then you reload nginx, being sure to wait for the reloads to actually complete. Then you can safely delete the old TLSA record using TSIG because you can be assured no one is relying on it.