DNS Security and Domain Infrastructure Integrity

C H A P T E R 0 4 Keep large answers working without fragmentation DNS over UDP is efficient, but large responses can exceed a path's usable packet size. EDNS lets a requester advertise capacity; that advertisement does not guarantee that every network path can carry a datagram of that size. Fragment loss, filtering and implementation differences can turn large signed responses into intermittent failures. RFC 9715 describes fragmentation avoidance, including response sizing and transport fallback. [S10] The often-used 1232-byte UDP payload budget derives from the IPv6 minimum MTU of 1280 bytes minus a 40-byte IPv6 header and an 8-byte UDP header, before additional encapsulation. It is a useful conservative reference, not proof that every tunneled path has the same usable budget. Truncation must lead somewhere When a response cannot fit, the server can indicate truncation and the client can retry over TCP. DNS implementations need working TCP support; blocking TCP port 53 because “DNS uses UDP” breaks legitimate operation. RFC 7766 covers the transport requirements and connection considerations. [S11] FIGURE 03 / TRANSPORT FALLBACK A small UDP reply can direct a larger TCP exchange UDP query Advertised capacity and path constraints Responder Fits the answer or marks truncation ↓ Fallback is part of normal DNS service ↓ TCP retry Allowed through firewalls and load balancers Complete answer Validated and cached under normal rules Test large signed answers, not only small address lookups. A healthy UDP probe does not demonstrate that DNSSEC key responses or rollover traffic will work. DNS Security & Domain Integrity SECURITY FIELD GUIDES aisecurityinterviews.com / field guides 10

C H A P T E R 0 7 Plan key changes from dependencies and cache lifetimes A key rollover is a sequence of publications that must remain valid for clients holding different cache states. The objective is to avoid a period in which an old cached key cannot validate a new signature, or a cached parent DS refers only to a key the child no longer serves. RFC 7583 describes the timing dependencies that make this more than a local key replacement. [S08] Separate key generation, publication, activation, retirement and removal. A key can be published before it signs data. A retired key may need to remain available while cached signatures or parent information still refer to it. An implementation's automation should expose these states and their evidence rather than hiding them behind a single “rotate” button. Build the overlap deliberately For a simplified signing-key transition, publish the new verification material, allow relevant caches to learn it, start using the new signing path and retain old material until old dependent data can expire. Key-signing changes additionally involve the parent DS publication and its cache lifetime. Algorithm changes can require broader overlap because validators must find a complete supported path through the transition. FIGURE 06 / ROLLOVER DEPENDENCIES Remove old evidence only after its dependents expire Publish new key Verify every authority serves the intended key set Establish trust Parent publication and cache propagation ↓ Advance on verified conditions, not a guessed sleep ↓ Activate new path Validate from independent resolver views Retire old path Wait for dependent signatures and caches A key tag match alone cannot establish that all signers hold the same key. This is a dependency model. Exact timing and sequence depend on rollover method, signer and parent automation. DNS Security & Domain Integrity SECURITY FIELD GUIDES aisecurityinterviews.com / field guides 16

C H A P T E R 1 2 Publish protective DNS policy like application code Protective DNS applies a local decision to a name-resolution request or response. It can block known harmful destinations, enforce an approved namespace policy or route selected queries to controlled handling. Its effectiveness depends on clients using the service and on the policy's coverage. It cannot prove that an allowed destination is benign or stop every connection made without a DNS lookup. Treat policy feeds as untrusted inputs to a controlled publication pipeline. Normalize records, validate scope, attach evidence and expiry, detect conflicts and test candidate changes before broad rollout. A mistaken block on an identity provider or package service can interrupt many applications at once. Separate evidence from enforcement A reputation score is evidence. The policy compiler turns evidence and organizational rules into an action. Keep that decision inspectable: source, reason, scope, creation time, expiry, exception and owner. Avoid importing every feed's most severe label directly into a permanent block. Different sources have different coverage and false-positive patterns. FIGURE 09 / POLICY RELEASE A feed update becomes a reviewed resolver decision Evidence inputs Indicators, local observations and analyst review Policy compiler Normalize, expire, deduplicate and resolve conflicts ↓ Advance on measured behavior ↓ Canary resolvers Measure expected blocks and business failures Fleet release Versioned rollout with rapid rollback Every block needs an explanation and every exception needs a lifetime. Publication version and resolver adoption time make policy propagation observable. DNS Security & Domain Integrity SECURITY FIELD GUIDES aisecurityinterviews.com / field guides 26