Should I be concerned? re: glue records

[Fezzy]

First - after upgrading to v60.1 on Ubuntu 22.04 all items are “green” on the “Status Checks” page. Yeah!

Here’s the line I have a question about, again all “green”:
“Nameserver glue records are correct at registrar. [ns1/ns2.box.XXXXXXX.org ↦ XX.XX.XX.XX]”

Note that there is no IPV6 listed. On my domain registrar, Hover.com, I have a glue record pointing to 1) the correct IPV4 server, noted in MIAB, and 2) a dedicated IPV6 address from an allocated block by Linode.

My publicly facing IPV6 address from Linode is an IPV6 SLAAC address different from the dedicated IP above. This is the IP that the MIAB upgrade process identified. Note I have also set the RDNS to this IPV6 address.

Do I need to focus on changing the glue record IPV6 address to the SLAAC address? Everything seems to be working fine, sending and receiving email, etc., and as I noted all checks are “green” on the status check page. I want to leave everything alone since it’s all working, but it bugs me to no end of what appears to be a misconfiguration. I will say I’m a novice with the gamut of IVP4 networking, and a complete ignoramus on IPV6.

Thanks for any feedback.

[andrew]

With IPv6, it’s normal to have multiple addresses for every machine. Perhaps MIAB picked up the wrong address. You could check and/or edit /etc/mailinthebox.conf for the desired IPv6 address and (if it was wrong) run sudo mailinthebox.

IPv6 is supported by all the bits that make up MIAB, but it’s not used by lots of MIAB operators, so support and testing seems more limited.

[Fezzy]

Thanks for the info. I think I’ll leave everything alone for now unless a problem pops up.

[andrew]

@Fezzy

“Nameserver glue records are correct at registrar. [ns1/ns2.box.XXXXXXX.org ↦ XX.XX.XX.XX]”

Hi - just reread your query. I think the message you’re seeing is perfectly normal for MIAB. My box seems to have IPv6 all set-up and I see the same message.

[tchangth]

It is my experience if my vps is assigned with an IPv6 address i need to assign AAAA record and reversed DNS before I switch over to MIAB. Failing to do so will incur the wrath from gmail:
host gmail-smtp-in.l.google.com[2404:6800:4003:c03::1a]
said: 550-5.7.25 [2402:1f00:8000:800::fa6] The IP address sending this
message does 550-5.7.25 not have a PTR record setup, or the corresponding
forward DNS entry 550-5.7.25 does not point to the sending IP. As a policy,
Gmail does not accept 550-5.7.25 messages from IPs with missing PTR
records. Please visit 550-5.7.25

[tchangth]

Related to the earlier post if i send a test email to check-auth@verifier.port25.com without proper ipv6 configuration at SPF (dns setting) i will get:

SPF check: softfail
“iprev” check: fail
DKIM check: pass

I had tried to disable ipv6 (at ovh.com) it does not work, as after a reboot ovh will reinstate ipv6 and ovh ipv6 rdns requires a correct AAAA record (before MIAB installation). in my opinion, if the hosting company provides ipv6 address, we don’t have a choice but to configure it properly.

[andrew]

You’ve actually got a couple of choices (or at least these worked for me on previous versions of MIAB):

• Run without IPv6. Disable IPv6 before you run the install. (E.g. execute sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1 and sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1.) MIAB will configure itself without reference to IPv6 addresses. When you next reboot, IPv6 will come back but as your mail config is IPv4 only, the IPv6 addresses are unused.

  As your install currently includes IPv6, you’ll have to remove/blank the references to IPv6 addresses in /etc/mailinthebox.conf, then disable IPv6, and then rerun sudo mailinthebox to refresh the install.

• Setup IPv6 email. This is a little more involved but it works for me. First find out your server’s static “external” IPv6 address. (Your box will acquire multiple IPv6 addresses, only one will be visible externally and unchanging - that’s the one to use. The external address will not start fd or fe.)

1. Arrange with your ISP/provider that IPv6 reverse DNS resolution is “delegated” to your box. This should be a simple matter of going to their website, ticking a box and providing the full name of your DNS server (eg. ns1.box.example.com)

