Third-Party Patch Fails with "lookup cdn.automox.com: no such host"

Issue

A third-party application patch fails on a device, and the device's Activity Log shows that the download step could not resolve cdn.automox.com. The error resembles the following, with the application name and version varying by which title was being patched:

level=ERROR command="InstallUpdate" message="update failed: step "download-new-version"
(Download New Version) failed after 1m41.428s: download failed after 3 attempts:
HTTP request failed: Get "https://cdn.automox.com/software-catalog/downloads/<application/
install-update/<Application/<Platform/<version/download.pkg?token=<redacted":
dial tcp: lookup cdn.automox.com: no such host"

The patch policy reports the device as failed. Other devices in the same organization patch the same application successfully, and the affected device often patches successfully on its next run without any change having been made.

Environment

• Automox agent on Windows, macOS, or Linux (any currently supported agent version)
• Third-party (non-operating-system) application patching, run from a Patch Policy or from Patch Now
• Outbound HTTPS on 443/tcp to cdn.automox.com, listed in Agent Firewall Allowlisting Rules

Overview

Third-party patch content is downloaded from Automox content delivery endpoints at the moment the patch runs. cdn.automox.com is one of those endpoints.

no such host is a name resolution failure, not a connectivity or content failure.

• The device's DNS resolver returned no address for cdn.automox.com, so the download request never left the device.
• Nothing reached Automox, which means the failure is not caused by the patch content, the application version, or the state of the Automox platform.

The download step retries three times inside a short window.

• All three attempts occur within roughly two minutes.
• A resolver outage lasting only a minute is therefore long enough to fail the entire step and mark the patch failed.

The application named in the error is incidental.

• Because resolution fails before any application-specific work happens, the error names whichever title happened to be downloading at that moment.
• The same failure appears against many unrelated applications on the same device over time, so the named application is not a useful diagnostic signal and the application itself does not need to be investigated.

Distinguishing this failure from the other download failures. The wording of the error identifies which layer failed:

Resolution

1. Re-run the patch on the affected device, using Patch Now or by triggering the patch policy again. Transient resolution failures clear on the next attempt, and a successful re-run confirms the cause was momentary rather than a configuration problem.
2. Confirm that cdn.automox.com is permitted outbound on 443/tcp, and that it is allowlisted by hostname rather than by IP address alone. The full endpoint list is in Agent Firewall Allowlisting Rules. Content delivery addresses change, so an IP-only allowlist will fail intermittently.
3. Test name resolution from the affected device:

   • Windows (PowerShell):

     Resolve-DnsName cdn.automox.com

   • macOS or Linux:

     dig cdn.automox.com +short

     Interpret the result as follows:

   • One or more addresses returned. Resolution is working at the time of the test, which is consistent with an intermittent failure. Continue to step 4.
   • No address, NXDOMAIN, or a server-failure response. Resolution is broken now, and the device will keep failing third-party patches until it is fixed. Continue to step 5.

4. Review what the device's network was doing when the patch ran. Compare the failure time in the Activity Log against the device's network activity, and look for:

   • A VPN client connecting or disconnecting, which replaces the device's resolver mid-session
   • A handoff between Wi-Fi and wired, or between wireless networks
   • Sleep, wake, or resume from hibernation
   • A captive portal that had not yet been satisfied

   A patch run that lands inside any of these transitions fails this way. Where possible, schedule patch policies for a window when target devices are settled on a stable network rather than during arrival or departure hours.

5. Check for a resolver on the device that cannot answer for external names:
   • DNS filtering or security products. Confirm that cdn.automox.com is permitted, and that the product is not returning an empty answer for the name.
   • Split-tunnel VPN configuration. Confirm that queries are not being sent to an internal resolver that is unreachable while the tunnel is partially up.
   • A stale resolver cache. Flush it and retest:
     • Windows: ipconfig /flushdns
     • macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
     • Linux (systemd-resolved): sudo resolvectl flush-caches
6. Confirm the device is still checking in to the console. The agent resolves api.automox.com through the same resolver, so a device that has genuinely lost name resolution altogether also stops checking in. A device that is checking in normally but failed to resolve cdn.automox.com at patch time had a momentary resolver problem, not a persistent one.
7. Escalate internally if a single device consistently fails to resolve cdn.automox.com while other devices on the same network resolve it successfully. The problem is local to that device's network or resolver configuration and cannot be corrected from the Automox console.

8. Contact Automox Support if either of the following is true:

   • Name resolution for cdn.automox.com succeeds consistently from the device, but the download still fails.
   • Many devices across different networks begin failing at the same time.

   Include the full Activity Log output from a failed run and the output of the resolution test in step 3.

Notes

• This error is not necessarily an Automox outage. Because the request never leaves the device, a resolution failure on one device says nothing about the availability of Automox content delivery. A genuine platform problem presents differently: many devices on unrelated networks fail at the same moment, and the errors are HTTP status codes or connection failures rather than no such host.
• A failed patch does not remove the patch from scope. The device remains non-compliant and the patch is attempted again on the next policy run. For the behavior of a policy after a failure, see What Happens When a Patch Policy Fails.
• Other causes of third-party patch failure are covered in Troubleshooting Third-Party Application Patch Failures, including an application being in use at patch time.
• Linux devices have an additional requirement. Operating system packages on Linux are downloaded from the distribution's own repositories rather than from Automox, so those repository hostnames must also resolve and be reachable. See Network Traffic Required for Patching Linux Devices.
• For more detail than the Activity Log shows, the agent log on the device records the same download attempt. See Reading Automox Agent Log Files.