Keep the privacy and security limits visible

Padding hampers one size clue; it does not make DNS anonymous or configure secure transport.

• Padding increases message size and traffic and can make DNS amplification attacks easier. These concerns are part of why RFC 7830 forbids using it over unencrypted transport. In the chosen base40→64 example, 24 extra bytes include header4+data20: a 60% increase before transport overhead (§6). This is not a measured real-world amplification factor.
• Even encryption plus padding can leave DNS recognizable, with timing and query/response counts still leaking information. RFC 8467 §6 explicitly identifies these limits; no timing jitter or cover-traffic scheme is implemented or recommended by this guide. Equal inner DNS lengths alone do not establish anonymity.
• RFC 7830 §6 says implementations/deployments SHOULD disable TLS-level compression because it can affect padding length. Current guidance in RFC 9325 §3.3 discourages TLS 1.2 record-level compression (SHOULD NOT, with a narrow proven-safe exception) and notes it was removed from TLS 1.3. This does not forbid DNS name compression or every other form of compression. Padding does not configure or authenticate a TLS connection.
• Padding data can be a covert channel, like other DNS fields. The receiver’s MUST-accept-any-value requirement remains a structural rule, not an endorsement or proof of the data’s meaning or sender identity. The fictional bytes 68 69 happen to spell hi in ASCII; the option does not define such a text payload (§§3,6).
• The option code’s registry status “Standard” is an IANA registration label. RFC 7830’s official publication status is Proposed Standard, May 2016, with no formal Updates/Updated By/Obsoletes/Obsoleted By relationships in the fresh RFC Editor metadata. RFC 8467 and current TLS guidance are related publications, not replacement editions of this immutable RFC (§5).