Re: Stopping ddos
I've never actually used RRL, but from the manual, it appears to default to a /24 prefix length to determine whether IPv4 clients are "similar" enough to be lumped in the same bucket, for RRL purposes. That might need to be tweaked, depending on the profile of whoever is attacking/abusing you. The option is ipv4-prefix-length. IPv6 has a similar option, defaulting to /56. From your partial log extract, it looks like you're getting hit from different parts of the 114.29.192.0/19 netblock (which, according to APNIC, appears to belong to WebEx/Cisco). That's why I suggested you might want to tweak those settings. From the ARM, it looks like there are other configuration parameters too -- responses-per-second, nodata-per-second, nxdomains-per-second, referrals-per-second -- presumably all intended to provide fine-grained protection with minimal false positives. I would recommend a thorough reading of the ARM, and perhaps consultation with DNS admins who have practical experience with RRL. Hopefully there are some on this list. If you have a robust IPS in place, it should be possible, with the appropriate signature/rule, to drop all incoming root-domain queries. That's a pretty drastic solution, though, and there could be fallout. - Kevin From: bind-users on behalf of Richard T.A. Neal Sent: Tuesday, August 2, 2022 5:20 PM To: r...@htt-consult.com ; bind-users@lists.isc.org Subject: RE: Stopping ddos >> Any best practices on this? >> >> I am running bind 9.11.4 >> >> thanks > You could think about adding fail2ban to your server with some custom rules. > Helped us in a similar situation. You could also take advantage of BIND's built-in Response Rate Limiting which is explained here: https://downloads.isc.org/isc/bind9/9.16.31/doc/arm/html/reference.html#response-rate-limiting I don't recall if BIND 9.11 supports that feature, but even if it does you should really be upgrading to 9.16.31 anyway (the latest Current-Stable, ESV). Best, Richard. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Resolve any query to same IP address
[ Classification Level: GENERAL BUSINESS ]
Dot "." instead of asterisk "*" as the zone name. Remove the "hint" zone,
since that doesn't apply when you host your own root zone.
You need a proper MNAME for the SOA RR too.
- Kevin
On Wed, Jul 21, 2021 at 11:18 AM Jeronimo wrote:
> Hi,
>
> how can I get the same IPv6 address as the answer to any query to my Bind9?
>
> I am using Ubuntu 20 and Bind 9.11 whit configuration as bellow:
>
> --
> $ cat /etc/bind/named.conf
> include "/etc/bind/named.conf.options";
> include "/etc/bind/named.conf.local";
> include "/etc/bind/named.conf.default-zones";
> --
> $ cat /etc/bind/named.conf.options
> options {
> directory "/var/cache/bind";
> recursion no;
> querylog yes;
> listen-on-v6 { any; };
> dnssec-validation auto;
> auth-nxdomain no;# conform to RFC1035
> };
>
> $ cat /etc/bind/named.conf.default-zones
> zone "." {
> type hint;
> file "/etc/bind/db.root";
> };
>
> zone "localhost" {
> type master;
> file "/etc/bind/db.local";
> };
>
> zone "127.in-addr.arpa" {
> type master;
> file "/etc/bind/db.127";
> };
>
> zone "0.in-addr.arpa" {
> type master;
> file "/etc/bind/db.0";
> };
>
> zone "255.in-addr.arpa" {
> type master;
> file "/etc/bind/db.255";
> };
>
> zone "*" {
> type master;
> file "/etc/bind/db.fakeroot";
> };
> --
> $ cat db.fakeroot
> $TTL 30
> @ IN SOA * hostmaster.mydomain.com. (
> 1 ; Serial
> 240 ; Refresh
> 120 ; Retry
> 900 ; Expire
> 300 ; Negative Cache TTL
> )
> ;
> IN NS
> * IN
>
> Any help is welcome.
>
> Regards,
>
> Jeronimo
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: query-source and listened interfaces
[ Classification Level: GENERAL BUSINESS ] I've done the match-destinations/query-source thing before, but in addition to that, it should theoretically be possible to also use a shared cache between the views, via attach-cache. I've never played with that directive myself, however. - Kevin On Mon, Jul 12, 2021 at 5:32 AM Petr Menšík wrote: > Hi Xinyu. > > Why would you need client-facing IP address to appear on authoritative > servers? It should be more or less independent. > > I think it might be possible to use views and match-destination combined > with query-source for each view. But it seems similar to running separate > bind instances. I think it would have different cache anyway. > > Can you share why source addresses are important? > > Cheers, > > Petr > On 7/8/21 9:08 AM, Xinyu Wang wrote: > > Hi guys, > > Is it possible to make a recursive BIND send queries to authorities from > the interface which the original query was sent to. > > For instance, > the recursive BIND is listening 3 interfaces, they are 1.1.1.1, 1.1.1.2, > and 1.1.1.3 > > when a recusive query arrived at 1.1.1.1, then BIND use 1.1.1.1 to > complete the recursion process. > > when a recusive query arrived at 1.1.1.2, then BIND use 1.1.1.2 to > complete the recursion process. > > when a recusive query arrived at 1.1.1.3, then BIND use 1.1.1.3 to > complete the recursion process. > > Hopefully I made myself clear, and looking forward to some help. > Thanks > > > > -- > Petr Menšík > Software Engineer > Red Hat, http://www.redhat.com/ > email: pemen...@redhat.com > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Managing localhost
[ Classification Level: GENERAL BUSINESS ] That chapter doesn't show any PTR records, for the reverse zones of any *public* address range, pointing back to a "localhost" name. It only shows a PTR record in the reverse zone for the 127.0.0/24 private range, which is what enables a reverse lookup for 127.0.0.1. Your ISP isn't (or shouldn't be) hosting reverse zones for any range under the 127/8 private block, on your behalf. That's your responsibility; hence the term "private". And, as Tony mentioned, these days it's highly questionable whether "localhost" entries in *any* zone, forward or reverse, serve any useful purpose, and may actually cause harm. - Kevin On Mon, Jun 21, 2021 at 12:48 PM wrote: > Hi, > > This book : > https://www.oreilly.com/library/view/dns-and-bind/0596100574/ch04.html > says I should manage the localhost within my zone (SOA) and reverse > lookup / PTR. > > I do not manage my revers lookup / PTR the IP owner does that. > > Any thoughts on managing the localhost within the zone file and PTR? > > Thanks!! > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to return REFUSED
[ Classification Level: GENERAL BUSINESS ]
I just checked the ARM, and it denotes that "match-recursive-only"
(boolean) still exists for views. So, you might be able to set up a special
view with that, as well as a negated match-clients, specifying allow-query
{ none; }. Put it as the first view, and both non-recursive queries, and
queries from your "recursive-users" ACL, will fall through to subsequent
views.
- Kevin
P.S. ISC's "understanding views" knowledgebase article doesn't mention
match-recursive-only, so there is a discrepancy there. Either the feature
has been removed, and the ARM documentation hasn't been updated to reflect
it, or the knowledgebase article only focuses on the most common
view-matching criteria, omitting match-recursive-only, since the use cases
for that are very rare.
On Wed, May 5, 2021 at 3:10 PM Axel Rau wrote:
> I have,
>
> allow-query { any; };
> allow-query-cache { recursive-users; };
> allow-recursion { recursive-users; };
>
> How can I make sure that none recursive-users get a REFUSED if query is
> recursive?
>
> Axel
>
> PS: I want to minimize the responses to this amplification attack:
> - - -
> 19:05:18.703238 185.230.55.130.30120 > 91.216.35.71.53: [no udp cksum] 1+
> RRSIG? pizzaseo.com.(30) (ttl 249, id 33043, len 58)
> 19:05:18.703568 91.216.35.71.53 > 185.230.55.130.30120: [udp sum ok] 1- q:
> RRSIG? pizzaseo.com. 0/13/14 ns: com. NS j.gtld-servers.net., com. NS
> m.gtld-servers.net., com. NS c.gtld-servers.net., com. NS
> b.gtld-servers.net., com. NS d.gtld-servers.net., com. NS
> e.gtld-servers.net., com. NS l.gtld-servers.net., com. NS
> f.gtld-servers.net., com. NS h.gtld-servers.net., com. NS
> i.gtld-servers.net., com. NS a.gtld-servers.net., com. NS
> k.gtld-servers.net., com. NS g.gtld-servers.net. ar: m.gtld-servers.net.
> A 192.55.83.30, l.gtld-servers.net. A 192.41.162.30, k.gtld-servers.net.
> A 192.52.178.30, j.gtld-servers.net. A 192.48.79.30, i.gtld-servers.net.
> A 192.43.172.30, h.gtld-servers.net. A 192.54.112.30, g.gtld-servers.net.
> A 192.42.93.30, f.gtld-servers.net. A 192.35.51.30, e.gtld-servers.net. A
> 192.12.94.30, d.gtld-servers.net. A 192.31.80.30, c.gtld-servers.net. A
> 192.26.92.30, b.gtld-servers.net. A 192.33.14.30, a.gtld-servers.net. A
> 192.5.6.30, m.gtld-servers.net. 2001:501:b1f9::30(490) (ttl 63, id
> 11754, len 518)
> - - -
> ---
> PGP-Key: CDE74120 ☀ computing @ chaos claudius
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind9 weighted load balancing
[ Classification Level: GENERAL BUSINESS ] Duplicate RRs are suppressed, as per the standards. RFC 2181, Section 5: Each DNS Resource Record (RR) has a label, class, type, and data. It is meaningless for two records to ever have label, class, type and data all equal - servers should suppress such duplicates if encountered That being said, a DNS-based load-balancer can probably do what you're looking for. - Kevin On Fri, Apr 30, 2021 at 3:44 PM Alperen Yılmaz wrote: > Hello everyone, > > There is a round robin resolving mechanism in bind9 where the server > chooses different records to resolve for each request, but is there a way > to assign weights so that the server resolves with different probabilities? > > All I could find about the topic was this old mail from the archive: > https://lists.isc.org/pipermail/bind-users/2007-April/066194.html > It says you can put duplicate records for increasing the weight, however > it also says that bind9 does not seem to support this. > > hostIN A 1.2.3.4 > IN A 1.2.3.4 > IN A 1.2.3.4 > IN A 1.2.3.5 > > > Thank you, > Alperen Yılmaz > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Configuring the location of named .jnl files
[ Classification Level: GENERAL BUSINESS ] Ivan, I've never done the Let's Encrypt thing myself, but from my skim of the documentation, it appears they want you to place a TXT record in a specific part of your domain's namespace hierarchy. I sincerely hope you're not trying to write the TXT record directly to the journal file. That could lead to corruption, or, at the very least, your changes could be overwritten, since journal files are written dynamically. The safe way to update DNS programmatically is through the Dynamic Update extension to DNS, typically via the "nsupdate" command-line utility, or via various libraries/modules of scripting languages like Perl or Python. One of the bash-based ACME client implementations linked from Let's Encrypt's webpage, for instance, is github.com/bruncsak/ght-acme.sh, and for the DNS-01 challenge method, it feeds some commands to nsupdate. The code is rather crude, assuming no crypto-based authentication on the server side, among other things, but it's at least a start on a recommended way to update DNS data. Better than mucking around with journal files. There is a learning curve associated with Dynamic Update. On the server side, for instance, you'll need to establish permissions via allow-update. Limiting updates to localhost at least would protect your DNS data from unauthorized changes from remote hosts, but ideally, you'd generate a key and use that. - Kevin On Sun, Apr 25, 2021 at 7:39 PM Ivan Avery Frey wrote: > I'm trying to obtain certificates from Let's Encrypt using the DNS-01 > challenge method. > > I just want to confirm that there is no option to configure the > directory for the .jnl files independently of the zone files. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Preventing a particular type of nameserver abuse
[ Classification Level: GENERAL BUSINESS ] It's not a "BIND" solution, per se, but if you have a sufficiently-sophisticated IPS (Intrusion Prevention System) you could have it simply drop all queries of a particular QNAME, or any particular combination of QNAME, QTYPE, QCLASS, before those packets even get to named. I know SNORT-based IPSes can do this, not so sure about other IPSes, but most of them have a custom rule/signature capability. As Grant pointed out, it wouldn't even need to be a dedicated IPS -- one could potentially leverage that IPS capabilities of a firewall. - kevin On Mon, Apr 12, 2021 at 4:10 PM Peter Coghlan wrote: > Hello, > > I have a nameserver which is authoritative for three or four domain names. > It receives around 1000 queries per day that could be regarded as plausably > legitimate. It receives around ten times that number of absive queries per > day from presumably spoofed ip addresses, the vast majority of them IN ANY > queries for the "sl" domain or for the root nameservers all of which my > nameserver responds to with return code 5 ie refused. > > In many cases, the source port is a low number such as 53, 80, 96 or 443 > for example which might make some sense if these were TCP queries but they > are all UDP queries and apart from attempting to target port 53, attempting > to target the other low UDP port numbers make no sense to me. > > I have searched high up and low down for any discussion about this kind > of abuse and found very little regarding abusive queries for the root > nameservers, none at all regarding the sl domain (although it is a > difficult > term to search for) and nothing at all regarding the oddball source ports > either. > > Even though the "refused" responses from my nameserver are "small", the > general persistence of the abusers over a long period of time suggests to > me that they are finding these queries effective for some kind of abuse, > perhaps by way of having a very large number of nameservers return them > (unless they are too stupid to care whether the queries are answered or > refused which I suppose is also possible). > > As far as I can see providing no response at all in any instance when a > code 5 refused response would normally be returned would be the appropriate > thing for my nameserver to do here and doing this would cause no > difficulties > at all with any legitimate queries or anyone who is not an abuser. Am I > correct here? > > I have searched for a way to prevent my nameserver from responding > to these queries at all in order to reduce the impact on the targets > of this abuse. All results of my research point to the use of > rate limiting as the only approach available for dealing with this > sort of issue. > > The abusive queries are clearly designed to circumvent the widely > suggested "errors-per-second 5" as they arrive in groups of five > per second and applying this limitation has little or no effect > on them. > > I have tried "errors-per-second 1" and this seems to reduce the abuse > by about four fifths but one fifth of it still manages to get through > and I don't find this acceptable. > > Instead, when I notice particularly heavy abuse of my nameserver, > I apply packet filtering to prevent the abusive queries from reaching > my nameserver and therefore to prevent it responding to them. I > also routinely packet filter all UDP dns queries with source port > numbers less than 1024 which I hope is the appropriate cutoff point. > > Is there anything else I can do to reduce the impact of this abuse > of my nameserver on others? > > My feeling is that mine can't be the only nameserver experiencing this > kind of abuse and that many nameserver admins probably would not even > notice it unless they had query logging or query-error logging turned > on and checked the logs. > > Regards, > Peter Coghlan. > > --Boundary_(ID_/cANmbMgveXk/KlZF+xdIQ)-- > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
