multi-qtypes Security Considerations says: > The method documented here does not change any of the security > properties of the DNS protocol itself.
I don't think this statement is true. Why? a) DNS DDoS threats are real and there was a shift towards minimizing answers. This goes in the reverse direction. But you address this in both security considerations. multiple-responses Security Considerations says: > > Additional records will make DNS responses even larger than they are > currently, leading to larger records that can be used in DNS > reflection attacks. One could mitigate this by only serving > responses to EXTRA requests over TCP or when using Cookies [RFC5395], > although there is no easy way to signal this to a client other than > through the use of the truncate bit. multi-qtypes Security Considerations says: > It should however be noted that this method does increase the > potential amplification factor when the DNS protocol is used as a > vector for a denial of service attack. b) UDP fragmentations - it strongly increases the risk of UDP fragmentation which is strongly discouraged (SHOULD NOT) in BCP 145. also multiple-responses Security Considerations says: > A malicious authoritative server could include a large number of > extra records (and associated DNSSEC information) and attempt to DoS > the recursive by making it do lots of DNSSEC validation. However, > this is not considered a realistic threat; CPU for validation is > cheap compared to bandwidth. This can be mitigated by allowing the > recursive resolver to ignore Additional records whenever it considers > itself under attack or its CPU resources are otherwise over- > committed. It should be noted, that ECC validation is more CPU intensive than RSA, as as such I find "CPU for validation is cheap compared to bandwidth" quite bold claim that should come with some data. Cheers, -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:[email protected] https://nic.cz/ -------------------------------------------- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
