Decode the Padding option exactly

Count data bytes separately from the four-byte header, and accept any received padding value.

• The option lives inside the RDATA of the OPT record. Its OPTION-CODE is 12, encoded as 00 0c. OPTION-LENGTH is the number of following PADDING octets, excluding the two code octets and two length octets. A chosen length-three zero-filled option is 00 0c 00 03 00 00 00: seven octets in total (§3).
• The minimum data length is zero. Thus 00 0c 00 00 is a present Padding option that still occupies four octets. Presence must not be detected by testing whether its data length is nonzero (§3). This distinction also matters when a zero-length request option triggers the response rule.
• Padding octets SHOULD be 0x00. Other values MAY be used, for example when compression before encryption is a concern. Received PADDING octets of any value MUST be accepted. A nonzero body is not by itself a malformed Padding option; changing SHOULD into a mandatory all-zero receiver check would be wrong (§3).
• The Padding option MUST occur at most once per OPT record and therefore at most once per DNS message (§3). RFC 6891 §6.1.1 permits only one OPT record in a message. The chosen builder rejects a duplicate Padding option before serialization. This is a local input disposition, not a claim that RFC 7830 mandates a particular receiver error packet.
• OPT RDLEN counts all option headers and data in its RDATA. Its 16-bit bound, the overall message budget and any other options all constrain what can fit; a 16-bit Padding length alone does not mean 65535 data octets fit into a whole message. The selected parser never reads past the declared RDATA boundary, and its incomplete/error statuses are local buffer policies (RFC 6891 §6.1.2).