Added RFC 3403-compliant guard clauses to DnsNAPTRRecordData constructor

[zbalkan]

Solves #45

P.S: Renamed branch and reopened PR.

[Copilot]

Pull request overview

This PR aims to enforce RFC 3403 structural constraints at construction time for DnsNAPTRRecordData, preventing creation of syntactically invalid NAPTR records (per issue #45).

Changes:

• Added null guard clauses for NAPTR <character-string> fields (flags, services, regexp, replacement).
• Added validation for RFC 3403 constraints (REGEXP/REPLACEMENT exclusivity, FLAGS character set, basic SERVICES sanity).
• Added a helper to validate regexp via .NET Regex compilation (plus new System.Text.RegularExpressions import).

Comments suppressed due to low confidence (1)

TechnitiumLibrary.Net/Dns/ResourceRecords/DnsNAPTRRecordData.cs:123

• IsDomainNameValid(replacement, true) is called even when replacement contains a trailing dot; since IsDomainNameValid rejects empty labels, this will throw for any FQDN that ends with .. This further confirms the trailing-dot requirement above is incompatible with the validator. Normalize replacement (e.g., trim a terminal dot) before validation, or remove the trailing-dot requirement entirely to match other RR constructors.

            //  DNS <character-string> constraints 
            if (DnsClient.IsDomainNameUnicode(replacement))
                replacement = DnsClient.ConvertDomainNameToAscii(replacement);

            DnsClient.IsDomainNameValid(replacement, true);

---

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

[ShreyasZare]

can contain arbitrary chars ans since the SERVICES parameter leaves it up to the application, validation for this param should be removed.

[ShreyasZare]

validation for REPLACEMENT is already in place done using DnsClient.IsDomainNameValid. So this is can be removed. This library internally does not allow domain names to end with . char.

[ShreyasZare]

Thanks for the PR. Added couple of comments for change. Rest changes look good.