Richy's Random Ramblings – Page 2 – Random ramblings and ravings of Richy B

DNSSec signed Google Apps/G Suite Email

November 2, 2022

I’ve been using Google Apps, aka Google Workspace aka Google Suite (or just G Suite) for a while now and it’s annoyed me that I was getting “marked down” on e-mail security testers such as Internet.nl and the UK Government’s National Cyber Security Centre (NCSC) Check Your Email Security Service because Gmail for Business (G Suite) didn’t support DNSSEC (Domain Name System Security Extensions) signed MX hosts.

However, I’ve managed to find Google’s DNS Sec settings which – combined with other setups on my main domains – mean I get 4 green ticks from the NCSC, 97% from Internet.nl (I’m let down by Google’s support of old TLS and Ciphers settings and no DANE TLSA records) and all green (apart from DANE) on Hardenize : so nice strong secure email!

Google normally suggest you use the following MX (Mail Exchanger) records in your DNS settings if you use G Suite:

Priority	Mail Server (MX Entry)
1	ASPMX.L.GOOGLE.COM
5	ALT1.ASPMX.L.GOOGLE.COM
5	ALT2.ASPMX.L.GOOGLE.COM
10	ALT3.ASPMX.L.GOOGLE.COM
10	ALT4.ASPMX.L.GOOGLE.COM

The normal suggest Google Suite Email Servers for Businesses

(The records can actually be in any order and the priority can be anything – but Google do recommend that aspmx.l.google.com is set as the “highest priority” which is actually 1)

However, after a bit of searching (using DuckDuckGo and not Google 😉 ), led me to a blog post by Nis Bornoe and Kura the following G Suite DNSSEC signed MX records:

Google’s DNSSEC Signed Mail Servers (MX Entry)
mx1.smtp.goog
mx2.smtp.goog
mx3.smtp.goog
mx4.smtp.goog

Google’s “hidden” DNS SEC Signed MX Records

These domains are hosted on Google owned Charleston Road Registry (CRR)’s .goog top level domain (not to be confused with their .google and .gle brand top-level domains: or the 98 other ones they applied for) and .goog domains can “only be registered to Google Inc and its affiliates” so you’ve got some confidence they are legitimate.

However, whilst myself and Nis and Kura do not seem to have had any problems using these IPv4 and IPv6 supported DNSSEC signed nameservers (and according to DNSlytics and WhoisXMLAPI there are over 930 domains currently using them), they are not officially supported or documented (from what we can find) and have been running since at least 2019 – so they should be reasonably safe to use.

The only “catch” may may be that, for some reason, they do NOT have a reverse DNS (Pointer aka PTR) record setup – which is actually only a problem if those mail servers are use for sending OUT email (not just receiving it) – however, many only testers do assume that your inbound and outbound mail servers are the same. I can confirm, via a test email, that outbound mail goes out via servers such as mail-wr1-f52.google.com which are correctly configured.

Techy: Removing an rate limit block from Exim

October 28, 2022

Leave a Comment

During testing/investigation of an issue, I had to send “bad emails” to my Exim based mail server which after a number of attempts blocked me using the rate limit that had been configured:

451-The server has reached its limit for processing requests from your host.
451 Please try again later.

I didn’t want to wait for over an hour for the block to clear so I had to find out how to clear the block manually. On the mail server, I found the Exim data files in /var/spool/exim/db and using the exim_dumpdb tool to view the “ratelimit” block list:

# exim_dumpdb /var/spool/exim/ ratelimit

and then limiting it to the sending IP address (which I had checked via /var/log/exim_rejectlog ):

# exim_dumpdb /var/spool/exim/ ratelimit | grep 2001:db8:9:a::
28-Oct-2022 16:50:01.247104 rate:      1.877 key: 1h/per_mail/2001:db8:9:a::
28-Oct-2022 16:50:14.986765 rate:      1.937 key: 1h/per_conn//2001:db8:9:a::

Okay, that’s confirmed the block – but now to remove it. To do this, I had to use the “practically no documentation and no ui” tool exim_fixdb :

exim_fixdb /var/spool/exim/ ratelimit

It then just showed a prompt “>” with no instructions. But if the “key” was provided:

# exim_fixdb /var/spool/exim/ ratelimit
Modifying Exim hints database /var/spool/exim//db/ratelimit
> 1h/per_mail/2001:db8:9:a::
28-Oct-2022 16:50:01
0 time stamp: 28-Oct-2022 16:50:01
1 fract. time: .247104
2 sender rate: 1.877

Pressing “d” then deleted that record (and I repeated it for the other entry). Once I had finished, I just used “q” to quit exim_fixdb.

Hope it helps!

Techy: Changing Python Shebang path from absolute to env

August 31, 2022

cPanel: Disabling cPanel Store Promotions

August 23, 2022

1 Comment

A few people have got a bit annoyed at the promotions/advertisements within their WHM webhosting control panel as developed by cPanel Inc (specifically, I saw the feature request “give server admins a way to turn off spam ads“).

Whilst cPanel partners (i.e. whoever your brought your cPanel licence from – usually your datacenter or web hosting provider) have the ability to toggle these cPanel Store Purchases from their cPanel Inc “manage2” interface, there is a way of disabling it yourself by “abusing” the internal testing code built into cPanel (specifically /usr/local/cpanel/Cpanel/Config/Sources.pm which is called by /usr/local/cpanel/Cpanel/Whostmgr/Store.pm which, in turn, is called by /usr/local/cpanel/Whostmgr/Store/Product/ImunifyAVPlus.pm ):

cPanel: Unable to upgrade from MySQL to MariaDB

August 22, 2022

Leave a Comment

Due to changes in the way MariaDB has setup their Centos yum repositories, cPanel (at the time of writing) is unable to access the necessary files to upgrade people from MySQL to MariaDB (as it needs to do it in stages and MariaDB 10.0 is no longer available).

Whilst the cPanel knowledgebase article entitled “Can’t upgrade from MySQL 5.6 to MariaDB” and cPanel have acknowledged it as an internal bug with the reference CPANEL-40434, they say there is “no workaround at this time”. This is incorrect!

As I posted on their forums in the “One of the configured repositories failed (MariaDB106)” thread (unfortunately my post – 14 hours on – is still pending moderation), there is a reasonably quick fix server administrators can do. Here’s the full text of the post “just in case”:

Since I’ve hit this problem on a new server migrating from MySQL to MariaDB (and my much earlier post about how to fix the general issue seems to have just expired rather than be approved), here’s what I did to fix it.

Platform: Centos v7.9 on x64 – migrating from MySQL 5.7 to MariaDB 10.6

If you do not have /etc/yum.repos.d/MariaDB102.repo , start an upgrade to MariaDB and let it die.

1. Copy /etc/yum.repos.d/MariaDB102.repo to /etc/yum.repos.d/MariaDB102-patch.repo
2. Modify /etc/yum.repos.d/MariaDB102-patch.repo to change the baseurl to https://archive.mariadb.org/mariadb-10.2/yum/centos7-amd64
3. Copy that file now as /etc/yum.repos.d/MariaDB103-patch.repo
4. Modify MariaDB103-patch.repo so “102” is changed to “103” throughout and the base URL has 10.3
5. Repeat steps 3 and 4 to go from “103/10.3” to “104/10.4” etc all the way up to 106/10.6
6. Do yum clean all;yum makecache
7. Go to the Database upgrade page (select “Ignore current upgrade” if necessary)
8. And upgrade!

Bit long winded and fiddly, but it worked for me(tm)