DNS use

Access Gateway use Domain Name Services (DNS) to resolve application requests to their corresponding application servers.

Access Gateway acts as a reverse proxy, sitting between clients and web servers. Access Gateway intercepts requests from clients and forwards the requests to back-end web servers.

Access Gateway resolves public addresses (external) and addresses behind firewalls (internal). Access Gateway may share hostnames with application servers as part of its role as a reverse proxy. When Access Gateway receives an external request to an application, it reverse proxies the request to the internal application server.

The following DNS architecture diagram represents this using:

• app-external.mysite.mycompany.com: The name used by end users to access the application. DNS resolves this name to the Access Gateway instance. This name can be the same name used internally for the app.
• app-internal: This represents the protected web application (for example, the internal Peoplesoft application described earlier).
• In this example, Access Gateway and the external application resolve to the same IP address.

The following sections describe how Access Gateway uses IP addresses.

External DNS entries (also referred to as public or customer-facing DNS entries) represent the URLs that customers use to access applications (for example, peoplesoft.mysite.company.com).

External DNS entries:

• Are defined in public DNS and are resolvable by anyone.
• Must be resolvable by Access Gateway.
• Are represented in the preceding diagram by app-external[.mysite.company.com].
• Resolve to the IP address of Access Gateway, or a load balancer.
• Are defined in applications by the Access Gateway Public Domain application field.

Internal DNS entries are private entries that represent the back-end applications being protected by Access Gateway.

Internal DNS entries:

• Are defined in a private DNS and can typically only be resolved behind an organization's firewall.
• Must be resolvable by Access Gateway.
• Are represented in the preceding diagram by app-internal*.
• Are defined in applications by the Access Gateway Protected Web Resource application field.

A third class of entries are reserved DNS names. These are represented in the architecture diagram by the following entries:

• /etc/hosts:admin: This represents an entry in your local hosts file. This entry is required for initial configuration of Access Gateway and can be ignored or removed once initial deployment is complete. See Add an admin entry to the hosts file.
• /etc/hosts:header represents a set of entries primarily used for testing and development. For example when creating a sample header application for testing. Other examples might be proxy, policy or other test entries. These entries are typically ignored or discarded when moving from development to test or production.
• DNS:gw-admin[.mysite.company.com] represents the name of the Access Gateway administration instance and points to the IP address of the Access Gateway.
• DNS:gw.[mysite.mycompany.com] must exist and point to the same IP address as gw-admin[.mysite.company.com]. Used by the admin GUI service to route configuration requests.

In high availability clusters, there may be additional DNS entries for the member nodes of the cluster, such as node1, node2, and so on.

The architecture diagram doesn't include entries for company.okta.com or company.oktapreview.com. These are used by Access Gateway when configuring an identity provider (IdP).

DNS entries and record types

DNS supports two record types, A and CNAME:

• A records map a name to one or more IP addresses when the addresses are known and stable.
• CNAME records map one name to another name.

Typically Access Gateway would use an A record for gateway addresses such as gw-admin.[mysite.company.com] and CNAME records, pointing to the gateway address for all external (app-external*[.mysite.company.com]) addresses.