In this article:
Overview
When the Twingate Client is active on Windows, it routes all DNS lookups through its internal DNS proxy to enforce access control and ensure accurate name resolution for private resources.
As part of this behavior, any attempt to manually specify a DNS server (for example, using nslookup
with a custom resolver) will be blocked. This is expected and by design.
Example:
>nslookup google.com 8.8.8.8
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 8.8.8.8
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out
This will fail, even though the same domain might resolve correctly through the Twingate Client using standard system lookups or a basic nslookup
without specifying a DNS server:
>nslookup google.com
Server: UnKnown
Address: 100.95.0.251
Non-authoritative answer:
Name: google.com
Addresses: 2607:f8b0:400a:800::200e
142.250.217.110
Why This Happens
Twingate uses a transparent DNS proxy that listens on a virtual network interface (usually with an IP like 100.95.0.x
). It intercepts and handles all DNS queries to resolve private resources securely.
Manually bypassing that proxy by specifying a resolver like 8.8.8.8
causes the request to be blocked, since:
- The DNS request would leave the Twingate-controlled path.
- The domain may not be resolvable via public DNS.
- Twingate enforces this behavior to prevent information leakage and maintain secure resource resolution.