CentOS 8's systemd-resolved resolv.conf symlink: mixed resolver behavior and TLS trust mismatches

Goal

On CentOS 8, systemd-resolved is active by default and manages /etc/resolv.conf as a symlink to /run/systemd/resolve/stub-resolv.conf, with the stub listener on 127.0.0.53. I need a reliable way to troubleshoot name resolution and TLS certificate validation across tools that may not all consult the same resolver path.

Constraints and uncertainty

Some utilities read /etc/resolv.conf directly and may only see updates after the symlink target is refreshed, while glibc-based applications go through systemd-resolved immediately. NetworkManager restarts of systemd-resolved may also leave stale cache entries in place until expiry or manual clearing. Separately, certificate validation uses the system trust store maintained by update-ca-trust and p11-kit, but Java applications may still default to their own legacy cacerts file, so a hostname that resolves correctly can still fail TLS verification against a different trust anchor set.

Questions

1. How can I determine, per application, whether resolution is going through systemd-resolved or bypassing it, so contradictory results between tools can be explained?
2. After a NetworkManager-triggered resolver restart, what is the supported way to confirm whether cached DNS entries are stale before suspecting upstream DNS?
3. When a TLS handshake fails only in a Java application, how should I verify which trust bundle it actually uses compared to the output of update-ca-trust extract?