Zone Replication IP Address Ignores Configuration Settings

[sproggit]

### Summary
When set up in a configuration that includes multiple Name Servers for a given Zone [Domain], Technitium DNS Version 14.3 employs AXFR/IXFR transfers to replicate zone data between name servers.

However, the transfers themselves do not seem to respect or follow local [host] network configuration settings when installed on a multi-homed server. As a result this may introduce complexity to configurations for other network infrastructure and to issue triage and management for any service involving the host.

Important Note To the best of my abilities to test this, I've been able to get synchronisation to work, even though it seems to be using the primary address for the Secondary Host, rather than the virtual address I set up to be dedicated to Technitium DNS. In order to do this, I just had to make a minor change on the Primary, specifically in the Zone [Zone Name] Zone Options >> Zone Transfer tab, I had to select "Use Specified Network Access Control List (ACL) as the Zone Transfer type, then make sure that I had the Primary IP address of the Secondary server in the "Network Access Control List (ACL)" text box...

### Vulnerable Environment
The "Steps to Reproduce" section, below, has been tested [and re-tested] using a pair of Raspberry Pi 4B hosts, each running a fully-patched version of Raspberry Pi OS 13, "Trixie". Each machine has been created as a "clean build" host, i.e. installation, basic configuration and patching of the host OS with no other software installed [apart from tools used during installation [e.g. gparted]. No other application, software, or services have been applied prior to testing.

To be a bit more explicit, I have a pair of Raspberry Pi machines, with the following setup:-

Host 1: [Primary DNS]
Primary IP: 172.16.103.21
Technitium Virtual IP: 172.16.103.211

Host 2: [Secondary DNS]
Primary IP: 172.16.103.24
Technitium Virtual IP: 172.16.103.241

### Desired Deployment / Use Case
In case it helps for context... I currently have a small collection of Raspberry Pi machines running a variety of local services supporting a home lab and family network, including a pair of Pi3B+ machines, each running effectively stand-alone versions of PiHole. However, I want to experiment with hosting a local mail server, which requires MX and TXT records, hence the switch to Technitium. To retain resiliency, I want to keep two hosts, but at the same time move from Pi3B + machines to 8Gb Pi4B machines and co-host Technitium DNS along with other apps and services [NextCloud, WordPress, Bookstack, Home Assistant, etc. I do this by using IP-based segregation of apps and services and setting up each Pi with multiple IP Addresses, such that each service on the network has a dedicated IP address to support it, which makes troubleshooting much [much] simpler.

** ### Steps to Reproduce **

1. Set up two hosts to serve as the operational platforms for the Primary and Secondary servers of a DNS Domain hosted by Technitium DNS.
2. Add a "Virtual IP Address" to each host such that it adopts a "multi-homed" configuration. [ For example, when deploying to a pair of Raspberry Pi hosts running Raspberry Pi OS 13, Trixie", use "sudo nmtui" to access the Network Manager Text User Interface. Select "Edit", go to the existing, default connection. Change the IPv4 settings from "Automatic" to "Manual" if required, then "Add" a second IP address to the host. Repeat for each server.
3. Perform a conventional installation of Technitium DNS for both Primary and Secondary servers in a Zone.
4. On each host, use the Web Admin panels [Settings >> General >> "DNS Server Local End Points" ] to explicitly set the added Virtual IP Address to be the listener for the DNS service on the host.
5. Evidence Create LICENSE #1 - Open a command prompt on the host in question and issue either the following command, or a functional equivalent if not performing validation on a Raspberry Pi:-

$ sudo netstat -tulpn | grep :53
tcp 0 0 172.16.103.211:53 0.0.0.0:* LISTEN 643/dotnet
tcp6 0 0 :::53 :::* LISTEN 643/dotnet
udp 0 0 172.16.103.211:53 0.0.0.0:* 643/dotnet
udp6 0 0 :::53 :::* 643/dotnet

[The above example output has been edited to remove two rows of returned detail that were related to the AVAHI daemon, listening on port 5353].

6. Complete the activation of synchronization and confirm effectiveness by checking the value of the "Status" column in the "Zones" view of the Admin web screens.
7. Open or switch to a browser tab/window connected to the Secondary DNS Server's Web Admin panels and select Zones
8. Navigate to and select the Zone used for issue reproduction
9. Select the "Resync" function by clicking the button displayed near the top of display
10. Open or switch to a browser tab/window connected to the Primary DNS Server's Web Admin panels and select "Logs"
11. Click on the most recent log [these are listed in reverse date order; it should be the log at the top of the list]
12. Open the log and scroll to the bottom
13. Look for a timestamped log entry that includes the text "DNS Server received zone transfer request for zone:"
14. Examine the record and note that the Source IP Address of the requesting secondary server [which can be found in a field between the record's timestamp [1st field] and the "[TCP] DNS Server received zone transfer" text [3rd field], the second field, enclosed in square brackets, contains the PRIMARY IP Address of the Secondary Server, NOT the secondary address defined in the Secondary Server's "Settings" >> "General" Admin/Configuration values.

### Partial Log Extract
[2026-02-23 12:07:16 UTC] DNS Server auth config file was saved: /etc/dns/auth.config
[2026-02-23 13:01:43 UTC] [172.16.103.24:44230] [TCP] DNS Server received zone transfer request for zone: saurian.net
[2026-02-23 13:01:48 UTC] [172.16.104.1:33286] Check for update was done {updateAvailable: False; updateVersion: 14.3; updateTitle: New Update (14.3) Available!; updateMessage: Follow the instructions from the link below to update the DNS server to the latest version. Read the change logs before installing this update to know if there are any breaking changes.; instructionsLink: https://blog.technitium.com/2017/11/running-dns-server-on-ubuntu-linux.html; changeLogLink: https://github.com/TechnitiumSoftware/DnsServer/blob/master/CHANGELOG.md;}

### Expected Behaviour
I would like/expect Technitium DNS to use the nominated IP Address [in this example, 172.16.103.241] for AXFR/IXFR transfer requests, since this is the address nominated for the service via the General Settings tab...

What seems to be happening with my setup is that the Secondary Server does not use/respect the "DNS Server Local End Points" value provided in the "Settings" >> "General" configuration options. That is probably a bit of an unfair way to describe it; it might be more accurate to say that there is no option in the configuration settings to allow an administrator to explicitly define a local host's IP address to be used for AXFR/IXFR traffic - instead the running binary just seems to grab the host's primary address and uses that for all synchronisation traffic with the Primary.

I'm reporting this as a bug - rather than an enhancement request - because I think that the label of "DNS Server Local End Points" implies the IP address to be used for "all DNS related network activity", even though that is not currently happening in practice.

I think there are two possible technical approaches to a solution I would like to see... One might be to change the code so that the AXFR/IXFR traffic uses whatever IP Address is set in the "DNS Server Local End Points" field [which, honestly, I'm less keen on]. The other would be to create a new field and allow the admin user to explicitly nominate the address they want to use.

I absolutely appreciated that:-

1. I already have a functional work-around - this is not a "show stopper" issue by any means
2. I am one of those extreme outlier use cases - someone who wants to deploy Technitium in a possibly unconventional way.

As a result, I do not expect this to get priority attention. However, I very much hope that you're able to come up with a way to make Technitium's use of IP addresses more transparent [and, hopefully, more configurable], for users.

[ShreyasZare]

Thanks for the post. The DNS Server Local End Points option is to specify the address the DNS server must listen on for DNS over UDP and TCP services. It does not specify the IP address that the DNS server should use for outbound requests.

A secondary zone uses a DNS UDP request to query SOA to decide if an update is available for the zone. UDP requests will get sent from the interface which has the default gateway which the OS selects on its own. If you wish to define the source IP address for all outbound requests then you need to configure the DNS Server IPv4 Source Addresses option in the same location.

[sproggit]

Thanks for responding so promptly.

In your reply, I see that you state, "If you wish to define the source IP address for all outbound requests then you need to configure the DNS Server IPv4 Source Addresses option in the same location."

I just checked the Secondary server and I can confirm that the named field currently contains the value "172.16.103.241", but when I check the logs on the primary server, I see

"[2026-02-23 15:34:32 UTC] [172.16.103.24:42944] [TCP] DNS Server received zone transfer request for zone: {redacted}.net"

From my limited understanding, I am expecting the log to say that it has received the sync request from 172.16.103.241, but the primary server log is reporting the sync request coming from 172.16.103.241.

My understanding of what should happen is entirely consistent with your explanation - that if I set the "Source Addresses", then that is where I expect the outbound traffic from the Secondary server to originate. However, it looks as though the value provided by "DNS Server IPv4 Source Addresses" is only being used for referrals, not for replication.

[ShreyasZare]

Thanks for the details. Please share a screenshot of the Settings > General section so that I can understand how the exact config is to try to reproduce the issue.

[sproggit]

Thanks again Shreyas. Two images attached - for Primary and Secondary servers.

Primary

Secondary

[ShreyasZare]

Thanks for the details. I tried the same scenario and was not able to reproduce this issue. The AXFR request is using the source address that was configured in this test. This was verified by running packet capture to confirm the address being using.

Not sure why its not working for your setup. How is the DNS server installed? Is it installed natively using the install script or are you using docker?

[sproggit]

The setup was performed using a pair of Raspberry Pi4B machines, both configured using the latest published binary [dated 4th December 2012]. I performed a clean installation on a pair of machines and then ran a full update and then installed using the "curl" script provided on the main project web site.

I've made no other changes.

I am starting to wonder if the delta that we are exploring here has its origin at the intersection of the Technitium binaries [or maybe the .Net network stack] and the native Raspberry Pi / Debian 13 OS?

This is what my Primary host looks like from a network perspective:-

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether dc:a6:32:55:07:69 brd ff:ff:ff:ff:ff:ff
inet 172.16.103.21/16 brd 172.16.255.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet 172.16.103.211/16 brd 172.16.255.255 scope global secondary noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 fe80::beb2:6300:1467:e2d7/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether dc:a6:32:55:07:6a brd ff:ff:ff:ff:ff:ff

[ShreyasZare]

I tried this earlier on Ubuntu server and it was working. I now tried with Raspberry Pi and I am able to reproduce this issue. Firstly, the DNS server does not use the Source Address. The reason was that when the DNS server started, the secondary IP was not set and thus it was not picket up. So, I restarted the systemd dns service and it picked up the source address. But, then there was another issue. The correct source IP was being used for outbound packets, and the destination server was receiving them. However, the response was getting dropped somewhere as I could not see the response coming in tcpdump. I am not sure what could be the issue with Raspberry Pi OS. The same exact test worked with Ubuntu server.

[sproggit]

Thanks, Shreyas, your testing now completely matches my experience.

What's interesting about the results we both see is that both Ubuntu and Raspberry Pi OS are derivatives of Debian ... so clearly what we're seeing is an issue that is either being introduced by Raspberry Pi's developers, or maybe exists in the Debian package and is being "fixed" by other changes that Ubuntu make in the networking stack code.

I have an idea of something I can try to see if it is possible to get the result that I want...

What I'm going to do is uninstall Technitium from the two Pi machines, then reconfigure their network setup so that each machine has only a single IP address - 172.16.103.211 [Primary] and 172.16.103.241 [Secondary]. I'm then going to create a Zone and configure the two servers to replicate. I'll prove that it works by adding some hosts on the Primary, then use the Web Admin panels to confirm the new A records appear on the secondary... When I see that, I'll then check the logs to confirm that the sync traffic is coming from 172.156.103.241 - which is what I want...

When that is working, I'm going to go back to the two hosts and I'll add 172.16.103.21 and 172.16.103.24, respectively, to the hosts. I'll then use the "Resync" button on the Secondary server to provoke a resync to occur, and check the logs on the Primary to see which IP address the secondary uses when it makes the AXFR/IXFR connection.

Depending on how Technitium is written, it might be that it captures and records local IP address details during setup, such that presenting the software with the single [desired] IP address during installation enables it to be configured correctly.

No idea if this will work or not, but it seems like a potentially viable test. I'll report back with the result....

[sproggit]

OK I've run an additional test - and this time I've got an interesting / somewhat expected result. Here's what I did:-

1. Perform a "full" uninstall of the DNS package from both Pi hosts. Manually remove the "/etc/dns/" folder and contents.

2. On each host, remove all IP addresses, except 172.16.103.211 on the Primary and 172.16.103.241 on the Secondary.

3. Install Technitium on both hosts

4. Set up '211 to be a Zone Primary and '241 to be a Zone Secondary.

5. Get replication working and confirm.

6. Go back in to the "sudo nmtui" network management utility and add back in the '21 and '24 addresses, intended to be the primary addresses for the host.

7. Re-test synchronisation and confirm that it works - it does...

8. Run an "ip addr" and confirm that both addresses now exist - they do - but note that in ip addr output, they now appear out-of-order, with the '211 address appearing before the '21 address and the '241 address appearing before the '24 address...

9. Being excessively fussy, navigate to /etc/NetworkManager/system-connections and manually edit the file found there, "Wired connection 1.nmconnection", to re-order the IPv4 addresses, such that "address1" are now the .21/.24 address[es] and "address2" are set to the .211/.241 addresses.

10. Perform a "sudo systemctl restart NetworkManager" - and then use ip addr to confirm that the IP addresses are present, but that they appear in the "correct" sequence.

11. Go back to a web browser, navigate to the Secondary DNS web admin panels and click "Refresh" for a Zone refresh with the Primary

12. Go to the Primary server logs and look ... and see that an error message is reported:-

[2026-02-24 16:01:48 UTC] [172.16.103.24:41676] [TCP] DNS Server refused a zone transfer request since the request IP address is not allowed by the zone: {redacted}.net

13. On the Primary Server, navigate to the "Zones" tab in the Admin screens. Select the newly created Zone and then "Zone Options". In the Options pop-up, click to the "Zone Trasfer" tab and manually add the new "Primary" address assigned to the network adapter for the Secondary DNS Server [172.16.103.24] to the "Network Access Control LIst (ACL) field...
14. Switch back to the Secondary Server and re-initiate the "Resync" process by manually clicking the appropriate command button.
15. Check the logs on the Primary Server and see that they synchronisation request has been accepted and serviced.
16. Manually add a host to the Primary and check that it replicates to the secondary as evidence that replication is now working.

Conclusions
The Zone replication process in Technitium DNS is "hard wired" to always use the Primary Network Address on a multi-homed network adapter, irrespective of what may have been set up in the configuration settings. The selection of the network address happens dynamically, in real, time - Technitium does not cache or remember the address used for the first sync [which is wise, because the network configuration may change over time].

Unfortunately for my extremely esoteric requirements, it means that even though I'm able to get Technitium working on a Virtual IP Address on my Pi hardware - and to work perfectly in that manner - the DNS synchronisation traffic - the AXFR/IXFR exchanges - will always disregard any configuration settings and use the "primary" assigned IP Address.

There is an entirely valid/reasonable work-around here - simply go to the Primary DNS and ensure that it is configured to accept sync requests from the relevant IP addresses. However, it does mean that the sync traffic operates independently of the configuration a user may set in the "Settings>>General" panels and cannot be forced to comply with an explicitly nominated IP Address.

I think there's one more thing that might be interesting to try... but I think it's a bit "unsafe" as a general network practice. I also happen to have a USB3-to-Ethernet adapter for my laptop... so I should be able to add that to the Secondary DNS host, giving it 2 ethernet adapters. It might be interesting to see how the software handles the selection of an Ethernet adapter to use for synchronisation traffic if they're both connected to the 172.16.. network... Is there a ranking between adapter as well as VIP's on a single adapter? Seems likely...

[ShreyasZare]

You can just use DNS Client tool on the admin panel for this test. The source address used by outbound calls works the same be it a recursive resolution request, request via DNS Client, or a AXFR zone transfer request. All outbound DNS queries use the same code and Source Address gets configured statically for use by all cases. So, there is no need to test this with primary-secondary zone setup.

The Zone replication process in Technitium DNS is "hard wired" to always use the Primary Network Address on a multi-homed network adapter, irrespective of what may have been set up in the configuration settings. The selection of the network address happens dynamically, in real, time - Technitium does not cache or remember the address used for the first sync [which is wise, because the network configuration may change over time].

The DNS client code does not have anything "hard wired". The DNS client just creates a socket to make outbound request and the OS will bind that socket to the default IP on that adapter which happens to be the primary/first IP that is configured.

If you configure Source Address option in Settings then the DNS client will use it to explicitly bind the socket to that local source address before making outbound request.

Another thing here is that my test result is different from yours. Your test shows that the DNS server keeps using the primary IP on the interface even when Source Address is configured. Whereas, here the DNS server is using the expected Source Address that was configured. It uses this source IP to send outbound requests, but the response somehow is getting dropped. I am not sure where it is actually getting dropped. Both the test DNS server and the DNS query it is making are connected to the same network switch and are in same /24 subnet, so there is no router in picture here. The tcpdump on the test server shows only outbound packets with correct source address but shows no responses. When using TCP, the tcpdump capture shows the SYN packets being retransmitted using the correct Source Address but there is no SYN/ACK being received.

Not really sure what the issue is in both your and my tests. The code is working well with Ubuntu Server so seems that the implementation is correct.

[sproggit]

Shreyas, I'm very grateful for your patience and your testing.

As I was clear to state at the outset, this is currently a "disappointment" rather than a material break that is causing me operational issues. It just means that I will need to think carefully about how I set out other services on this pair of Pi4B servers. [I have been running PiHole on a pair of 3B+, dedicated machines... but I have so many Pi's running that the electricity cost is starting to get significant - this is part of an attempt to simplify].

I also raised a question on the Raspberry Pi forums with regards to the way that my Pi is apparently disregarding the explicitly configured outbound IP address. If you want to monitor that to see if I get responses, you can find it here:

https://forums.raspberrypi.com/viewtopic.php?p=2365303#p2365303

Even though I'm getting unexpected results, I'm getting consistent results - so I think I can work with that.

Thanks for all your help.

[ShreyasZare]

You're welcome. For you specific scenario, you can consider configuring the Zone Transfer Allowed Networks option in the Setting > General section which will allow all the specified addresses to do zone transfer. So, no need to do zone specific config which requires doing it for all zones separately.