Add RFC 3403–compliant guard clauses to DnsNAPTRRecordData constructor

[zbalkan]

Summary

The DnsNAPTRRecordData constructor currently accepts parameters without validating them against the structural requirements defined in RFC 3403 (DDDS DNS Database / NAPTR RR). This allows construction of NAPTR records that are explicitly invalid per the RFC and would later need to be ignored or rejected by consumers.

RFC 3403 defines several mandatory constraints that should be enforced at object construction time to prevent invalid state from entering the system.

Affected code

        public DnsNAPTRRecordData(ushort order, ushort preference, string flags, string services, string regexp, string replacement)
        {
            if (DnsClient.IsDomainNameUnicode(replacement))
                replacement = DnsClient.ConvertDomainNameToAscii(replacement);

            DnsClient.IsDomainNameValid(replacement, true);

            _order = order;
            _preference = preference;
            _flags = flags;
            _services = services;
            _regexp = regexp;
            _replacement = replacement;

            Serialize();
        }

Expected behavior

The constructor should fail fast when parameters violate RFC 3403 structural rules, ensuring that any instantiated DnsNAPTRRecordData object is syntactically valid.

Required validation (RFC 3403)

• order and preference are valid as ushort (0–65535); no extra checks required.

• flags, services, regexp, and replacement MUST NOT be null (DNS <character-string> may be empty but not null).

• FLAGS:

  • Only characters [A–Z0–9] (case-insensitive) are permitted.
  • Empty string is allowed.

• REGEXP and REPLACEMENT are mutually exclusive.

  • If both are non-empty, the record is invalid and MUST be rejected.
  • At least one of them MUST be non-empty.

• REPLACEMENT, if present:

  • MUST be a fully qualified domain name.
  • MUST end with a trailing dot.
  • MUST NOT contain empty labels (..).

• SERVICES:

  • Must be a valid DNS <character-string>.
  • Semantic validation is application-specific and out of scope here.

• REGEXP:

  • RFC requires POSIX ERE semantics but does not mandate compile-time regex validation.
  • Only basic non-emptiness checks should be enforced at this layer.

Rationale

• RFC 3403 explicitly states that records violating these rules are “in error and SHOULD be ignored or an error returned.”
• Enforcing these constraints at construction time prevents invalid NAPTR records from propagating through resolution, caching, or serialization logic.
• This keeps RFC-mandated structural validation separate from application-specific DDDS logic (ENUM, URI resolution, etc.).

Reference

• RFC 3403 — Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database, Sections 3–4.