logo Go to Kayako Classic
Start a conversation Sign in
Start a conversation
  1. Kayako Support
  2. Kayako - Article Drafts
  3. Articles

Kayako Agent Portal Unreachable with “This site can’t be reached” / <code>DNS_PROBE_FINISHED_NXDOMAIN</code> (DNS Resolution Failure)

Contents

Overview

When attempting to access the Kayako agent portal (for example, https://your_instance.domain.com/agent), you may see “This site can’t be reached” and sometimes DNS_PROBE_FINISHED_NXDOMAIN. Command-line tools may show “curl: (6) Could not resolve host” or “Unable to resolve target system name”.

These symptoms indicate a DNS resolution failure on the customer network/ISP path (the hostname is not resolving to an IP address), even when the Kayako service itself is operational and reachable from other networks. In the documented scenario, the agent portal was reachable during validation checks and there was no Kayako status-page incident for the NXDOMAIN symptom; the confirmed root cause was ISP/DNS-related, not a Kayako platform outage.

Solution

Issue

The Kayako agent portal fails before loading, commonly presenting as:

  • Browser: “This site can’t be reached”
  • Browser (Chrome): DNS_PROBE_FINISHED_NXDOMAIN
  • CLI: “curl: (6) Could not resolve host: your_instance.domain.com”
  • CLI: “Unable to resolve target system name your_instance.domain.com”
  • nslookup (default resolver): “can’t find …: Unspecified error” or NXDOMAIN-type behavior

What this means

These errors indicate the request is failing at DNS name resolution (your environment cannot translate your_instance.domain.com into an IP). In this scenario, Kayako can still be healthy; the problem is typically caused by:

  • A failing/filtered local DNS resolver (router, firewall, internal DNS server)
  • ISP DNS issues or upstream DNS forwarding problems
  • DNS filtering/security policy blocking the hostname or its CNAME/load-balancer target

How to diagnose

1) Compare your default DNS resolver vs. known-good public DNS

On an affected Windows machine:

  1. Check what your default resolver returns:

    nslookup your_instance.domain.com

    Note the Server: line (often a router/internal DNS such as <local_dns_resolver> / <local_resolver_ip>).

  2. Query known-good public resolvers:

    nslookup your_instance.domain.com 8.8.8.8
nslookup your_instance.domain.com 1.1.1.1

Interpretation

  • If the default lookup fails but 8.8.8.8/1.1.1.1 succeed, the failure point is your network’s configured DNS resolver/ISP DNS path, not Kayako.
  • Example failure indicators include: “Unable to resolve target system name …”, “Could not resolve host …”, and DNS_PROBE_FINISHED_NXDOMAIN.

2) Confirm whether the issue is isolated to a specific network

If permitted by policy, test from a different network:

  • Mobile hotspot / USB tethering
  • Another ISP connection

If it works on the alternate network but not on the primary network, that strongly indicates an ISP or corporate network DNS issue.

3) Optional: capture a HAR file for browser-side evidence

If teams need proof the browser fails before reaching Kayako, capture a HAR file while reproducing the issue:

  • Capture a HAR while attempting to load https://your_instance.domain.com/agent.
  • A DNS failure will typically show the request never successfully initiates a connection to Kayako endpoints (consistent with failing nslookup on the default resolver).

Resolution / Mitigation

Option A — Temporarily bypass the failing resolver (workstation-level)

If your IT policy allows, set the affected machine to use a working DNS resolver (for example, 8.8.8.8 or 1.1.1.1).

Windows 10/11 (typical path)

  1. Settings → Network & Internet → Advanced network settings → More network adapter options
  2. Right-click the active adapter → Properties
  3. Select Internet Protocol Version 4 (TCP/IPv4) → Properties
  4. Choose Use the following DNS server addresses and enter:
    • Preferred DNS: 8.8.8.8 (or 1.1.1.1)
    • Alternate DNS: 1.1.1.1 (or 8.8.8.8)

Then flush local DNS and retest:

ipconfig /flushdns
nslookup your_instance.domain.com

Option B — Fix the resolver (network/ISP-level)

If DNS is provided by a router/firewall/internal DNS server:

  • Review which resolver clients are using (often the gateway IP).
  • Verify DNS forwarding works and that no DNS filtering/security policies are blocking:
    • your_instance.domain.com
    • Any CNAME/load-balancer alias it resolves to (your DNS output will show this)
  • Check for cached NXDOMAIN results or stale/incorrect forwarding behavior.

If DNS is ISP-managed:

  • Engage the ISP to correct DNS forwarding/caching/filtering that is causing NXDOMAIN/lookup failures for your_instance.domain.com.

Validation (confirm the fix worked)

  1. nslookup your_instance.domain.com should return a valid answer (IPs and/or a CNAME chain).
  2. Load https://your_instance.domain.com/agent in an incognito/private window.
  3. If the issue previously reproduced only on a specific network, validate again from that same network to confirm stability.

If access works but in-app actions fail

If the portal loads but actions inside the agent UI fail (for example, an in-app “Oops something went wrong” message when opening a conversation or sending a reply), treat it as a separate symptom and collect:

  • Exact timestamp + timezone
  • The conversation/ticket identifier involved
  • Screenshot of the message

This helps correlate behavior to backend logs. Note that an internal infrastructure review may be performed for intermittent UI symptoms; however, the “site can’t be reached” / NXDOMAIN symptom specifically indicates a DNS-resolution failure upstream of Kayako.

Frequently Asked Questions

1. How do I know this is DNS and not a Kayako outage?

If you see DNS_PROBE_FINISHED_NXDOMAIN, “This site can’t be reached,” or CLI output like “curl: (6) Could not resolve host,” the failure is occurring during DNS lookup.

A quick confirmation is: if nslookup your_instance.domain.com 8.8.8.8 works but nslookup your_instance.domain.com (default) fails, the issue is your DNS resolver/ISP path.

2. What should I send to my ISP or network administrator?

Provide the exact error(s) and the outputs of:

  • nslookup your_instance.domain.com (default resolver)
  • nslookup your_instance.domain.com 8.8.8.8
  • nslookup your_instance.domain.com 1.1.1.1

If public resolvers succeed and the default fails, ask them to investigate DNS forwarding/filtering/caching on the default resolver.

3. Why does it work on a mobile hotspot/USB tether but not on my office network?

This pattern indicates the office network’s DNS resolver or ISP path is failing (or filtering) DNS resolution for the hostname. The Kayako service can be reachable, but your primary network cannot resolve the hostname to an IP.

4. I flushed DNS and tried incognito mode but it still fails. What’s next?

Flushing DNS clears only the local client cache. If the upstream resolver (router/firewall/internal DNS/ISP DNS) is returning NXDOMAIN or failing to resolve, the problem will persist until that resolver is fixed or bypassed (for example, by temporarily using a known-good DNS server like 8.8.8.8/1.1.1.1).

5. After fixing DNS, what’s the quickest way to verify everything is normal?

Run nslookup your_instance.domain.com and confirm it returns a valid answer, then load https://your_instance.domain.com/agent in a private window. If the issue previously reproduced only on a specific network, validate again from that same network.

Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Priyanka Bhotika

  2. Posted

Comments