Use fixed-time TSIG MAC comparison

[zbalkan]

What?

Replaces SequenceEqual with CryptographicOperations.FixedTimeEquals for all three TSIG MAC verification checks in TechnitiumLibrary.Net/Dns/DnsDatagram.cs:

• VerifySignedRequest (line ~1434)
• VerifySignedResponse (line ~1689)
• next-message verification in the multi-message TSIG chain (line ~1816)

No public API surface changed; method signatures, return values, and out-parameter semantics are identical.

Why?

SequenceEqual short-circuits on the first mismatched byte, so its execution time leaks information about how many leading bytes of an attacker-supplied MAC are correct. Over enough requests, that timing signal can be used to forge a valid TSIG MAC byte-by-byte instead of brute-forcing it in one shot, defeating the purpose of TSIG authentication for zone transfers and dynamic updates. CryptographicOperations.FixedTimeEquals is the BCL's constant-time comparison primitive designed for exactly this: comparing a computed secret/MAC against caller-supplied bytes without leaking timing.

How?

Straight one-line swap at each of the three call sites, plus a short comment explaining why fixed-time comparison is used. FixedTimeEquals returns false (never throws) on unequal-length inputs, same as SequenceEqual would; in practice this never triggers here since computedMac is always computed with tsig.MAC.Length as the target length, so both arrays are guaranteed equal length going in -behavior for the existing code paths is unchanged, only the timing characteristic is.

Testing?

• dotnet build of the full TechnitiumLibrary.Net project (Release): succeeds, 0 warnings/errors.
• Verified no other TSIG MAC comparison sites were missed (grep across the repo for SequenceEqual against MAC/tsig fields); the one other hit, DnsTSIGRecordData.Equals(), is a value-equality override unrelated to authentication and intentionally left as-is.
• Cross-checked the downstream consumer, TechnitiumSoftware/DnsServer, which calls this code via the unchanged VerifySignedRequest public method: built DnsServerCore, DnsServerCore.HttpApi, DnsServerCore.ApplicationCommon, and DnsServerApp against the patched library, all succeed with 0 errors.
• No automated test currently exercises TSIG verification with a deliberately wrong MAC to assert rejection; recommend adding one as a follow-up (see below).

Anything else?

• This is a defense-in-depth hardening change; there's no known exploited vulnerability being patched, just removal of a theoretical timing side channel in authentication-critical code.

[ShreyasZare]

Thanks for the PR. Will check it soon in detail.