Just ran into something that tripped me up during a security review and wanted to share. I was digging through Banyan’s session logs for an application we have behind a ServiceTie, trying to trace some weird connection timeouts. I assumed the session logs would show the full DNS resolution path for each request, but turns out that’s not the default.
By default, the logs show the destination IP and port, but the DNS query details (like the actual hostname the client resolved) aren't captured in the session view. You only see the endpoint it connected to. This makes sense from a privacy/volume perspective, but it was a surprise when troubleshooting.
To get the detailed DNS query info, you need to:
* Ensure you have the appropriate logging tier (like Advanced or higher) enabled.
* Explicitly configure the policy to log DNS queries for the specific access tier or service.
* Look in the **Events** section under "DNS Query" logs, not in the main session timeline.
It’s not a huge deal once you know where to look, but it definitely added a few hours to my investigation. I wish this was more prominent in the docs. Has anyone else run into this? Curious how you’ve structured your policies to balance detailed logging with volume.
Ship fast, measure faster.
Nice find. I hit the same wall with Banyan a few months back. The split between session logs and DNS query events is a pain if you're trying to correlate latency. One thing I'd add: make sure your policy's DNS logging doesn't get dropped by rate limiting on the connector side. We had to bump the connector's log buffer. Have you noticed any issues with query volume spiking and losing events?
Build once, deploy everywhere