2. Build yourself an IPv6 rDNS record. First use a tool like Reverse DNS Generator to convert your IPv6 into reverse format. The file lives in /etc/nsd/zones. My address is 2403:5806:96::20 and my reverse address looks like 0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.9.0.0.6.0.8.5.3.0.4.2.ip6.arpa. (Use a web tool to get all the zeros correct!)

   The rDNS record is just a text file should be named as your (reversed) subset. My subnet is 2403:5806:96 so my rDNS file is /etc/nsd/zones/6.9.0.0.6.0.8.5.3.0.4.2.ip6.arpa.txt. The contents of your file will differ in the address and dns name, but mine contains the following (the trailing dots on the DNS names are required):

;
; 2403:5806:96::/48
;
; Zone file built with the IPv6 Reverse DNS zone builder
; http://rdns6.com/
;
$TTL 1h ; Default TTL
@       IN      SOA     ns1.box.shh.one.        admin.box.shh.one. (
        2021101602      ; serial
        1h              ; slave refresh interval
        15m             ; slave retry interval
        1w              ; slave copy expire time
        1h              ; NXDOMAIN cache time
        )

;
; domain name servers
;
@       IN      NS      ns1.box.shh.one.


; IPv6 PTR entries
0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.9.0.0.6.0.8.5.3.0.4.2.ip6.arpa.    IN    PTR    box.shh.one.

3. Add a local zones config file so the DNS server knows to use the zone record from step 2. This file is called /etc/nsd/nsd.conf.d/local.conf. You will need to adjust the addresses, but my config file contains:

# local (non-managed) zone config

zone:
        name: 6.9.0.0.6.0.8.5.3.0.4.2.ip6.arpa
        zonefile: 6.9.0.0.6.0.8.5.3.0.4.2.ip6.arpa.txt

4. (At least) restart your DNS server (sudo systemctl restart nsd) - personally, I like reboot the server!

5. Go to your domain regsitrar and ensure that the IPv6 address of your ns1.box.example.com is listed in the glue records, and check that your DNSSEC records match that shown on the MIAB control panel. (Everything else is provided by MIAB.)

6. Give it a few minutes for luck, then check the MX, DNS and AAAA records. You should have 2 entries in the MX, an AAAA lookup should return your IPv6 address, and a reverse lookup on your IPv6 should return your box name. Personally, I use Network Tools: DNS,IP,Email but whatever you prefer.

[Fezzy]

@tchangth @andrew Thanks for the comments gents. I ran the @verifier.port25.com check and I am getting a “pass” on all tests.

Summary of Results

SPF check: pass
“iprev” check: pass
DKIM check: pass

Interestingly, there is no output for my IPV6 settings from the test. It correctly details my IPV4 address and DNS entry, but no mention of my IPV6 or DNS.

The reason I am focused on IPV6 because at one point I was receiving bounced emails from a European server (an entity where I was employed) that had a policy around properly configured IPV6 addresses. I didn’t do a lot of digging, so it could have been a server unique configuration, vs a European regulation.

My DNS A and AAAA records point to my server, but again, as per my original post, the glue record has a different IPV6 address.

Anyway, I’ll keep testing and it appears @andrew 's comment is the right one: it’s not uncommon to have multiple IPV6 entries per device. Seems to me that’s what I have because so far, I haven’t had any bounced emails because of an improperly configured IPV6 (that I know of…).

[tchangth]

Andrew, Thanks for your advice. I tried all of them netplan, sysctl, grub - they all have unexpected consequence - especially after i rebooted the vps. My point is if the hosting company provides an ipv6 address, it would be best like you rightly pointed out is to configure them correctly and not get block by microsoft and google. Most of the MIABers just want a good email server and get on with their llife which Josh has for years provides such a good solution for us to use.

[andrew]

Fezzy, MIAB hasn’t had a strong IPv6 focus, so some of the checks and diagnostics are weaker than for IPv4.

If your glue record has the wrong IPv6 address, just fix it at your registrar/provider. The glue record is the one thing that MIAB can’t control, so you’ll have to fix that manually. For a normal MIAB install, everything (DNS/mail/web/etc servers) lives on the one server, so your glue (which points to your DNS server) should have the addresses of your box.

For a quick test and verification, I personally use https://en.internet.nl/. It’s not perfect but gives a good idea. Just ignore the “error” that “[Mail server connection not or insufficiently secured (STARTTLS and DANE)” - it’s a valid warning but for receiving mail your probably want to accept those weaker keys. And similar if you check your web server - yes, MIAB doesn’t conform to all current recommendations but it has a fine setup for what it does.