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.