Public DNS (nsd4) is running and available over IPv4 but is not accessible over IPv6

[ariejan]

Since some time (unknown since which version) I have this error message in my status page:

Public DNS (nsd4) is running and available over IPv4 but is not accessible over IPv6 <ipv6>

Upon further investigation, the setup for DNS uses private IPs to generate /etc/nsd/nsd.conf:

https://github.com/mail-in-a-box/mailinabox/blob/master/setup/dns.sh#L48

When I run setup.sh I have one public ipv4 and both a public and a private ipv6. The status page checks for the DNS service on the public IPv6, while the configuration work with the private IPv6.

Either something is wrong with my IPv6 configuration or the public IP address should be used to run DNS.

Update: I'm a bit confused about the bind9 + nsd setup.

Bind9 is configured for IPv4 only on 127.0.0.1. setup/system.sh has the following comment:

# So we'll be running `bind9` bound to 127.0.0.1 for locally-issued DNS queries
# and `nsd` bound to the public ethernet interface for remote DNS queries asking
# about our domain names. `nsd` is configured later.

So, nsd should be listening on public interfaces, right? Here's a snippet from setup/dns.sh, which clearly uses private IPs:

# Since we have bind9 listening on localhost for locally-generated
# DNS queries that require a recursive nameserver, and the system
# might have other network interfaces for e.g. tunnelling, we have
# to be specific about the network interfaces that nsd binds to.
for ip in $PRIVATE_IP $PRIVATE_IPV6; do
        echo "  ip-address: $ip" >> /etc/nsd/nsd.conf;
done```

This is my setup:

Primary Hostname: mail.example.com Public IP Address: 149.xx.xx.xx Public IPv6 Address: 2a01:xxx:4960 Private IPv6 Address: 2a01:xxx:1b59 Mail-in-a-Box Version: v0.17b

and this is the resulting `/etc/nsd.conf`:

ip-address: 149.xx.xx.xx ip-address: 2a01:xxx:1b59

Notice that there is not private IPv4 address, so the public IPv4 is used.

[ariejan]

@JoshData do you have an opinion on this?

[JoshData]

The "private" IP address is an IP address assigned to a network interface. It's an IP address that services on the box can "bind" to. The address may or may not be a publicly accessible IP address.

The "public" IP address is how the box is known on the public Internet, and when that differs from the private IP address it's usually because of some upstream firewall hardware performing NAT. Services cannot "bind" to the public IP address because it's not an address the box even knows it has. But it's the address the box advertises as its IP address, e.g. in DNS.

[ariejan]

Ok, so in my case, my public IPs are (should be) the same as my private IPs. I'll investigate how/why two different IPv6 addresses are discovered. I'll update this post for posterity, leaving it open for now.

[JoshData]

... Also, IPv6 works in mysterious ways. Not all of the concepts of IPv4 translate well to IPv6. So.... Yeah. That's very new to me. Beware! :)

[biophonc]

Just a guess: Did you make sure that your nameserver (glue records) are pointing to the appropriate IPv6 address?

[Attempt3035]

Hi all, I am aware this problem was from quite a while ago, however I am experiencing what I believe is a similar problem. After wrestling with IPv6 blacklisted address pools, I have managed to get my own /64 pool assigned to my VPS (Using Linode if it helps). Following their guide I was able to add the address to the network configuration file successfully and setup mailinabox using that alternate IPv6 address. The way Linodes are set up, the chosen address from the pool is available alongside the original SLAAC address linked to the VPS. Mailinabox successfully allows me to set my "public" ipv6 to the new address and does indeed send emails from this address, however it reports the error Public DNS (nsd4) is running and available over IPv4 but is not accessible over IPv6 <ipv6>. I cannot reach the remotely DNS from the IPv6 address and I'm not sure how to solve the problem. Forcing mailinabox to use the new IPv6 for both the "public" AND "private" address does not seem to have any effect on the issue. I don't believe this issue is related to nameserver setup at the registrar as I should still be able to reach the DNS using the IPv6 address directly, even if my NS configuration was incorrect? Not sure what logs or other information might be needed for this, please ask for any logs etc!

[gwhitney]

I am now in precisely the same situation as the previous poster. If anyone helped resolve it in any way, please provide any helpful information; and of course I will do likewise. EDIT: It appears that one more reboot of the box resolved the problem. If that's not the case, I will edit again.

[Attempt3035]

Damn lucky, I never ended up resolving it. I had to turn off ipv6 altogether because it was trying to send on ipv6 even when it wasn't successfully working, hence other clients were blocking my mail cause they couldn't ping back to the address. Would be interested to get to the bottom of this. Are you able to confirm you can successfully send mail that shows (in the header) it came from your alternate ipv6 address you set up, not the slaac original one tied to the vps? mxtoolbox is good for checking these details btw.

[gwhitney]

I never ended up resolving it.

An exact list of what I did to get it working is at https://discourse.mailinabox.email/t/how-do-i-make-miab-use-my-new-ipv6-address/7095/10.

Are you able to confirm you can successfully send mail that shows (in the header) it came from your alternate ipv6 address you set up, not the slaac original one tied to the vps? mxtoolbox is good for checking these details btw.

I believe so, because I had a specific recipient to which my MiaB was sending mail by IPv6 that was constantly bouncing me until I did all of the above, and then as soon as I go through all the steps, the mail immediately started going through. I didn't see how to check the headers of outgoing IPv6 mail in mxtoolbox; if you can provide instructions I am happy to. Anyhow, if you want to set this up try the 5-step process I list in the answer linked above.