Feature request: operator-managed DNS resolver admission for Kubernetes guests

Context

The existing behavior is understood: a caller can explicitly add the DNS server IP to allow_out when creating a sandbox.

This issue asks how Kubernetes deployments should model the same decision at the operator/platform layer. In many clusters, the guest DNS resolver is a private Kubernetes Service address configured by the Cubelet/chart. Application callers should not need to discover or hard-code that environment-specific resolver address in every sandbox request.

The immediate requirement is basic guest DNS connectivity for workloads that need to reach internal services and external endpoints. It does not require CubeVS to be the only egress security control; deployments may combine it with egress gateways, service mesh, VPC/firewall controls, or application policy.

Current Behavior And Observation

• A guest configured with a private Kubernetes DNS Service address cannot resolve names under an IP-only or otherwise strict policy unless that resolver CIDR is explicitly in allow_out.
• Adding the resolver /32 explicitly makes the same guest DNS and subsequent network path work.
• This indicates a policy-admission issue at the guest-to-resolver hop, rather than a Kubernetes Service, UDP NAT, or return-path incompatibility.

Desired Operator Experience

A Kubernetes operator should be able to make an explicit deployment-level choice such as:

cubeNode:
  dns:
    sandbox:
      nameservers:
        - <cluster resolver>
      autoAllowDefaultResolvers: true

Desired semantics:

1. Default is disabled, preserving the existing allow_out contract.
2. When enabled, only resolvers configured by the operator and actually used by the guest are admitted automatically.
3. A per-sandbox dns_config.servers override must not itself create an implicit network exception.
4. The decision must survive a sandbox network-policy update.
5. Application callers do not need to carry resolver topology in their requests.

Important Limitation

Current allow_out is CIDR-granular. Admitting a resolver /32 permits all ports to that IP, not only UDP/TCP 53. Therefore any near-term feature should be clearly operator-controlled and disabled by default. A future port-aware policy representation could make this DNS-only.

Questions

1. Is an operator-controlled resolver-admission setting an acceptable Kubernetes integration feature, or is there an existing recommended chart/template mechanism that should be used instead?
2. If this belongs in CubeSandbox, should it be a boolean that uses the configured default resolver list, or an explicit operator allow-list of resolver IPs?
3. Where should the setting live: Helm chart values, Cubelet dynamic configuration, or another component?
4. Are there compatibility concerns around template creation, policy updates, or custom guest DNS that this proposal should account for?

Related PR: #1741. We can narrow or rework that implementation based on the design outcome here.