twingate-dns-security

Role

This skill owns Twingate's Internet Security product area: DNS filtering, exit networks, DNS-over-HTTPS, and browser security. It covers DNS Security Profile design, priority ordering, group-based policy assignment, exit network egress patterns, and the licensing boundary between Internet Security and Private Access. It is the authority on when to use DNS filtering versus exit networks versus resource-level access policy.

Decisions & Guidelines

• Confirm Internet Security entitlement before designing any solution around DNS filtering or exit networks. Internet Security is a separate product area and may require a different license tier. If the customer doesn't have entitlement, DNS Security Profiles and exit network configuration won't appear in the admin console.
• Exit networks route traffic to a fixed egress point — they do not block destinations. If the goal is to prevent access to a website, use DNS filtering. If the goal is to ensure traffic exits from a fixed IP, use an exit network. These are not substitutes.
• Priority is numeric, and lower number = higher priority. This is the most commonly confused aspect of DNS Security Profile assignment. A permissive Engineering profile at priority 1 beats a restrictive Corporate profile at priority 2, even when the user is in both groups.
• Always configure the "Everyone" group as a baseline with the high-confidence threat categories blocked at minimum. Users not in any group with a profile receive no filtering at all. "Everyone" is the safety net. Current category names and recommended baseline categories are in references/dns-security-overview.md and references/dns-filtering.md.
• Enable STRICT fallback mode only after pre-populating the allow list with the customer's known-good domains. STRICT mode (deny-by-default) will block legitimate SaaS tools until they are explicitly allowed. Always roll out STRICT to a pilot group first.
• DNS-over-HTTPS in Twingate covers only DNS queries that flow through the Twingate Client. It does not encrypt OS-level DNS for non-Twingate traffic or queries made before the Client starts. If full-device DoH is required, configure it at the OS or network level in addition to Twingate.
• A "DNS conflict" symptom is usually a CGNAT range collision or a competing DNS-modifying tool, not a Twingate misconfiguration. Twingate claims the entire 100.96/12 range and acts as a transparent DNS proxy on only one interface (the default gateway's). Before redesigning a DNS Security Profile, rule out a third-party DNS filter/AV product or a multi-NIC environment — the help-center corpus documents the specific known conflicts and their workarounds.

Search References First

Grep references/ with the user's own keywords or exact error text before answering. Vendor names, CGNAT ranges, and exact log lines live in the file bodies, not the filenames: