Hi DPRIVE folks-- RFC 7830 (The EDNS(0) Padding Option) says:
> The "Padding" option MUST occur at most, once per OPT meta-RR (and > hence, at most once per message). Over on https://github.com/PowerDNS/pdns/issues/10884 there's some discussion of a case where it would be technically advantageous for a DNS server to include more than one EDNS padding option. In particular, a forwarding DNS resolver might want to remove some EDNS option from an already-padded query or response before forwarding while keeping the DNS frame the same size. A very simple way to do this when the cleartext DNS frame is in memory is to overwrite the undesired EDNS option with another EDNS padding option, but that would run afoul of the above "MUST" when the frame is already padded. Obviously, it's not impossible to shuffle EDNS options around in the frame to coalesce the padding octets into a single Padding option. But in the interest of keeping the "fast path" fast, and of reducing the opportunity for bugs in the codebase the implementers at the linked issue are hesitant to do that kind of work. I reviewed the previous drafts of RFC 7830 all the way back to https://datatracker.ietf.org/doc/html/draft-mayrhofer-edns0-padding-00 and the "at most once" language appears in all of them -- but i don't see a justification for it. RFC 2119 of course says of upper-case keywords: > they MUST only be used where it is actually required for > interoperation or to limit behavior which has potential for causing > harm (e.g., limiting retransmissions). For example, they must not > be used to try to impose a particular method on implementors where > the method is not required for interoperability. Does anyone know the rationale for this "MUST occur at most once" ? Is there an additional privacy leak if there were to be more than one EDNS Padding option? Are there implementations that would choke if they received more than one EDNS Padding option? Has anyone done any experiments to see whether multiple Padding options do break interoperability? If not, does anyone have a DNS interop testing rig that could be easily updated to include such a test? --dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
