Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
On 2012-06-18 9:49 AM, Stephane Bortzmeyer wrote: > On Tue, Jun 12, 2012 at 08:15:00PM +, > Paul Vixie wrote > a message of 21 lines which said: > >> [recursive servers are] a separate problem, and most of the time the >> fix is to add an ACL to deny off-net or off-campus query traffic. > > If you don't do ingress filtering, it still allows people to attack > your users (they can send from the outside a "ANY ripe.net" query > claiming to be from a local machine). if you want to resist spoofed-source attacks, there's a suite of necessary countermeasures, one of which is to lock down every UDP app you have to make sure they are either only available within your own network (so, an ACL) or are rate limited (as the DNS RRL patch for BIND9(*) seems able to do, but as google dns and opendns also do.) importantly, you must also drop any packet whose source address isn't correct for the input interface. this means (as above) dropping packets from outside your network which purport to be from inside your network; more commonly it means dropping packets from inside your network which purport to be from outside your network. this is covered in BCP38 and BCP84(*) and to a lesser extent SAC004(*). paul (*)http://www.redbarn.org/dns/ratelimits http://tools.ietf.org/html/bcp38 http://tools.ietf.org/html/bcp84 http://archive.icann.org/en/committees/security/sac004.txt ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
Stephane Bortzmeyer writes: > On Tue, Jun 12, 2012 at 08:15:00PM +, > Paul Vixie wrote > a message of 21 lines which said: > >> [recursive servers are] a separate problem, and most of the time the >> fix is to add an ACL to deny off-net or off-campus query traffic. > > If you don't do ingress filtering, it still allows people to attack > your users (they can send from the outside a "ANY ripe.net" query > claiming to be from a local machine). The same is true if you have open resolvers / forwarders in your networks (problem CPEs for example) and they accept spoofed queries from the outside. What is the proposed mitigation for the ISP caching resolver in these cases? Regards, Kostas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
On Tue, Jun 12, 2012 at 08:15:00PM +, Paul Vixie wrote a message of 21 lines which said: > [recursive servers are] a separate problem, and most of the time the > fix is to add an ACL to deny off-net or off-campus query traffic. If you don't do ingress filtering, it still allows people to attack your users (they can send from the outside a "ANY ripe.net" query claiming to be from a local machine). ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
On Jun 11 2012, Paul Vixie wrote: Vernon Schryver and Paul Vixie have been working on DNS Response Rate Limiting (DNS RRL) as a patch set to BIND9 (9.9.1-P1 or 9.8.3-P1) and we are ready for broader external testing. Details on how to fetch the patches and specifications are at: http://www.redbarn.org/dns/ratelimits A note for earlier private testing -- that web page now includes patched BIND9 Windows executables. Just a reminder to OARC users that there is an associated mailing list, see http://lists.redbarn.org/mailman/listinfo/ratelimits as it is surprisingly quiet so far. Sharing experiences about configurations might usefully be done there (always remembering that the black hats may be listening, of course). We have turned on rate limiting on our authoritative nameservers with good effect. -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukNew Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
On 6/12/2012 8:13 PM, Florian Weimer wrote: > * Paul Vixie: > >> Vernon Schryver and Paul Vixie have been working on DNS Response Rate >> Limiting (DNS RRL) as a patch set to BIND9 (9.9.1-P1 or 9.8.3-P1) and we >> are ready for broader external testing. > It seems rather straightforward to force recursive resolvers to hit > the rate limit. Why isn't this a problem? as described in the documentation (http://www.redbarn.org/dns/ratelimits), we do not recommend this for recursive servers at this time. that's a separate problem, and most of the time the fix is to add an ACL to deny off-net or off-campus query traffic. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
* Paul Vixie: > Vernon Schryver and Paul Vixie have been working on DNS Response Rate > Limiting (DNS RRL) as a patch set to BIND9 (9.9.1-P1 or 9.8.3-P1) and we > are ready for broader external testing. It seems rather straightforward to force recursive resolvers to hit the rate limit. Why isn't this a problem? ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
On 6/12/2012 10:16 AM, Vernon Schryver wrote:
From: Ken A
To: dns-operati...@mail.dns-oarc.net
On a authoritative + recursive server, instead of a separate view, we use:
acl "trusted" { x.x.x.x/z; };
allow-recursion { trusted; };
Is there any way to apply this patch so that it does not affect a
specific acl, such as "trusted" addresses?
Or, is it recommended/required that we configure separate views to use this?
Separate views are required to apply rate limiting to some but not
all DNS clients, unless you are of the school that holds
authoritative+recursive servers are always utterly wrong. In that
case separate servers are required.
We are a small ISP, and it has not be necessary.
We do run separate caching servers for mail server use.
Would it be easy to transform your configuration file to use views via
the include directive? My named.conf files look something like
view "insiders" {
match-clients { goodnets; };
recursion yes;
include "privatezones";
include "publiczones";
response-policy {
...
};
};
view "outsiders" {
match-clients { any; };
recursion no;
include "publiczones";
rate-limit { ... };
};
Yes, only straight forward / minor changes would be needed.
Thanks,
Ken
Vernon Schryverv...@rhyolite.com
--
Ken Anderson
Pacific Internet - http://www.pacific.net
Latest Pacific.Net Status - http://twitter.com/pacnetstatus
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
> From: Ken A
> To: dns-operati...@mail.dns-oarc.net
> On a authoritative + recursive server, instead of a separate view, we use:
> acl "trusted" { x.x.x.x/z; };
> allow-recursion { trusted; };
>
> Is there any way to apply this patch so that it does not affect a
> specific acl, such as "trusted" addresses?
>
> Or, is it recommended/required that we configure separate views to use this?
Separate views are required to apply rate limiting to some but not
all DNS clients, unless you are of the school that holds
authoritative+recursive servers are always utterly wrong. In that
case separate servers are required.
Would it be easy to transform your configuration file to use views via
the include directive? My named.conf files look something like
view "insiders" {
match-clients { goodnets; };
recursion yes;
include "privatezones";
include "publiczones";
response-policy {
...
};
};
view "outsiders" {
match-clients { any; };
recursion no;
include "publiczones";
rate-limit { ... };
};
Vernon Schryverv...@rhyolite.com
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
On 2012-06-12 2:33 PM, Ken A wrote:
>
> On a authoritative + recursive server, instead of a separate view, we
> use:
> acl "trusted" { x.x.x.x/z; };
> allow-recursion { trusted; };
>
> Is there any way to apply this patch so that it does not affect a
> specific acl, such as "trusted" addresses?
no, sorry.
> Or, is it recommended/required that we configure separate views to use
> this?
yes.
paul
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
On a authoritative + recursive server, instead of a separate view, we use:
acl "trusted" { x.x.x.x/z; };
allow-recursion { trusted; };
Is there any way to apply this patch so that it does not affect a
specific acl, such as "trusted" addresses?
Or, is it recommended/required that we configure separate views to use this?
Thanks,
Ken
On 6/11/2012 4:56 PM, Paul Vixie wrote:
Vernon Schryver and Paul Vixie have been working on DNS Response Rate
Limiting (DNS RRL) as a patch set to BIND9 (9.9.1-P1 or 9.8.3-P1) and we
are ready for broader external testing.
Details on how to fetch the patches and specifications are at:
http://www.redbarn.org/dns/ratelimits
A note for earlier private testing -- that web page now includes patched
BIND9 Windows executables.
vix& vjs
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
--
Ken Anderson
Pacific Internet - http://www.pacific.net
Latest Pacific.Net Status - http://twitter.com/pacnetstatus
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] dns response rate limiting (DNS RRL) patch available for testing
Vernon Schryver and Paul Vixie have been working on DNS Response Rate Limiting (DNS RRL) as a patch set to BIND9 (9.9.1-P1 or 9.8.3-P1) and we are ready for broader external testing. Details on how to fetch the patches and specifications are at: http://www.redbarn.org/dns/ratelimits A note for earlier private testing -- that web page now includes patched BIND9 Windows executables. vix & vjs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
