Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses

In message <236F5488-42D4-4A89-ACAB-B55FD2B5782A@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: marka@isc.org