Now that I read my post again, I found out that all your questions were
about the collector, not the presenter.
Unfortunately, I am not on the operations side of things, so I have no
experience with the resources that the DSC collector consumes :(
Best regards
Beda
On 15/05/13 08:53, Bedric
Hi,
Does a hardware firewall help to defend the DNS attack?
If so what's the suggested policy/rules?
Thanks.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing l
On 15 May 2013 09:13, fenghe wrote:
> Does a hardware firewall help to defend the DNS attack?
> If so what's the suggested policy/rules?
Chances are your firewall will break long before your DNS server is overwhelmed.
DNS traffic should not be firewalled, the number of UDP transactions
will very
I've been told that we can't implement BCP38 because its actually an egress
filteringits only ingress from the perspective of the ISP and its
downstream customersto DNS operators, that the ISPs need to implement.
Since it is to prevent source address that aren't in the netblock of its
...
Lawrence K. Chen, P.Eng. wrote:
> I've been told that we can't implement BCP38 because its actually an egress
> filteringits only ingress from the perspective of the ISP and its
> downstream customersto DNS operators, that the ISPs need to implement.
> Since it is to prevent source
I thought I'd share this to anyone that wants to just force all TYPE=ANY
queries over TCP to prevent those from coming from spoofed locations.
This is a crude but effective hack. It doesn't stop the system from recursing
to find the response.
http://puck.nether.net/~jared/bind-9.9.3rc2-tcp-any
> From: Jared Mauch
> I thought I'd share this to anyone that wants to just force all TYPE=ANY
> queries over TCP to prevent those from coming from spoofed locations.
>
> This is a crude but effective hack. It doesn't stop the system from
> recursing to find the response.
>
> http://puck.nethe
* Vernon Schryver [2013-05-15 21:40]:
>> From: Jared Mauch
>> This is a crude but effective hack. It doesn't stop the system from
>> recursing to find the response.
>
>
> I can understand simplistic DNS reflection mitigation in firewalls,
> especially when response rate limiting is not availab
On May 15, 2013, at 5:09 PM, Matthäus Wander
wrote:
> * Vernon Schryver [2013-05-15 21:40]:
>>> From: Jared Mauch
>>> This is a crude but effective hack. It doesn't stop the system from
>>> recursing to find the response.
>>
>>
>> I can understand simplistic DNS reflection mitigation in fi
On Wed, 15 May 2013 17:52:11 -0400
Jared Mauch wrote:
> If others want, I can look at putting in a config directive. It
> would be possible to add other RRtypes easily enough that should get
> TCP only that are not commonly used.
I can speak for others, but I would prefer to use the RRL code al
On May 15, 2013, at 5:58 PM, John Kristoff wrote:
> On Wed, 15 May 2013 17:52:11 -0400
> Jared Mauch wrote:
>
>> If others want, I can look at putting in a config directive. It
>> would be possible to add other RRtypes easily enough that should get
>> TCP only that are not commonly used.
>
>
One more comment: This patch only impacts recursive servers, not authorities.
They won't set TC=1 for an ANY query.
- Jared
On May 15, 2013, at 6:03 PM, Jared Mauch wrote:
>
> On May 15, 2013, at 5:58 PM, John Kristoff wrote:
>
>> On Wed, 15 May 2013 17:52:11 -0400
>> Jared Mauch wrote:
>
> From: Jared Mauch
> Because of the FP ratio presented at the DNS-OARC meeting this
> past week. It's suitable on a recursive resolver, where RRL is most effective
> on an authority.
>
> See
>
> https://indico.dns-oarc.net/indico/getFile.py/access?contribId=4&resId=0&materialId=slides&confId=0
On May 15, 2013, at 6:52 PM, Vernon Schryver wrote:
>> This effectively does slip=1 and does away with any amplification and just
>> makes it
>> a pure reflection attack. Still not ideal, but doesn't amplify.
>
> On the contrary, as I just now wrote in the ratelimits mailing list
> http://lis
> From: Jared Mauch
> The folks that are most concerned with RRL are those expecting queries
> from stub resolvers, I think this would mitigate this risk.
} > Is it intentional that the patch does not affect authoritative ANY
} > responses? I think the patch would fail to stop the authorities f
On May 15, 2013, at 8:03 PM, Vernon Schryver wrote:
> I think the patch has a false negative rate of approximately 100%.
> To check whether I am wrong again, I set up a test server and tried
> two `dig +ignore isc.org any` commands. The first got a TC=1 error
> response as expected. The second
I fixed the patch by moving where it does this check to before query_find as
opposed to inside it.
Thanks for the insight and input.
- Jared
On May 15, 2013, at 8:03 PM, Vernon Schryver wrote:
> I think the patch has a false negative rate of approximately 100%.
> To check whether I am wrong a
17 matches
Mail list logo
