Proposal of introducing new JFR events for DNS lookups

[hashjangcyber at gmail.com]

Hello,
I would like to start a discussion on introducing new JFR events for DNS lookups. While many lookups are DNS in cloud-native environments, the JDK uses the configured name service, so the event naming and semantics should not imply DNS-only behavior. I’m seeking feedback on scope, naming, and payload fields.
Motivation


• High-frequency, latency-sensitive lookups are critical for service discovery.

• Current gaps:
    • Cannot distinguish cache hits vs. network lookups

    • Hard to trace lookup latency and diagnose timeouts/failures

    • Concurrent libraries may cause redundant lookups

• Value:
    • End-to-end observability: lookup → socket connect → data transfer

    • Troubleshooting: identify timeouts, resolution failures

    • Performance: evaluate cache policies, detect hotspot names

    • Security: audit external domains accessed


Proposed event (initial draft)
Event name: jdk.DnsLookup
When: Emitted around DNS hostname resolution call boundaries, including:


• Actual network DNS queries (when cache is disabled or cache miss occurs)

• Cache hits (when result is retrieved from DNS cache)

• Stale data usage (when expired but still valid cached data is used)

• Background DNS cache refresh operations


Key fields (feedback welcome):


• host (String): The hostname being resolved

• result (String): Comma-separated list of resolved IP addresses, or error message if lookup failed

• success (boolean): Whether the DNS lookup was successful

• cached (boolean): Whether the result was retrieved from cache (true) or from actual DNS network query (false). This helps distinguish between three use cases:
    • Actual network queries (cached=false) - represents real DNS network traffic

    • Cache hits (cached=true, stale=false) - repeated lookups using fresh cached data

    • Stale data usage (cached=true, stale=true) - application continues with expired but still valid cached data when DNS refresh fails

• ttl (long, seconds): Time to live in seconds. Values:
    • 0 or -1: Not cached or forever cached

    • > 0: Actual remaining TTL if cached

• stale (boolean): Whether stale cached data was used (only valid when cached=true). Helps identify semi-error scenarios where DNS errors occur but application continues using stale cached records


Event name: jdk.DnsCacheStatistics
When: Periodic event emitted at configurable intervals (default: 5 seconds in default.jfc, 1 second in profile.jfc). This is a statistics event similar to jdk.ExceptionStatistics, providing aggregate metrics about the DNS cache state.
Key fields (feedback welcome):


• cacheSize (long): Current number of entries in the DNS cache. Useful for monitoring cache growth and understanding cache utilization patterns.

• staleEntries (long): Number of stale entries currently in the cache (entries that have expired but are still within the stale period). Helps identify how many entries are using stale data, which is important for understanding cache behavior in scenarios where DNS refresh fails.

• entriesRemoved (long): Number of entries that have been removed during cache cleanup operations. This metric tracks cache eviction and helps understand cache churn patterns, which is particularly useful in Kubernetes and cloud-native environments where DNS entries may change frequently.


Use cases:


• Monitoring DNS cache size growth over time

• Identifying cache cleanup frequency and patterns

• Understanding stale data usage in production environments

• Troubleshooting DNS-related performance issues in microservices architectures

• Observing cache behavior during DNS server failures or network partitions


Prototype/PR


• A preliminary PR is available for context and discussion:
    • https://git.openjdk.org/jdk/pull/28110

• I will update the design/implementation per feedback from this thread.


Thanks in advance for your feedback!
Best regards,
NeayGuyCoding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251113/62292a70/attachment-0001.htm>