How to Test Okta Access Gateway DNS and Understanding the Unbound Service

The Okta Access Gateway(OAG) uses the Okta-unbound service that does Domain Name System (DNS) caching. If OAG fails to resolve the protected URL, users will get a resolution error while accessing the resource.

Application is not resolvable in DNS

Application <app name> is. no longer accessible. This failure has been logged. Please contact your administrator or helpdesk.

The issue can also occur intermittently due to caching and DNS records. This article provides steps on how to rule out a potential resolution error.

• Okta Access Gateway(OAG)
• Domain Name System (DNS)
• Okta-Unbound
• Okta Classic Engine
• Okta Identity Engine (OIE)

How does the Okta-unbound (OAG DNS) service work?

The Okta-unbound service is responsible for the DNS queries and also does caching. The /etc/resolv.conf has the loopback, 127.0.0.1, IP because the Okta-unbound service is listening on the loopback interface.

When resolution needs to be done, the request will be sent to 127.0.0.1, that is, the Okta-unbound service. If the record is not in the cache, Okta-unbound will send a query to any of the forward-addr (DNS servers ) configured in /opt/oag/unbound/conf/unbound.conf. If the record is in the cache, then no DNS query will be sent to the configured DNS servers.

If the resolution fails at some point, a spoof address, 0.0.0.2, will be assigned. This has been set through the dns_fallback script, as shown below:

/opt/oag/unbound/scripts/dns_fallback.py:SPOOF_ADDR = "0.0.0.2"

Follow the steps below to test OAG DNS:

1. The following commands can be used to get a list of configured DNS servers:

   sudo awk '/forward-addr:/ {print $2}' /opt/oag/unbound/conf/unbound.conf

   cat /etc/dns_servers.conf

2. Using the configured DNS servers, resolution can be checked through the dig command using the following loop with all DNS servers:

   for ip in {<enter-dns-IPs-in-comma-separated-value-format>}; do echo $ip; dig +noall +answer @$ip <target-hostname>; echo “==========“; echo; done

    NOTE: If the loop shows there is an issue with a particular DNS server, then running just "dig @<dns ip> <target hostname>"  against that specific DNS server will provide more detail.

3. Another test can be done through the host command in a loop, as shown below. This will try to resolve the target-hostname every second. Use CTRL+c to cancel the loop.

   while true; do host <target-hostname>; sleep 1; done

NOTE: If there is an intermittent issue noticed with the while loop, then it could be because of a missing mx record.

• • The following command can be used to check if the mx record has been set:

    nslookup
    
    > set type=mx 
    > target-hostname

Please create a support case if further troubleshooting is required on the OAG appliance and no issues were observed with the configured DNS servers.