In message <36a593c1-1f01-4fe1-bc9a-3279f6460...@rfc1035.com>, Jim Reid writes: > > > On 20 Jul 2016, at 06:19, Mark Andrews <ma...@isc.org> wrote: > >=20 > >> That's not who DDos work. If attacker would only do what the specs = > say > >> we wouldn't have any DDos. But an attacker can just create an UDP = > packet > >> with that bits and a spoofed address and fire it off (or get a botnet = > to > >> fire it off). > >=20 > > Which is why DNS COOKIES with a valid server cookie / TCP / DNS-O-TLS > > was suggests as being a necessary precondition. > > The draft does not say that Mark.
It was stated up thread. Additionally aren't these discussion supposed to get consensus of the changes needed rather than the "I-D is cast in stone" especially right at the start of the processes. If this was last call this sort of nit picking would be justified but at this stage of the development process it seems to be unnecessary. > Under Security Considerations, it says: "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." > > It's a bit of a stretch to call that a suggestion and a far bigger one to > claim cookies and/or TCP as a necessary precondition. There's no language > like "clients and servers SHOULD (MUST?) use DNS cookies/TCP/DNSoverTLS > for EXTRA queries and responses". Well, not yet anyway. Maybe in the next > release. > > And if DNS over TLS is the answer, the overheads of that handshake would > more than cancel out the benefit of optimising away an extra > query/response RTT. > > FWIW, I think it's a Bad Idea and the start of a very slippery slope to > make queries or responses to QTYPEs dependent on the underlying transport > protocol (modulo AXFR of course). Are layering violations acceptable > nowadays? Nameservers make decisions TODAY about what they will put in a message based on COOKIES / TCP / UDP and a host of other considerations. Personally I don't think EXTRA is needed. A nameserver can predict a lot of the future queries based on the contents of the reply to the initial query. MX -> A / AAAA / TLSA of _25._tcp.<MX TARGET> SRV -> A / AAAA / if _tcp then TLSA of _<port>._tcp.<SRV TARGET> Yes, the responses get bigger but bigger isn't the real problem. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
