Streaming connection crashes on reverse DNS lookup of Kubernetes Pod IPs

[kabasm]

Description

When running featbit-agent inside Kubernetes, the agent intermittently logs the following exception during streaming connection processing:

fail: Streaming.Connections.ConnectionContext[2]
      Failed to resolve host for IP address: ::ffff:10.244.0.11.
      System.Net.Sockets.SocketException (00000005, 0xFFFDFFFF): Name or service not known
         at System.Net.Dns.GetHostEntryOrAddressesCore(IPAddress address, Boolean justAddresses, AddressFamily addressFamily, Nullable`1 startingTimestamp)
         at System.Net.Dns.<>c.<GetHostEntryOrAddressesCoreAsync>b__33_1(Object s, Int64 startingTimestamp)
         at System.Net.Dns.<>c__DisplayClass39_0`1.<RunAsync>b__0(Task <p0>, Object <p1>)
      --- End of stack trace from previous location ---
         at Streaming.Connections.DefaultConnectionContext.<>c__DisplayClass37_0.<<PrepareForProcessingAsync>g__GetHostAsync|3>d.MoveNext()

The problematic IP addresses are Kubernetes Pod IPs, for example:

::ffff:10.244.0.11

which corresponds to:

10.244.0.11

(an IPv4-mapped IPv6 address).

---

Environment

• Kubernetes cluster
• featbit-agent
• Pod networking with internal Pod CIDR (10.x.x.x)
• CoreDNS
• .NET runtime inside container

---

Expected behavior

The agent should continue processing streaming connections even if reverse DNS lookup for a client IP fails.

Missing PTR/reverse DNS records for Kubernetes Pod IPs is a normal situation in many Kubernetes environments.

---

Actual behavior

The agent attempts to resolve a hostname from the client IP address and logs an exception:

Name or service not known

In our environment this appears to disrupt streaming connection handling.

---

Possible root cause

It looks like the streaming connection code performs reverse DNS lookup via:

Dns.GetHostEntry(...)

or similar API calls.

In Kubernetes, Pod IPs typically do not have guaranteed reverse DNS (PTR) records unless explicitly configured.

As a result, reverse lookups for Pod IPs may legitimately fail with:

SocketException: Name or service not known

This should probably be treated as a non-fatal condition.

---

Suggested fix

Wrap reverse DNS resolution in try/catch and fall back to the raw IP address if hostname resolution fails.

Pseudo-example:

string host;

try
{
    host = (await Dns.GetHostEntryAsync(ip)).HostName;
}
catch
{
    host = ip.ToString();
}

Alternatively, make reverse DNS resolution optional/configurable.

---

Additional notes

This issue is reproducible only in Kubernetes environments.

The following commands inside the cluster demonstrate the missing reverse DNS entry:

dig -x 10.244.0.11
nslookup 10.244.0.11
getent hosts 10.244.0.11

which return NXDOMAIN / no result.

This is expected Kubernetes/CoreDNS behavior for many cluster configurations.