Press "Enter" to skip to content

Richy's Random Ramblings

DNSSec signed Google Apps/G Suite Email

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 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 (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!

Read more: DNSSec signed Google Apps/G Suite Email

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

PriorityMail Server (MX Entry)
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 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)
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 which are correctly configured.

Techy: Removing an rate limit block from Exim

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

I’m just working in some Python code, and quite a lot of it has the “shebang” line for the Python interpreter set as an absolute path (such as /usr/bin/python) which won’t work for me as I need the scripts to use whichever version of Python I have configured in my “environment”: and the ideal way to do this is to call is using /usr/bin/env python – so how do I change these…

cPanel: Disabling cPanel Store Promotions

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/ which is called by /usr/local/cpanel/Cpanel/Whostmgr/ which, in turn, is called by /usr/local/cpanel/Whostmgr/Store/Product/ ):

cPanel: Unable to upgrade from MySQL to MariaDB

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
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)