After upgrading to Zabbix 7.4.2 and later to 7.4.3, we observed that some hosts created or updated via Autoregistration had their “DNS name” field automatically cleared. This leads to false positives and loss of configuration. The issue is reproducible and appears whenever the Zabbix agent is configured with multiple values in ServerActive, especially when at least one of those endpoints is a proxy that does not belong to the same proxy group as the others.

When the agent is configured to talk only to the Zabbix server (no proxies), the problem does not occur, the DNS stays as configured. This proves the issue is related to how the server reconciles autoregistration data coming from multiple proxy endpoints, not to the basic autoregistration flow.

Environment

• Zabbix server: 7.4.2, 7.4.3 and 7.4.4 (issue present in all)

• Backend DB: PostgreSQL 16 (official postgres:16 image)

• Deployment: Docker Compose using official Zabbix Docker images (see “Docker Compose used to reproduce” below)

• Timezone: America/Sao_Paulo

• Agents: zabbix/zabbix-agent2:alpine-7.4-latest (pulled at test time)

• Proxies: zabbix/zabbix-proxy-sqlite3:alpine-7.4-latest

The same behavior was seen in our customer-like environment (multiple teams, thousands of servers, autoregistration mandatory).

Problem description

When the agent is started with:

ServerActive=proxyA,proxyB,proxyC

and at least one of those proxies is not in the same proxy group as the others, the next autoregistration (for example, after the agent container restarts) causes Zabbix to re-write the host interface and clear the “DNS name” field.

This is destructive because the DNS may have been set manually by an operator after the host was created. Clearing it causes:

• simple checks to fail (name resolution missing)

• triggers to fire

• host to look misconfigured, even though it was previously fixed

When we simplify the setup to:

Server=zbx-server
ServerActive=zbx-server

(i.e. only the server, no proxies), the problem does not occur: the DNS stays as “batata” (or any other value we set). This clearly shows the issue is tied to the multi-endpoint autoregistration path.