Apply the request and response rules

Response padding depends on request capabilities, encryption and space, not echoing the request’s padding length.

• These cases assume encrypted transport throughout; otherwise the security rule forbids Padding. When the query included Padding, responders MUST pad the response unless doing so would violate the maximum UDP payload size. A query option with zero data bytes still counts as included. The responder chooses its own padding amount rather than echoing the query’s length (§§3–4,6).
• When the query indicated EDNS(0) support but did not include Padding, responders MAY pad the response. This is permission, not a requirement to insert padding into every EDNS exchange, and all encryption and size conditions still apply (§4).
• When the query did not indicate EDNS(0) support, responders MUST NOT pad the response (§4). The diagram stops the padding branch; it does not say that the responder cannot return an ordinary answer.
• When a query included Padding but fewer than four octets remain in the effective payload budget, the mandatory-response rule’s size exception applies. Zero data length cannot make its four-byte header disappear. A selected block target exceeding the budget is a different case: a smaller amount may still fit. The helper distinguishes no-room from policy-target failure (§4; RFC 8467 Appendix A.1).
• The helper returns required/optional/forbidden/size-exception classifications for selected valid request inputs. It does not send DNS packets, implement all DNS errors or decide the rest of a response’s EDNS content. The request’s advertised size is not cached as a permanent peer capability (RFC 6891 §6.2.3).