What is the difference between conntrack-based NAT handling and NOTRACK for proxied DNS traffic?

Conntrack-based NAT records packet state and can short-circuit rule evaluation for later packets in the same flow. NOTRACK bypasses that state tracking for selected traffic, which avoids stale flow reuse and looping behavior in this kind of proxy path. The trade-off is a small performance cost in exchange for more deterministic packet handling.

Why conntrack-based NAT and NOTRACK behave differently for proxied DNS flows

Conntrack-based NAT and NOTRACK are solving different problems in the packet path. Conntrack gives the kernel state about a flow, which is useful when the same 5-tuple should be treated consistently across packets. NOTRACK intentionally removes that statefulness for selected traffic, which is often the safer choice when a proxy or local redirect must avoid replaying stale flow decisions.

The practical difference shows up in proxied DNS because DNS forwarding paths can reuse addresses and ports in ways that look repetitive to conntrack. When the kernel keeps matching later packets to an old tracked flow, packets may short-circuit into the wrong translation or loop back through the same decision path. NOTRACK reduces that coupling by forcing each packet to follow the intended rule path instead of inheriting an earlier state entry.

That means conntrack-based NAT is usually better when you want normal connection semantics and stateful translation, while NOTRACK is better when the proxy path itself should be treated as an exception to state tracking. For DNS proxying, the deciding question is not which mode is more advanced, but whether stable packet handling matters more than state reuse.

When stateful NAT is the wrong fit for a DNS proxy path

Stateful NAT depends on the assumption that packet flow identity is stable enough for a tracked entry to remain valid. Proxied DNS traffic can violate that assumption because the proxy may terminate, rewrite, or re-originate packets in a way that makes the apparent flow look similar even when the routing intent has changed. In those cases, state retention can preserve the wrong translation decision.

NOTRACK is useful when the proxy design already provides the necessary handling and the kernel should not try to preserve flow memory across packets. This is less about bypassing security and more about preventing a packet-processing optimization from becoming a logic error. The cost is that you give up some conntrack conveniences, including reuse of existing state for later packets in the same exchange.

For proxied DNS, that trade-off is usually acceptable because DNS packets are small, frequent, and sensitive to deterministic handling. A proxy path that depends on fresh rule evaluation can be easier to reason about than one that inherits a prior NAT decision that no longer reflects the actual route.

How to choose between conntrack and NOTRACK in practice

The right choice depends on whether the proxy path is state-dependent by design. If the packet must be translated consistently across a long-lived flow, conntrack-based NAT is appropriate. If the traffic is being deliberately redirected through a proxy that should not inherit stale translation state, NOTRACK is the cleaner fit.

For DNS, the most important operational clue is repeated or circular behavior. If a packet trace shows replies re-entering the same handling path or landing on an old flow decision, that is a sign the conntrack model is too sticky for the proxy design. In that case, reducing statefulness is often more reliable than trying to tune the same state table harder.

At scale, the difference is also about predictability. Conntrack adds memory and lookup overhead, but it can simplify ordinary forwarding. NOTRACK removes that overhead for the chosen traffic, but it puts more responsibility on the rule path and proxy behavior itself. For DNS proxying, deterministic packet processing is usually the stronger requirement.

Risk and Threat Considerations

Stateful packet tracking can create operational exposure when a proxy path is sensitive to stale translation state or flow reuse. In DNS proxying, that can cause misrouting, looping, or persistent handling errors that are hard to diagnose because the kernel appears to be “helping” by reusing prior decisions.

Failure mechanism: A conntrack entry remains valid longer than the proxy path expects, so later packets are matched to a prior NAT decision instead of being processed through the intended redirect or exception rule.

Impact: DNS traffic can loop, bypass the intended proxy treatment, or produce inconsistent resolution behavior that looks intermittent from the application side.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-12 — Network Infrastructure Management	Proxy and NAT handling are network infrastructure behaviors that need controlled change and validation.
Recommendation — Validate packet-path changes and review translation rules before deployment.
NIST CSF 2.0	PR.PS-04 — Platform security is managed, and security-relevant configuration changes are controlled.	Conntrack and NOTRACK are security-relevant configuration choices affecting packet handling.
Recommendation — Control and validate firewall and packet-filter configuration changes.
NIST SP 800-53 Rev 5	SC-7 — Boundary Protection	NAT and proxy routing are boundary-control mechanisms that shape traffic flow at network edges.
	CM-6 — Configuration Settings	Selecting NOTRACK versus stateful tracking is a configuration decision that affects packet processing.
Recommendation — Enforce boundary rules so proxied DNS traffic follows the intended path. Document and baseline packet-filter settings for proxy paths.
ISO/IEC 27001:2022	A.8.9 — Configuration management	The choice between conntrack and NOTRACK is a controlled configuration change with operational impact.
Recommendation — Review and approve packet-handling configuration changes before release.

Practitioner Guidance

What to verify: Confirm whether the DNS proxy is terminating, redirecting, or re-originating traffic in a way that makes flow state unreliable. If the handling path depends on packet-by-packet rule evaluation, NOTRACK is usually the more defensible choice.

Decision rule: If you see stale flow reuse, repeated redirects, or packets landing on the wrong translation path, treat that as a design mismatch rather than a tuning problem. Use conntrack only when preserving state is materially helpful to the proxy behavior.

Practitioner takeaway: For proxied DNS, the goal is not to eliminate state everywhere, but to remove state exactly where it creates non-deterministic packet handling.