Added support for DNS cookies (RFC 7873/9018, and partially BCP 38)

[zbalkan]

Adds DNS Cookies support across DnsServer with EDNS(0) COOKIE parsing, server-side cookie generation/validation, and request/response handling per RFC 7873/9018.

• EDNS COOKIE parsing/serialization (code 10) via EDnsCookieOptionData; 8-byte client cookie; 8–32-byte server cookie.
• DnsCookieSecretManager for secrets with persistence and rotation.
• DnsCookieValidator builds v1 server cookies (version, timestamp, SipHash-2-4 with 1 hour past / 5 min future skew); server replies BADCOOKIE with TC and a fresh cookie on failure.
• Response path echoes/attaches server cookies when absent or forced and updates OPT safely.

Relies on PR TechnitiumSoftware/TechnitiumLibrary#56

Edit: Solves #1151

[Copilot]

Pull request overview

This pull request adds DNS Cookie support to the Technitium DNS Server, implementing RFC 7873 and RFC 9018 specifications. The implementation includes EDNS(0) COOKIE option parsing, server-side cookie generation and validation using HMAC-SHA256, secret management with automatic rotation, and appropriate request/response handling with BADCOOKIE responses.

Changes:

• Added DnsCookieSecretManager class for managing 32-byte HMAC secrets with file persistence and automatic rotation
• Added DnsCookieValidator class for generating and validating DNS cookies using RFC 9018 server cookie structure (version 1 with timestamp and HMAC-SHA256-64)
• Integrated DNS cookie validation and response handling into DnsServer with configuration options for enabling cookies, secret file path, rotation period, TC-on-bad-cookie behavior, and always-echo mode

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 19 comments.

File	Description
DnsServerCore/Dns/Security/DnsCookieSecretManager.cs	Manages cryptographic secrets for DNS cookies with persistence, rotation, and thread-safe access
DnsServerCore/Dns/Security/DnsCookieValidator.cs	Implements RFC 9018 server cookie generation and validation with timestamp and HMAC verification
DnsServerCore/Dns/DnsServer.cs	Integrates DNS cookie support with request validation, BADCOOKIE response generation, and configuration management

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 8 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 7 comments.

Comments suppressed due to low confidence (1)

DnsServerCore/Dns/DnsServer.cs:593

• DNS cookies are not initialized when LoadConfigFile encounters an exception other than FileNotFoundException (caught at line 589). This means if the config file exists but is corrupt or causes any error during ReadConfigFrom, DNS cookies will not be available. Consider calling InitDnsCookies() in the catch block at line 589 to ensure DNS cookies are initialized even when config loading fails, similar to how it's called in the FileNotFoundException handler at line 587.

            catch (Exception ex)
            {
                _log.Write("DNS Server encountered an error while loading DNS config file: " + dnsConfigFile + "\r\n" + ex.ToString());
                _log.Write("Note: You may try deleting the DNS config file to fix this issue. However, you will lose DNS settings but, other data wont be affected.");
            }

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[zbalkan]

I'll roll back last two commits. I shouldn't blindly listen to the copilot review. Original code was okay. But tomorrow.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[zbalkan]

Ready.

[zbalkan]

BTW, this is the first iteration of the progress. The next step is to add another rate-limiter making use of DNS cookies. The flow would be:

• If there is no valid cookie for N amount of queries, escalate to DNS-over-TCP
• If there are valid UDP cookies, proceed with DNS-over-UDP.

[zbalkan]

After 2 months, I finally found time to work on where I've left. Now, blocking traffic based on DNS query BADCOOKIE event has become another rate limiter. It can be enabled/disabled by a checkbox under Settings>General tab. The other values are hardcoded. The idea is to minimize the workload under a DDoS by responding queries with bad cookies ASAP with a truncate message, and beyond a threshold, dropping them altogether with no response. Blocking must be cheaper than resolving for this to work as intended.

[zbalkan]

At commit 89c59e732c8e6d3d76c0e867ef8cf47222120e86, here's the status.

Category	Added lines	Percentage
Whitespace-only	622	14.32%
Comments	546	12.57%
Actual code/content	3,175	73.11%
Total additions	4,343	100%

I took another look at whether DNS Cookies and RRL / early UDP reflection limiting can be split into two completely independent PRs. I think this should be a stacked Part I / Part II series, rather than two unrelated PRs targeting master.

DNS Cookies and RRL are separate features at the configuration level, as they are in other implementations. Once both are enabled, though, their behavior is intentionally combined. A valid Server Cookie is a trust signal for response rate limiting, and the early reflection limiter can use cookie state to send a useful recovery response. BIND and Knot DNS follow the same general approach: Cookies and RRL are exposed separately, but valid-cookie UDP traffic is exempt from RRL when both are enabled. The relevant standards also allow Cookies to be deployed independently. Their interaction with RRL is an implementation policy, not a protocol requirement.

Two unrelated PRs would leave us with an awkward sequencing problem. We would either temporarily lose the valid-cookie exemption and cookie-aware recovery behavior, or add a third PR later to restore the intended combined policy. Neither makes the change easier to follow. I therefore suggest the following split:

1. Part I: DNS Cookies. This covers RFC 7873/9018 protocol handling, validation, secret lifecycle and rotation, cluster handling, and the cookie-management surface.

2. Part II: UDP response RRL and early reflection limiting. This covers the limiter engines and their configuration and UI, plus the two small integration points that use cookie classification to apply the final combined policy.

This still gives us two smaller changes that can be reviewed separately, while making the dependency explicit and preserving the behavior we intend to ship. For a change set of roughly 4k LOC, that should make the individual concerns easier to reason about, test, and review without suggesting that the final security policy has no relationship between them.