bitflicker64 commented on issue #3124:
URL: https://github.com/apache/hugegraph/issues/3124#issuecomment-5117477719
Adding measured data to supplement the specification references above, plus
two practical notes for anyone reproducing this.
### Measured TTL behavior
Run inside the Server image's JDK (Temurin 11), reading
`sun.net.InetAddressCachePolicy.get()`:
| Condition | Effective positive DNS TTL |
|---|---|
| No SecurityManager, no flag | `30` |
| **SecurityManager, no flag** | **`-1` (cache forever)** |
| SecurityManager + `-Dsun.net.inetaddr.ttl=30` | `30` |
| SecurityManager + `-Dnetworkaddress.cache.ttl=30` | **`-1` (unchanged)** |
The last row is worth calling out explicitly, because it is an easy trap
when testing the workaround. `networkaddress.cache.ttl` is a **security**
property, not a system property — passing it as `-D` on the command line has no
effect. Only `-Dsun.net.inetaddr.ttl` works from the command line;
`networkaddress.cache.ttl` has to go in a security properties file (e.g. via
`-Djava.security.properties=`) or the JDK's `conf/security/java.security`.
### Precedence between the two mechanisms
Since the suggested fix mentions both, their interaction matters. Measured
with `networkaddress.cache.ttl=60` in a security properties file **and**
`-Dsun.net.inetaddr.ttl=30` on the command line, the effective TTL is **60** —
the security property wins.
That is the desirable outcome: once a finite TTL ships in the distribution,
any `-D` workaround an operator has already deployed becomes a harmless no-op
rather than a conflicting setting.
### Note on reproduction step 6
Step 6 ("Confirm the Store DNS name and port are reachable from the Server
pod") is expected to **succeed** while the bug is active, and it does not
disprove the diagnosis.
A shell-based probe — `curl`, `nc`, `/dev/tcp` — runs in a separate process
with its own resolver state, so it resolves the name fresh and connects to the
new pod successfully. It never exercises the Server JVM's `InetAddress` cache,
which is the thing that is stale. I initially took a successful probe as
evidence that the transport layer was healthy and the fault lay elsewhere; it
is not evidence of that either way.
### Scope beyond Kubernetes
The title says Kubernetes because that is where this was observed, but the
actual precondition is narrower and not Kubernetes-specific:
1. a hostname that stays constant,
2. whose address changes, and
3. a long-running JVM that had already resolved it successfully.
Kubernetes hits all three routinely because a replaced pod is a new pod at a
new IP behind the same StatefulSet DNS name. Any deployment where an address
moves behind a stable name — DNS-based failover, container recreation that does
not preserve the IP — meets the same conditions. Deployments with genuinely
fixed addresses are unaffected.
### On the security trade-off
Worth stating plainly since the JDK's infinite default is deliberate: it
exists to limit DNS rebinding after an initial trusted resolution, so
shortening it is not a no-op in security terms.
The argument for shortening it here is that `HugeSecurityManager` is
installed to sandbox Gremlin script execution, and the DNS cache policy is an
incidental side effect of installing any SecurityManager rather than a
considered choice — nothing in the codebase or docs references it. HugeGraph
also resolves Store addresses from PD metadata rather than from untrusted
input, and `30` is the JDK's own default whenever no SecurityManager is
present. The negative-lookup TTL is a separate setting and would be untouched.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
