| SYSTEM INFORMATION | |
|---|---|
| OS type and version | Debian 12 |
| Webmin version | 2.105 |
| Virtualmin version | 7.9.0 |
| Related packages | BIND9, DNS |
When adding a new domain, executing:
systemctl restart networking.service
is required before the IPv6 is resolved properly externally.
That doesn’t make sense and no else has reported a issue like that. So your basically saying pinging your IPv6 address works before you add a new domain and can’t after.
There’s a reason I haven’t upgraded to Debian 12. 
I add a new domain with a new dedicated IPv6 (autoselected next from the pool). When I test, everyhting works, except the IPv6 address does not resolve. When I restart the network, it registeres the new IPv6 and than also the IPv6 resolves.
Note: the IPv4 for the new domain is on a shared IP address.
Does Webmin/Virtualmin already have these pool addresses registered so that it knows about them before the assignment is made?
Yes, under the “System Setting”, “Server Templates”, “Virtual IP addresses” in the section “Ranges for automatic IPv6 allocation”, I have “Starting address” ***:1:1 and “Ending Address” ***:1:ffff configured (with the netmask set to default and, of course, “Listed below” checked).
Note: for IPv4 I have only 1 shared IP address (but that still works out of the box when adding a new virtual server with a new domain name).
Complete guess here, but, if they aren’t in Webmin > Network Configuration > Host Addresses, then they aren’t ‘real’ yet?
Those IPv6 addresses have been automatically added (by Virtualmin, when adding a new domain) to the “Network Interfaces” (ens3:0) and those added are resolvable (after the manual restart). The server runs its own DNS. Should each IPv6 also be added the “Host Addresses” (manually, one by one - or can they be added as a block)?
I ran into this while testing (still not working) the PTR/rDNS for the scenario where I have 1 main/server domain “abc.net” (dedicated IPv4 and dedicated IPv6) and several project domains (shared IPv4, dedicated IPv6) like “bcd.com” and “dcb.com”. The dedicated IPv4 from abc.net and the shared IPv4 from the project domains all have a rDNS = abc.net set up. This causes a rDNS mismatch.
you wrote
I am curious, what tools or checking has reported this – what is the actual impact on you? In my experience, often having almost ANY value for a rDNS record is “good enough” 
SpamAssassin triggers on the “RDNS_NONE” error (tested via https://www.mail-tester.com/). And this is what I get back from Google when it is not set up correctly.
host gmail-smtp-in.l.google.com[142...] said: 550-5.7.25 [149...] The IP address sending this message does not have a 550-5.7.25 PTR record setup, or the corresponding forward DNS entry does not 550-5.7.25 point to the sending IP. As a policy, Gmail does not accept messages 550-5.7.25 from IPs with missing PTR records. For more information, go to 550-5.7.25 Email sender guidelines - Google Workspace Admin Help 550-5.7.25 To learn more about Gmail’s sender policy, go to 550 5.7.25 Email sender guidelines - Google Workspace Admin Help. v11-20020a1709061dcb0a3d3548si477525*.541 - gsmtp (in reply to end of DATA command)
Webmin > Network Configuration > Host Addresses only partially lists what is in the interfaces file. Here is my interfaces file:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo ens3 ens3:0 ens3:1 ens3:2
iface lo inet loopback
# The primary network interface
allow-hotplug ens3
iface ens3 inet static
address 9.*.*.6
netmask 255.255.255.0
network 9.*.*.0
gateway 9.*.*.1
# The dns-* options are implemented by the resolvconf.
# This is an autoconfigured IPv6 interface
iface ens3 inet6 static
pre-up /sbin/modprobe -q ipv6 ; /bin/true
address 2a:*:*:*:*:*:fe54:9c
netmask 48
gateway 2a0:*:*::1
# Example.com Shared IPv4
iface ens3:0 inet static
address 9.*.*.7
netmask 255.255.255.0
network 9.*.*.0
# ns1.Example.com IPv4
iface ens3:1 inet static
address 9.*.*.8
netmask 255.255.255.0
network 9.*.*.0
# ns1.Example.com IPv6
iface ens3:1 inet6 static
# Is this duplication needed (might not only the first iface need it)?
pre-up /sbin/modprobe -q ipv6 ; /bin/true
address 2a:*:*:b6::2
netmask 64
# ns2.Example.com IPv4
iface ens3:2 inet static
address 9.*.*.9
netmask 255.255.255.0
network 9.*.*.0
# ns2.Example.com IPv6
iface ens3:2 inet6 static
# Is this duplication needed (might not only the first iface need it)?
pre-up /sbin/modprobe -q ipv6 ; /bin/true
address 2a:*:*:b6::3
netmask 64
iface ens3:0 inet6 static
# Is this duplication needed (might not only the first iface need it)?
pre-up /sbin/modprobe -q ipv6 ; /bin/true
address 2a:*:*:*:*:ff:1:1
netmask 64
# Why is the below needed? Is that not already covered by the 1:1/64 above if rewritten to /48?
up ifconfig ens3:0 inet6 add 2a:*:*:*:*:ff:1:4/64
up ifconfig ens3:0 inet6 add 2a:*:*:*:*:ff:1:5/64
up ifconfig ens3:0 inet6 add 2a:*:*:*:*:ff:1:6/64
up ifconfig ens3:0 inet6 add 2a:*:*:*:*:ff:1:7/64
I cannot reproduce it on my Debian 12 system. I can see that the new network interface becomes available right after virtual server (domain) creation.
You should look deeper into Logs and Reports ⇾ Virtual Server Action Log, the very first entry after domain creation. On the inside check how the new IPv6 address is added exactly? Is it added using ip -6 addr add command or somehow else?
Oh, wow, I did not know that (the ability to see the executed commands) existed.
I see:
Adding IPv6 address 2a:*:*:*:*:ff:1:d ..
.. added to interface ens3:0
and twice this:
cp -p \/etc\/network\/interfaces \/etc\/network\/interfaces\~
and:
ip link set dev ens3 mtu 1500
but nothing similar to:
ip -6 addr add
and and systemctl related commands are not for the network.
Can you share all commands starting with ip (or other network related commands, which include newly added IPv6 address) that are shown in the action log?
A direct copy-n-paste:
Executed command
cp -p \/etc\/network\/interfaces \/etc\/network\/interfaces\~
Executed command
cp -p \/etc\/network\/interfaces \/etc\/network\/interfaces\~
Changed file /etc/network/interfaces
54a55
> up ifconfig ens3:0 inet6 add 2a:*:*:*:*:ff:1:d/64
Executed command
cd / ;
Executed command
ip link set dev ens3 mtu 1500
and when searching for “network”, the only other lines are outputs:
systemd-network:*:::::::
systemd-network:x:101:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-network:x:102:
and no other line matches the actual IPv6 address, other than the outputs of created/changed files like:
/etc/webmin/virtual-server/domains/*
/var/lib/bind/.com.hosts
/etc/bind/named.conf.local
/etc/apache2/sites-available/.com.conf (which gets created and later also changed)
The changes must be applied immediately when using the ip -6 addr add command, just as when using ifconfig, without requiring a restart of the network service.
Sorry, I’m not sure what is wrong on your side. It works for me either way, with ifconfig command and without. Perhaps @Jamie would have more insights…
As far as I can see, this line is only added (might not even be needed netmask already covers it) to the /etc/network/interface file, it is not made active (like by doing “systemctl restart networking.service”).
This does look like a bug! Is this a stock Debian 12 system?
Also, do you have the ifconfig or ip commands installed, or both?
I have tried it with a stock Debian 12. It didn’t have ifconfig installed by default. I later installed it for testing purposes. Although, interface was applied immediately either way.
Debian 12 via upgrade from a stock 11 (with VirtualMin already installed).
ifconfig: no
ip: yes