In message <236f5488-42d4-4a89-acab-b55fd2b57...@fl1ger.de>, "Ralf Weber" writes: > Moin! > > On 20 Jul 2016, at 5:03, wrote: > > > About the DDoS risk, it should not be worried so much because this > > scheme is controlled/triggered by the recursive server (with a flag as > > NN bit). > > In other words, the recursive server can get the piggybacked multiple > > responses only when it wants and of cource it can disable this model > > anytime. > 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).
Which is why DNS COOKIES with a valid server cookie / TCP / DNS-O-TLS was suggests as being a necessary precondition. > > Another scenario to illustrate this proposal is under the DANE case: > > A client wants to visit www.example.com. > > But this domain name supports DANE can the TLSA record is configured > > under the domain name: _443._tcp.www.example.com. > > The client has to query the two names seperately. > > Yes, it is just one more TTL, but why not to do the optimization with > > a steerable method. > Again if example.com is popular almost all the time this record will be > in the cache already. But the cache can be the other side of the world. The browser vendors aren't willing to go to SRV because they may need to make a second query to the recursive server to get the addresses of the SRV targets. > > So long > -Ralf > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
