--- title: "Device DNS configuration" slug: "device-dns-configuration-v6-5" description: "Optimize your DNS configuration with auto-configuration and policies for consistent behavior across systems, enhancing security and user access." updated: 2025-10-31T18:26:03Z published: 2025-10-31T18:26:03Z canonical: "support.appgate.com/device-dns-configuration-v6-5" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.appgate.com/llms.txt > Use this file to discover all available pages before exploring further. # Device DNS configuration DNS configuration in the Appgate SDP system can be done in two ways, both aimed at providing consistency in DNS behaviors across different operating systems. They use specialized configuration options, driven by special syntax that overcomes the limitations outlined above, providing the optimal match-domain model for DNS requests. Unless you are using the Client DNS auto-configuration option, you need to add an Entitlement so the user's application is able to access the DNS server(s) you have specified. Leave access control set to *Always Allow Action(s)*. ## Using DNS auto-configuration (Preferred) The Client DNS auto-configuration simplifies DNS configuration in that users are no longer required to manually create the DNS Policy and an Entitlement to associate with that Policy and any related groups. *Use the* [*Sites*](/v1/docs/dns-resolving) *UI to configure DNS using auto-configuration.* The Client DNS auto-configuration feature uses your resolver's DNS settings for Clients when no other DNS Policy exists. To do this, when configuring a DNS Resolver for the Site, you define the DNS Server and the Match Domain. Then you select *Enable auto-configuration* under Client DNS to ensure the Client is configured in the same way as the Gateway. A DNS Policy will then be automatically created along with a suitable Entitlement. This will be assigned automatically when a user has at least one other Entitlement for this Site and no other DNS Policy assigned. ## Using DNS Policy (Advanced) When DNS configuration is set using a DNS Policy, it makes it possible to configure multiple different DNS user groups within one system based on criteria such as IdP or geo location of the user. *Use the* [*Policies*](/v1/docs/policies) *UI to add a DNS configuration.* You do not need to consider special syntax when using a DNS Policy as the only option is when the use of a default domain is required. The affinity that links a specific DNS server to a DNS domain is generated from the list in the DNS Policy. This will generate as many affinity pairs as required which can be specified in any order: `10.11.12.13 <> foo.com` - this setting will use **10.11.12.13** but only for DNS requests ending in **foo.com**. The most specific domain will always have the highest priority: `10.11.12.13 <> foo.com10.11.12.113 <> bar.foo.com` - this setting will use **10.11.12.113** for DNS requests ending in **bar.foo.com** and **10.11.12.13** for DNS requests ending in **notbar.foo.com**. After all match domains are dealt with, the system DNS (default) will be used to resolve all other DNS requests. ### Default domain syntax - Mobile Clients use the built-in VPN implementation of the mobile operating system. These require a default DNS server to be configured for the system to use. For iOS, IPadOS, Android, and Chrome you must include a *default* domain or no DNS settings will be applied. (For example, you could set the *default* domain to 8.8.8.8 and have a match domain to an internal server such as 172.10.1.20.) - Portal and Lite Clients operate in a less advanced environment than the normal Client but still require a DNS Server configured to work. For this type of Client you must include a *default* domain or no DNS settings will be applied. - Desktop Clients may be required to overrule the system DNS and send all DNS requests through Appgate SDP, possibly to a secure internal DNS server. Therefore, you can include a *default* domain for desktop operating systems. To specify a *default* domain, enter `default` into the *Match Domain* field and add one or more IP addresses into the *DNS Servers* field: `10.11.12.13 <> default` - this will force all DNS requests to use **10.11.12.13** It is possible to combine the *default* domain with specific domains: `10.11.12.13 <> default10.11.12.113 <> bar.foo.com` **10.11.12.113** will be used for DNS requests ending in **bar.foo.com** and **10.11.12.13** for all other DNS requests. ## Within IdP configuration (Deprecated) When DNS configuration is done within the Identity Provider it makes it possible to configure DNS differently for divergent user groups (tenants) within one system. This can be useful when, for instance, when one business is merging with another. *Use the* [*Identity Providers*](/v1/docs/general-settings) *UI to add a DNS configuration.* You may or may not need to use this special syntax depending the native behavior of the device operating systems and your actual requirements. - This syntax is NOT supported for **Portal Clients** which ONLY uses the *DNS Servers* configuration (and ignores the *DNS Domains* configuration). - When entering multiple *DNS Domains* they can be specified in any order. The DNS Domain syntax follows the format: `dns.server.<IP address>.<domain>.<action>` The `<action>` being optional. ### All operating systems To improve affinity, the special syntax can be used to link a specific DNS server IP address to a DNS domain: `dns.server.10.11.12.13.foo.com` - this setting will use **10.11.12.13** but only for DNS requests ending in **foo.com**. It is possible to specify multiple domains using the special syntax, in which case the most specific domain will always have the highest priority: `dns.server.10.11.12.13.foo.comdns.server.10.11.12.113.bar.foo.com` - this setting will use **10.11.12.113** for DNS requests ending in **bar.foo.com** and **10.11.12.13** for DNS requests ending in **notbar.foo.com**. ### Windows and Linux The *DNS servers* setting will be tried to resolve all other DNS requests not specified in *DNS Domains* since Appgate SDP has the highest priority. ### macOS macOS has native affinity, but the *DNS servers* setting can be used in conjunction with additional *DNS Domains* that use the special syntax: `foo.comdns.server.10.11.12.113.bar.foo.com` - this setting will use **10.11.12.113** for DNS requests ending in **bar.foo.com** and the specified *DNS server* for DNS requests ending in **notbar.foo.com**. The system DNS will be used to resolve all other DNS requests not specified in *DNS Domains*. That said, there may be occasions where you would like to overrule the system DNS and send all the DNS requests through Appgate SDP, for instance to some secure internal DNS server. To do this, the option can be used on the end of the special syntax. If the specified is *default* the specified IP address is used as the default DNS server: `dns.server.10.11.12.13.default` - this will force all DNS requests to use **10.11.12.13** Again, it is possible to combine this special syntax with the normal format macOS uses, such as: `dns.server.10.11.12.13.defaultbar.foo.com` - the *DNS server* configuration will be used for DNS requests ending in **bar.foo.com** and **10.11.12.13** for all other DNS requests. #### **Improving look up times** To improve look up times, the option can be used on the end of the special syntax. If the specified is *nxdomain* it just returns NXDOMAIN: `dns.server.1.2.3.4.foobar.com.nxdomain` - this setting means the driver will never send the DNS request to 1.2.3.4 for foobar.com but instead it returns NXDOMAIN. > [!NOTE] > **NOTE** > > The fact that the request is never sent means the could be fake or real. The use of this special syntax will teach Windows to use lower priority DNS servers for requests for foobar.com and not to waste time trying the *DNS Server* configured in Appgate SDP. The can be left out of the special syntax: `dns.server.1.2.3.4.nxdomain ` - this setting means the driver will return NXDOMAIN for all domains (which on its own is not very useful). This option can be combined with the syntax explained earlier: `dns.server.10.11.12.13.foo.comdns.server.10.11.12.113.bar.foo.comdns.server.1.2.3.4.nxdomain ` - this setting means the driver will immediately return NXDOMAIN for all domains that have not already been matched with any earlier domain matches for foo.com and bar.foo.com The use of this special syntax will teach Windows to use lower priority DNS servers for all requests apart from those explicitly specified, avoiding the wait time for a reply. Appgate SDP (Software Defined Perimeter) is a security solution that provides secure access to resources based on user identity and context, leveraging a zero trust security model. A defined access right or permission granted to users or devices, allowing them to access specific resources or functionalities within the Appgate ZTNA system. A Policy is a set of rules that govern access control and permissions for users and devices within the Appgate ZTNA system. Policies determine what resources users can access based on their entitlements. An appliance that acts as an enforcement point, controlling user access to protected resources. A web-based interface that allows users to access resources without requiring a standalone Client. It serves as a reverse proxy for user traffic.