[DNSOP] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: Knot Resolver + Knot DNS
With Knot Resolver + Knot DNS the fragmentation issues are currently being addressed quite simply: * IP_PMTUDISC_OMIT to avoid spoofed MTU * UDP size limit, 1232 by default (and of course honoring if the other side wants lower, etc.) Other points from the draft, perhaps less important: * fragments are ignored if they arrive over an XDP interface (XDP usage is not typical) * TCP is attempted after repeated UDP timeouts * minimal responses: yes (not configurable) * smaller signatures: yes, ecdsap256sha256 by default I also believe that the MTU spoofing should be reflected in this draft's recommendations. With the current list I _suspect_ attackers could relatively easily force all 512B+ answers to TC=1 + TCP (if on IPv4). 1232: I haven't gone in detail over the relevant measurements so I'm not even 100% sure they're conclusive, but it might really will be better to increase that default. I don't expect any other changes related to this draft for future. Use 'minimal-responses' configuration: Some implementations have a 'minimal responses' configuration that causes DNS servers to make response packets smaller, containing only mandatory and required data Nit: this formulation makes me wonder what this recommends for SVCB-like records. Strictly taken I'd say it clashes with some SHOULDs from the soon-to-be RFC. Either way, SVCB-like queries could be prone to generating large answers (if this SHOULD is followed). --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: Knot Resolver + Knot DNS
thanks for this. can you propose new text? educating the authors to the point where they can speak for your experience may be error prone. re: Vladimír Čunát wrote on 2023-01-28 09:42: With Knot Resolver + Knot DNS the fragmentation issues are currently being addressed quite simply: * IP_PMTUDISC_OMIT to avoid spoofed MTU * UDP size limit, 1232 by default (and of course honoring if the other side wants lower, etc.) Other points from the draft, perhaps less important: * fragments are ignored if they arrive over an XDP interface (XDP usage is not typical) * TCP is attempted after repeated UDP timeouts * minimal responses: yes (not configurable) * smaller signatures: yes, ecdsap256sha256 by default I also believe that the MTU spoofing should be reflected in this draft's recommendations. With the current list I _suspect_ attackers could relatively easily force all 512B+ answers to TC=1 + TCP (if on IPv4). 1232: I haven't gone in detail over the relevant measurements so I'm not even 100% sure they're conclusive, but it might really will be better to increase that default. I don't expect any other changes related to this draft for future. Use 'minimal-responses' configuration: Some implementations have a 'minimal responses' configuration that causes DNS servers to make response packets smaller, containing only mandatory and required data Nit: this formulation makes me wonder what this recommends for SVCB-like records. Strictly taken I'd say it clashes with some SHOULDs from the soon-to-be RFC. Either way, SVCB-like queries could be prone to generating large answers (if this SHOULD is followed). --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
