The Okta Access Gateway(OAG) uses the okta-unbound service that does DNS caching. If OAG fails to resolve the protected URL, users will get a resolution error while accessing the resource. The issue can also happen intermittently because of caching and DNS records. This article provides steps on how to rule out a potential resolution error. 

• Okta Access Gateway(OAG)
• DNS
• Okta-unbound

How okta-unbound (OAG DNS) service works?

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 loopback interface.

When resolution needs to be done, the request will be sent to 127.0.0.1, i.e., 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, then 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"

Please follow the below steps 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

     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 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

   • 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 from the OAG appliance and no issues were noticed with the configured DNS servers.