On Wed, Jul 20, 2016 at 9:40 AM, 延志伟 wrote:
> Hi, Ralf, I understand prefetch by the recursive server and it is the
> common case.
> [https://tools.ietf.org/html/draft-liu-dnsop-dns-cache-00]
> But if recursive server asks: give me the a RR and all the related RRs
> under your domain. And the aut
Hi, Ralf, I understand prefetch by the recursive server and it is the common
case.
[https://tools.ietf.org/html/draft-liu-dnsop-dns-cache-00]
But if recursive server asks: give me the a RR and all the related RRs under
your domain. And the authoritative server sends back the requested domain nam
Hi, Ralf,
We understand your worries and these negative effects can be fixed or descended
in the next version.
But anyway, let's go back to the scenario considered by our draft to illustrate
its necessity.
I show an example as following (although I think we have described it several
times. :-)
Moin!
On 20 Jul 2016, at 14:36, 延志伟 wrote:
But anyway, let's go back to the scenario considered by our draft to
illustrate its necessity.
I show an example as following (although I think we have described it
several times. :-)):
In order to visit the www.baidu.com, the user has to query
www.ba
Jim,
On 20 Jul 2016, at 9:18, Jim Reid wrote:
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 respo
Moin!
On 20 Jul 2016, at 7:34, 延志伟 wrote:
I understand your points, but these risks always be there because DNS
response is larger than the request, like DNSSEC.
Yes, which is why we have several proposals on how to mitigate the
problem by e.g not giving back ALL qtypes to an ANY question, or
> On 20 Jul 2016, at 08:40, Mark Andrews wrote:
>
> Nameservers make decisions TODAY about what they will put in a message
> based on COOKIES / TCP / UDP and a host of other considerations.
True. But that's orthogonal to the point I was making.
The draft *might* be heading in the direction of
In message <36a593c1-1f01-4fe1-bc9a-3279f6460...@rfc1035.com>, Jim Reid writes:
>
> > On 20 Jul 2016, at 06:19, Mark Andrews 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 =
> pa
> On 20 Jul 2016, at 06:19, Mark Andrews wrote:
>
>> 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).
>
Good morning, Ralf.
At 2016-07-20 13:07:01, "Ralf Weber" wrote:
>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 rec
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 ot
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 o
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.
Sorry, this sort of response to queries.
On Jul 19, 2016 10:14, "Matthew Pounsett" wrote:
>
>
> On 19 July 2016 at 09:46, Ted Lemon wrote:
>
>> I thought the proposal specifically excluded support for this sort of
>> query in any case other than for queries from authoritative servers.
>>
>> I'm
On 19 July 2016 at 09:46, Ted Lemon wrote:
> I thought the proposal specifically excluded support for this sort of
> query in any case other than for queries from authoritative servers.
>
> I'm not sure what you mean about "this sort of query".There wouldn't
be any special query sent to recur
I thought the proposal specifically excluded support for this sort of query
in any case other than for queries from authoritative servers.
On Jul 19, 2016 09:37, "Matthew Pounsett" wrote:
>
>
> On 19 July 2016 at 09:19, Ralf Weber wrote:
>
>> Moin!
>>
>> On 19 Jul 2016, at 9:00, Christopher Mor
On 19 July 2016 at 09:19, Ralf Weber wrote:
> Moin!
>
> On 19 Jul 2016, at 9:00, Christopher Morrow wrote:
>
> > On Jul 19, 2016 8:36 AM, "Ralf Weber" wrote:
> >>
> >>
> >> Except that if you have a decent size and hot Cache with refreshing
> >> these records will be in there anyway. IMHO you ga
Moin!
On 19 Jul 2016, at 9:00, Christopher Morrow wrote:
> On Jul 19, 2016 8:36 AM, "Ralf Weber" wrote:
>>
>>
>> Except that if you have a decent size and hot Cache with refreshing
>> these records will be in there anyway. IMHO you gained nothing, but I
>> agree with Jim Reid that it would be go
On Jul 19, 2016 8:36 AM, "Ralf Weber" wrote:
>
>
> Except that if you have a decent size and hot Cache with refreshing
> these records will be in there anyway. IMHO you gained nothing, but I
> agree with Jim Reid that it would be good to have data on this.
Nothing except some DNS round trips.
How
Moin!
On 19 Jul 2016, at 8:18, George Michaelson wrote:
> "in reality" is skewing the story. You don't foresee a usecase, but
> you do foresee abuse? So deploy cookies or move to TCP, or DTLS or
> some other cost space where amplify implies special knowledge, or cost
> on the amplifier.
Which the
"in reality" is skewing the story. You don't foresee a usecase, but
you do foresee abuse? So deploy cookies or move to TCP, or DTLS or
some other cost space where amplify implies special knowledge, or cost
on the amplifier.
I'm not sure I understand the use-case either btw, but this rebuttal
smell
Moin!
You were not alone, though I hummed for different reasons. I think it is
bad to blow up responses with stuff that might be helpful, but in reality
only will be helpful to people running amplification attacks.
So long
-Ralf
___
DNSOP mailing list
Paul Wouters wrote:
> The reason I hummed against this idea is that I think it is better to
> teach validators to not strip dnssec signed additional data, and just
> supply the data there.
>
> The current document as explained today seemed to limit itself already
> to in baliwick or subzone data.
The reason I hummed against this idea is that I think it is better to
teach validators to not strip dnssec signed additional data, and just
supply the data there.
The current document as explained today seemed to limit itself already
to in baliwick or subzone data.
That seems a much simpler sol
24 matches
Mail list logo
