# DNS Failures

## DNS Resolution Problems

A cornerstone of Twingate’s functionality is its handling of DNS. The Client intercepts DNS queries for protected Resources and securely forwards them to a Connector, which resolves the name using your internal DNS servers. A failure in this process means the user’s application never gets the correct IP address to connect to.

**Common Symptoms:**

- A user is connected to Twingate, but when they try to access an internal web application, they get a browser error like `DNS_PROBE_FINISHED_NXDOMAIN` or “This site can’t be reached.”
- A desktop or mobile application fails to connect, with logs showing errors like “host not found” or “cannot resolve hostname.”
- In the Twingate Admin Console, the **Activity** report for the Resource shows events with a “DNS lookup error” status.

**How to Identify and Troubleshoot:**

- **Test DNS Resolution on the Client device:** Use standard command-line tools on the user’s device to see how DNS is behaving.
  - Open a command prompt or terminal and run `nslookup <resource_fqdn>` (e.g., `nslookup jira.mycompany.internal`).
  - **Correct Behavior:** If the Twingate Client is correctly intercepting the request, the command should return an IP address from the Carrier-Grade NAT (CGNAT) range: `100.96.0.0/12`. This is a virtual IP address that Twingate uses internally and it confirms that the Client has identified the destination as a protected Resource. (See our guide on [How DNS Works with Twingate](/content/docs/how-dns-works-with-twingate/index.html) for more information.)
  - **Incorrect Behavior:** If the command times out, returns a public IP address, or returns an error, it means the Client is _not_ intercepting the request. This could be because the Resource isn’t defined correctly in the Admin Console, the logged-in user isn’t a member of a Group with access to the Resource, or the Client itself is having an issue.
- **Check for CGNAT IP Address Conflicts:** This is a critical and often overlooked issue. Twingate reserves the `100.96.0.0/12` IP address range for its internal operations. If the user’s local network or their ISP uses this same range for device IP addresses or DNS servers, it will cause a conflict.
  - **Diagnosis:** On the user’s machine, check their network configuration. On Windows, run `ipconfig /all`. On macOS, run `scutil --dns`. Look at the assigned IP addresses and, most importantly, the DNS server addresses. If any of these—except the Twingate adapter—fall within the `100.96.0.0` to `100.127.255.255` range, there is a conflict.
  - **Resolution:** The simplest fix is to have the user manually configure their device’s DNS settings to use a public DNS provider that is outside the conflicting range, such as Google DNS (`8.8.8.8`, `8.8.4.4`) or Quad9 (`9.9.9.9`).
- **Check DNS Resolution on the Connector Host:** If the Admin Console’s **Activity** report explicitly shows a “DNS lookup error,” the problem isn’t on the Client’s end. It means the Client successfully sent the request to the Connector, but the Connector itself couldn’t resolve the name.
  - **Diagnosis:** Log in to the server or container host where the Connector is deployed. From that machine’s command line, run `nslookup <resource_fqdn>` or `dig <resource_fqdn>`.
  - **Resolution:** If the command fails on the Connector host, it confirms a local DNS issue. You must resolve the DNS configuration on that host. This might involve editing `/etc/resolv.conf` on Linux, checking VPC DNS settings in your cloud provider, or ensuring the host has a network path to your internal DNS servers. This is why it’s a best practice to shut down all but one Connector when troubleshooting - it isolates the problem to a single host machine.
- **Check for Multiple Active Network Interfaces:** On some operating systems, particularly Windows and Linux, having both a wired (Ethernet) and wireless (Wi-Fi) connection active on the same subnet can lead to unpredictable routing and DNS behavior.
  - **Resolution:** The most reliable fix is to ensure network interface card (NIC) drivers are up to date, especially for Realtek chipsets. As a workaround, advise the user to disconnect from one of the interfaces (e.g., unplug the Ethernet cable or turn off Wi-Fi) so that only one is active.

_If DNS is resolving correctly to a `100.x.x.x` address on the Client, but the connection still fails, the issue lies further down the path with the Connector or the network route to it._

Last updated 6 months ago.