Bug: RFC2136 reports multiple nameservers as failed when only one nameserver is unreachable

What happened?

I am seeing incorrect/misleading warning logs when ExternalDNS is configured with multiple RFC2136 nameservers.

In my setup, two nameservers are configured:

192.168.101.200
192.168.101.201

When one nameserver becomes unreachable, ExternalDNS reports both nameservers as having failed, even though the actual AXFR connection failure occurred only against 192.168.101.200.

For example, the logs show:

time="2026-09-10T04:36:49Z" level=info msg="Configured RFC2136 with zones '[mbl.int.internal]' and nameservers '[192.168.101.200 192.168.101.201]'"

time="2026-09-09T06:14:53Z" level=warning msg="Last operation failed for nameserver 192.168.101.200:53"

time="2026-09-09T06:14:55Z" level=warning msg="Last operation failed for nameserver 192.168.101.201:53"

time="2026-09-09T06:14:55Z" level=warning msg="Last operation error message: failed to fetch records via AXFR: failed to connect for transfer: dial tcp 192.168.101.200:53: i/o timeout"

time="2026-09-09T06:14:55Z" level=error msg="Failed to do run once: soft error\nfailed to fetch records via AXFR: failed to connect for transfer: dial tcp 192.168.101.200:53: i/o timeout (consecutive soft errors: 83)"

The important point is that the actual error is:

dial tcp 192.168.101.200:53: i/o timeout

However, ExternalDNS also reports:

Last operation failed for nameserver 192.168.101.201:53

This gives the impression that both nameservers are down, which is misleading.

Expected behavior

When an operation fails against a specific nameserver, the warning should identify only the nameserver on which the operation actually failed.

For example:

WARNING: AXFR failed for nameserver 192.168.101.200:53:
failed to connect for transfer: dial tcp 192.168.101.200:53: i/o timeout

If ExternalDNS retries the operation using 192.168.101.201 and it succeeds, the logs should indicate that the second nameserver was successfully used.

For example:

INFO: AXFR succeeded using nameserver 192.168.101.201:53

Therefore, the logs should distinguish between:

192.168.101.200 -> FAILED
192.168.101.201 -> SUCCESS

rather than reporting both as failed.

How to reproduce

1. Configure ExternalDNS with the RFC2136 provider and two nameservers:

--rfc2136-host=192.168.101.200,192.168.101.201

1. Enable AXFR using:

--rfc2136-axfr

1. Make only one nameserver unreachable. For example, make:

192.168.101.200:53

unreachable while keeping:

192.168.101.201:53

available.

1. Trigger ExternalDNS reconciliation.

2. Observe the warning logs.

Actual behavior

ExternalDNS logs a failure for both nameservers:

Last operation failed for nameserver 192.168.101.200:53
Last operation failed for nameserver 192.168.101.201:53

while the actual underlying error identifies only:

192.168.101.200:53

as the endpoint that failed.

Expected behavior

The failure should be associated only with the nameserver where the operation failed.

If failover to another nameserver succeeds, the logs should clearly show the successful nameserver as well.

For example:

WARNING: AXFR failed for nameserver 192.168.101.200:53: connection timeout
INFO: AXFR succeeded using nameserver 192.168.101.201:53

Impact

This is primarily an observability and troubleshooting issue.

In a production environment with multiple DNS nameservers, these messages can incorrectly indicate that all configured nameservers are unavailable. This makes it difficult for operators to identify the actual failed DNS server and can lead to unnecessary investigation or failover actions.

The underlying reconciliation may still succeed when another nameserver is available, but the warning/error reporting incorrectly attributes the failure to multiple nameservers.

Proposed fix

The nameserver associated with an operation should be captured and reported at the actual AXFR/update operation site.

Specifically:

• Do not emit a deferred Last operation failed warning based on the current/rotated nameserver.
• Report the failure immediately with the exact nameserver used for that operation.
• Preserve the nameserver associated with the actual error during nameserver rotation/failover.
• Log successful AXFR/update operations with the nameserver that successfully handled the operation.

This will ensure that RFC2136 failover logs accurately represent the actual status of each nameserver.