Admins set access rules by defining entitlements, which include actions. Within an action, host(s) can be defined by IP addresses, subnets, hostnames, URLs, resource names (cloud resolvers), and host entitlement scripts. Resource names and entitlement scripts support the dynamic least privilege access mode, which is a key part of the product. These extend the capabilities of the system, allowing it to adapt in near real time to changes in the infrastructure.
Name resolvers provide support for various types of cloud resolver (azure://vnet:<NAME>) as well as hostname resolution (idns://crm.internal.my_company.com).
Sites include numerous name resolution options to allow the system to derive IP addresses from all the host definitions mentioned above.
DNS in Appgate SDP
Appliances
Appliances need access to the DNS server(s) to find other servers, such as Gateways looking for the Controllers, Controllers looking for LDAP, etc. This is configured when creating a new Appliance in the System Settings tab. Appgate SDP appliances are also DNS servers in their own right as they run the Go based CoreDNS. The appliance setting is actually configuring a CoreDNS virtual server, which it will then use as a proxy when trying to resolve hosts.
Gateways
Gateways need access to the DNS server(s) to resolve all the users' . This is set up by configuring a DNS resolver for the Site where the DNS servers are located. Just like the appliance, this will utilize one or more CoreDNS virtual server(s). Effectively you are setting up two things; the resolver which will speak to a coreDNS instance, and the coreDNS instance which will use the same (internal) DNS server(s) as the appliances on that Site.
To allow a Gateway to resolve all the users' Entitlements out of the box, a limited default DNS resolver is included which will use the Gateway appliance's DNS server settings. This will handle all hostnames without matching domains from the other DNS Resolvers.
There is an option for Zone transfers (to Gateway) when configuring a new DNS resolver. Zone transfers are a standard DNS feature in which a DNS server delegates part of its workload to another that is better placed to service requests for that specific zone. In the case of the DNS resolver, the Match Domains defined are also used to set the zones for CoreDNS. Zone transfers are useful in this case as Gateways can make a lot of DNS requests, and these will then in effect now be internal to the Gateway.
If the DNS Server does not respond when coreDNS is starting up, a zone transfer request will be retried every 10 seconds until it succeeds. When it has succeeded, the SOA record from the DNS Server will set the refresh interval (typically 12-24 hours). If a zone transfer subsequently fails, coreDNS will continue to serve DNS requests from its cache. This should improve reliability when there are network issues or when the DNS Server is temporarily unavailable.
There is also an option when using the DNS resolver to enable or disable AAAA lookups. If you don't need these, disable AAAA lookups. There is no option for this in the DNS forwarder as it just does what the Client asks it to do, so if you don't need these you should take steps to stop devices and apps asking for AAAA lookups.
Portal
Portal users have a specific problem in respect of access to DNS server(s) to resolve Entitlements. User A might need access to a different DNS server from user B because they have a different DNS Policy. For this reason, the Portal appliance also uses CoreDNS virtual servers to ensure that users' DNS requests are forwarded to the appropriate DNS servers regardless of the appliance’s DNS server settings. The way the Portal operates adds some additional DNS requirements of its own.
Using Name Resolvers
Depending on how you define your host(s), you may use different host definitions for each Site. If you are targeting cloud-based protected hosts, then you could consider using cloud based resource names which will return IP addresses directly without the need for DNS. Are you resolving static internal hostnames or the dynamic public IPs used by a SaaS provider? To understand all the options that Appgate SDP offers, see Defining Hosts.
Ensure that the Client DNS settings on the user's device are ready for when the user attempts to access a (protected) host. This will use the same internal DNS server as the Site DNS resolver. This can be done automatically for you by checking the Enable auto-configuration box when configuring the Site's DNS resolver.