Last update:
Last verified version: AMC 3.2.1
Problem
When installing the ASGARD Agent on a Linux system that uses a split-horizon configuration in their local DNS resolve configuration, the Agent can show unexpected behavior leading to the inability to connect to the ASGARD Management Center.
If this is the cause of a connection error between ASGARD Agent and ASGARD Management Center can be verified by reviewing the agent log.
sudo cat /var/lib/asgard2-agent/log/agent.log | egrep -a "connect.*to asgard"
2026/01/15 09:38:01 ASGARD_AGENT: Info: tcp connection to asgard established PROXY: REMOTE_ADDR: [[ASGARD_IP_ADDRESS]]:443 ADDRESS: [[ASGARD_FQDN]]:443
2026/01/15 09:38:06 ASGARD_GENERIC: Info: {"level":"ERROR","time":"2026-01-15T09:38:06+01:00","message":"connect to asgard failed","component":"controller","address":"[[ASGARD_FQDN]]:443","proxy":"","error":"dial tcp: lookup [[ASGARD_FQDN]]: no such host"}
In the log you see a “connection to asgard established” followed by a sequence of log lines stating “no such host”.
What is split-horizon DNS?
A split-horizon DNS setup is often used for VPN setups into corporate networks. A Laptop may be at first connected to a local WiFi network and is then used to dial into a VPN network. Depending on the system configuration this will lead to a system with two DNS servers that are not sharing the same information (one may be a default internet router, the other the corporate DNS with an internal DNS zone configuration).
Reason
The cause for this behavior is a difference in the used libraries, that are using DNS resolutions differently. One of these implementations (the more common one) is resolving names by using one DNS server at a time until there is an answer. The other one is sending the DNS request to all configured servers and is using the first answer.
The common setup would be that the corporate DNS server is the first in the list to properly resolve all corporate resources. Nevertheless with the second implementation the local DNS is usually the first to respond. So the answer is “no such host” (NXDOMAIN), which is then accepted by the library as the anwer.
Solution
This change only affects the ASGARD Agent and will persist after updates. Other services on the system are not impacted.
Until the behavior is adjusted this issue can be resolved by setting the environment variable GODEBUG=netdns=go for the ASGARD Agent Service on systems that are affected. This setting forces the ASGARD Agent to use Go’s internal DNS resolver, which queries nameservers sequentially (like most Linux systems) instead of in parallel. This avoids race conditions where a faster but incorrect DNS response is accepted.
Stop the Agent service and open the systemd service configuration of the ASGARD Agent service:
systemctl stop asgard2-agent
systemctl edit asgard2-agent
Add the following two lines for the environment variable configuration:
[Service]
Environment=GODEBUG=netdns=go
The output will look like this:
### Editing /etc/systemd/system/asgard2-agent.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file
[Service]
Environment=GODEBUG=netdns=go
### Edits below this comment will be discarded
### /etc/systemd/system/asgard2-agent.service
# [Unit]
# Description=
# ConditionFileIsExecutable=/usr/sbin/asgard2-agent-service
#
#
# [Service]
# StartLimitInterval=5
# StartLimitBurst=10
# ExecStart=/usr/sbin/asgard2-agent-service
#
#
#
#
#
#
#
# Restart=always
#
# RestartSec=120
# EnvironmentFile=-/etc/sysconfig/asgard2-agent
#
# [Install]
# WantedBy=multi-user.target
Save and exit the editor. Then perform a daemon-reload to update the service configurations and start the ASGARD Agent:
systemctl daemon-reload
systemctl start asgard2-agent
Afterwards review the log and check if the connection is created properly after the change.
Revert the workaround
The described changes can be rolled back to default by the following steps:
systemctl stop asgard2-agent
systemctl revert asgard2-agent
systemctl daemon-reload
systemctl start asgard2-agent