Basic BCP 38 support

[zbalkan]

tl;dr: Moved RRL to a separate PR from #1737. It means this PR depends on it and TechnitiumSoftware/TechnitiumLibrary#56.

UDP DNS Response Rate Limiting

Problem

The Cookie admission limiter is keyed on the source and runs before the query, so it cannot distinguish a cheap NXDOMAIN from a large signed answer. A source staying under its admission budget can still pick the responses with the best amplification ratio, and repetition - the actual signature of a reflection flood - is invisible to a limiter that counts requests rather than what they produce.

Solution

A second limiter on the finished UDP response, immediately before transmission, keyed on (client network, response identity). Responses are grouped so repetition shows up even when queries differ:

Response	Class	Keyed on
NXDOMAIN	NxDomain	question name, type zeroed
Other non-NOERROR	Error	question name and type
NOERROR, no answer, NS in authority	Referral	delegation owner name
NOERROR, no answer	NoData	question name, type zeroed
Wildcard RRSIG in answer	Query	signer's name
Anything else	Query	question name and type

Zeroing the type collapses a type-sweep of one name; keying on the delegation owner collapses a random-subdomain flood. Each response is also checked against an All bucket, so spreading across classes is still bounded; the stricter result wins.

Disabled by default. When enabled: 100 responses/second sustained, 200 instant, slip every 2, 65536 entries, empty bypass list. Clients tracked at /32 and /24, /128, /64 and /56.

Decisions

• Separate from the Cookie limiter. Different key, sizing and lifecycle; they share only AddressPrefix and SipHash24. Merging them would couple the two features for no behavioural gain.
• The valid-Cookie exemption is the only Cookie link, through this PR's own DnsResponseRrlRequestTrust enum. The limiter files name no Cookie type; the single mapping happens at the call site.
• Synthetic responses are exempt. Admission slips, BADCOOKIE and QPM truncations are signals the server chose to emit; counting them would let the Cookie bootstrap path exhaust the budget protecting it.
• Slip is class-restricted. Errors are dropped rather than truncated — a truncated error is not a useful retry signal, and TC would be the amplification this exists to prevent.
• Errors get a small leak (4096 entries, 1/s) so a client with a malformed query still learns why, counted separately.
• Settings publish as immutable generations with one Volatile.Write; the previous generation survives a failed rebuild, and history is preserved unless the change actually invalidates it.
• The bypass list is scanned directly, matching the QPM bypass list on the same path. It is capped at 255 entries. An earlier revision compiled it into binary tries; that is now proposed separately for TechnitiumLibrary.Net.
• Config appends after the Cookie suffix. Layering is strict - master ⊂ Cookies ⊂ this PR - with end-of-stream guards, so no migration.

No existing API changes: public signatures, properties, HTTP endpoints and settings fields were diffed against master, none removed or altered.

Testing

DnsServerCore and DnsServerApp build clean. The solution build fails on DnsServerSystemTrayApp on Linux, pre-existing and unrelated.

There is no test project in the repository, so nothing covers class assignment, slip eligibility, the error leak, the Cookie exemption, or preserve-vs-rebuild on settings changes. That is the main gap for review, along with BuildResponseIdentity, where wrong grouping is either a bypass or a false positive on legitimate traffic.

[ShreyasZare]

Thanks for the PR. This will require studying things in details which will take a lot of time. Support for DNS cookies is not immediately planned as there are several other things that are planned to be implemented before it. Thus, I am not sure when I can take look at this topic and come back to this PR.

[zbalkan]

Thanks for the information. Since I incidentally built response rate limiting during DNS cookie development, and then split it, they are decoupled. If you believe it's valuable regardless of cookies, I can try to work on it as a totally separate feature, but it will take time.