> From: Dave Warren
> I haven't been following the RRL discussions too closely, is this patch
> scheduled to be included in BIND9 proper or will it remain a patch?
} From: Evan Hunt each at isc.org
} > It's not built into bind (yet).
}
} Correct. For the record, it'll be in 9.10.0 by default
On 2013-07-05 07:21, John Wobus wrote:
I endorse this suggestion: we were faced with such attacks and were
naturally leery about issues we might run into running a patched bind
and the additional tuning it could require. Our experience is: the RRL
patch, used with its default parameters, simply
> From: John Wobus
> > Other possibility is to implement packet rate limiting - a patch was
> > discussed here a few days/weeks ago.
>
> I endorse this suggestion: we were faced with such attacks and were
> naturally leery about issues we might run into running a patched bind
> and the additional
Other possibility is to implement packet rate limiting - a patch was
discussed here a few days/weeks ago.
I endorse this suggestion: we were faced with such attacks and were
naturally leery about issues we might run into running a patched bind
and the additional tuning it could require. Our exp
On 01.07.13 04:02, blrmaani wrote:
We are noticing that a handful of our domains are being used for
amplification attacks and we would like to reduce outgoing (DNS response)
packet size.
One solution is to reduce the additional sections in the response for these
handful zones and I would like to
On 01/07/13 12:02, blrmaani wrote:
We are noticing that a handful of our domains are being used for
amplification attacks and we would like to reduce outgoing (DNS
response) packet size.
One solution is to reduce the additional sections in the response for
these handful zones and I would like to
If these are authoritative DNS servers then just enable
minimal-responses, so clients will only ever get the records that they
requested.
Steve
On 1 July 2013 12:02, blrmaani wrote:
> We are noticing that a handful of our domains are being used for
> amplification attacks and we would like to r
We are noticing that a handful of our domains are being used for amplification
attacks and we would like to reduce outgoing (DNS response) packet size.
One solution is to reduce the additional sections in the response for these
handful zones and I would like to know if there is any way to add s
On 24 June 2013 08:14, Matus UHLAR - fantomas wrote:
> You still have not answered my question, so I repeat it:
>
>>> > What is the point of your question?
>
I think what Matus wants to know is your reasoning/problem/issue about
not returning records from the cache for those zones?
The answer is
On Friday, June 21, 2013 11:26:25 AM UTC-7, Lawrence K. Chen, P.Eng. wrote:
I thought I had read somewhere (which I can't locate), that
additional-from-auth can be used in global or view scope.
On 23.06.13 23:25, blrmaani wrote:
Yes, works in Global view. I am trying to prevent additional rec
Yes, works in Global view. I am trying to prevent additional records being sent
from a selected list of zone in our configuration..
blr
On Friday, June 21, 2013 11:26:25 AM UTC-7, Lawrence K. Chen, P.Eng. wrote:
> I thought I had read somewhere (which I can't locate), that
> additional-from-aut
I thought I had read somewhere (which I can't locate), that
additional-from-auth can be used in global or view scope.
- Original Message -
> On 21.06.13 02:00, blrmaani wrote:
> >The additional-from-auth yes_or_no ; option is a global option. I
> >would
> > like to know if there is a per-
On 21.06.13 02:00, blrmaani wrote:
The additional-from-auth yes_or_no ; option is a global option. I would
like to know if there is a per-zone configuration to do the same in BIND9
configuration? I couldn't find it in BIND9 ARM.
What is the point of your question?
--
Matus UHLAR - fantomas, u
The additional-from-auth yes_or_no ; option is a global option. I would like to
know if there is a per-zone configuration to do the same in BIND9
configuration? I couldn't find it in BIND9 ARM.
Thanks!
Blr
___
Please visit https://lists.isc.org/mailm
14 matches
Mail list logo