Map DNS packet, server, and data threats to the protection each needs
TSIG can authenticate a dynamic-update client to a server, but it protects the transaction rather than the updated zone data seen by resolvers.
Read the checklistDSE security knowledge hubCybersecurity
Cybersecurity
Knowledge
Page 127 of the DSE Cybersecurity knowledge center, with source-backed guidance and practical next steps.
DSE-authoredOfficial sourcesReviewed guidance
Search the library Explore this topic
Start with the cornerstone guide Cybersecurity knowledge center
Source-backed guidance for identity, vulnerability reduction, ransomware readiness, detection, response, and recovery.
DSE post stream
1,892 articlesCybersecurity
Match replies to outstanding DNS queries before accepting an answer
Before accepting a DNS reply, a resolver must match its addresses, destination port, query ID, query name, query class, and query type to the outstanding query.
Read the explainer
Negotiate EDNS UDP size and extended fields through the OPT pseudo-record
EDNS uses an OPT pseudo-record to carry the sender’s UDP payload size plus extended response-code, version, flag, and option fields. A requestor advertises the maximum UDP payload it can reassemble in the OPT CLASS field, and responders must limit replies to that advertised size.
Read the guide
Place authoritative DNS secondaries across independent failure domains
Authoritative secondary servers must be geographically dispersed and connected through diverse network paths so one failure cannot isolate all servers. Placing every authoritative server on one LAN, in one room, or in one building defeats most of the resilience gained from multiple servers.
Read the playbook
Preserve unknown DNS record types through generic presentation syntax
The generic master-file form for an unknown RR type uses a type code and a length-prefixed hexadecimal representation of its RDATA. DNS servers and resolvers must handle unknown RR types transparently without requiring type-specific RDATA knowledge.
Read the briefing
Publish AAAA and IP6.ARPA data as separate forward and reverse decisions
An AAAA record stores one 128-bit IPv6 address in network byte order for its owner name. An AAAA query returns the IPv6 address records associated with the queried name; it does not perform reverse mapping.
Read the checklist
Rank DNS data credibility before caching conflicting answers
A server must not merge response records with cached records to construct one RRset; it retains one complete set and ignores or replaces the other. Primary-zone and transferred-zone data rank above authoritative answer data, which ranks above non-authoritative answers and additional information.
Read the explainer
Refuse to treat a DNS name as a stable or trustworthy identifier
Client and server protocol behavior should not change merely because of the other endpoint’s domain name. When a protocol offers capability negotiation, endpoints should negotiate supported features instead of inferring them from a domain name.
Read the guide
Reject authoritative implementations that mishandle AAAA query responses
For an existing name that has no AAAA record, an authoritative server should return NOERROR with an empty answer rather than NXDOMAIN. Returning NXDOMAIN to an AAAA query incorrectly asserts that the queried name does not exist, not merely that its AAAA record is absent.
Read the playbook
Request and interpret EDNS NSID without assigning it global semantics
A resolver requests server identification by sending an empty NSID option in an EDNS OPT record; request payload data is not allowed. An NSID request identifies only the server that directly receives it, so a recursive server does not transitively forward the client’s request semantics.
Read the briefing