Discussion:
Preventing a particular type of nameserver abuse
Peter Coghlan
2021-04-12 19:41:13 UTC
Permalink
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Grant Taylor via bind-users
2021-04-12 20:39:44 UTC
Permalink
Post by Peter Coghlan
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?
You might consider filtering the egress code 5 from your server via
local firewall. I'm not entirely sure how to do this. But I suspect
that your platform's firewall has an option.

I know that I've used IPTable's "string" match extension to filter out
problematic inbound queries at times in the past. Perhaps something
like this could be pressed into service to filter outgoing code 5 replies.

You might be able to apply the same methodology to filter unwanted
inbound queries to completely avoid sending the reply code at all.
Post by Peter Coghlan
All results of my research point to the use of rate limiting as the
only approach available for dealing with this sort of issue.
There are always multiple ways to do things. It's a question of how
practical they are.
--
Grant. . . .
unix || die
Richard T.A. Neal
2021-04-12 22:55:59 UTC
Permalink
You might be able to apply the same methodology to filter unwanted inbound queries to completely avoid sending the reply code at all.
That's exactly what I do - I have some code that's watching for a frequent occurrence of these sorts of queries and then adds a firewall rule for a predetermined amount of time to simply drop the incoming packets at the firewall - this prevents them from reaching BIND in the first place and thus consuming system resource on the BIND server. And I say "predetermined amount of time" because that rule is then removed after a period of time in case the abuse was "unintentional" (ahem), or in case it came from a system using a non-static IP (i.e. a different user may be using that IP now, so I don't want to block them).

As well as requests for IN ANY sl, I also get a huge number for IN ANY census.gov. As with "sl" it's an attack based on the premise that the query is very small when compared to the volume of data being sent by return. And bear in mind the IP address purporting to send the query could very well be spoofed since it's UDP traffic - i.e. the malicious actor is potentially trying to get your DNS server to participate in a DDOS DNS attack against a third party. So by dropping those requests at the firewall I'm helping to ensure that my BIND server isn't a participant in that attack.

Richard.
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Julien Salort
2021-04-13 20:32:48 UTC
Permalink
Post by Richard T.A. Neal
That's exactly what I do - I have some code that's watching for a frequent occurrence of these sorts of queries and then adds a firewall rule for a predetermined amount of time to simply drop the incoming packets at the firewall - this prevents them from reaching BIND in the first place and thus consuming system resource on the BIND server. And I say "predetermined amount of time" because that rule is then removed after a period of time in case the abuse was "unintentional" (ahem), or in case it came from a system using a non-static IP (i.e. a different user may be using that IP now, so I don't want to block them).
Do you block specifically the dns queries in the firewall, or straight
out block the IP?

Reading this thread, I considered simply enabling the fail2ban
named-refused jail, but they advise against it because it would end up
blocking the victim rather than the attacker.

I understand that always ignoring these request may be bad if it causes
some timeout somewhere (though I still do not quite fully understand
what legitimate requests those may be for a server which only does
authoritative answers). Couldn't bind then have a built-in option to
ignore repeated attempts from a given host, and cap the number of error
codes sent to a given host per day?

Julien

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/
Carl Byington via bind-users
2021-04-13 21:04:14 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Post by Julien Salort
Reading this thread, I considered simply enabling the fail2ban
named-refused jail, but they advise against it because it would end up
blocking the victim rather than the attacker.
In the particular case of the .sl denied queries, I don't think these
are forged queries from the attack victim. Something else is going on
here. We see queries from systems like these, almost exclusively
consumer endpoints:

142-197-133-231.res.spectrum.com.
mta-162-154-195-235.kya.rr.com.
mobile-166-173-63-176.mycingular.net.
prg03s05-in-f193.1e100.net.
prg03s05-in-f1.1e100.net.
pool-173-79-59-79.washdc.fios.verizon.net.
174-30-51-96.wrbg.centurylink.net.
c-174-53-75-253.hsd1.va.comcast.net.
174-081-062-250.res.spectrum.com.
cpe-174-106-58-62.ec.res.rr.com.
192.sub-174-214-12.myvzw.com.
stop-looking-at-drifteds-ip.gov.
252.243.53.179.d.dyn.claro.net.do.
ip184-186-26-40.no.no.cox.net.
dsl-187-193-200-41-dyn.prod-infinitum.com.mx.
dsl-189-178-58-206-dyn.prod-infinitum.com.mx.
customer-189-216-112-75.cablevision.net.mx.
189.223.57.66.dsl.dyn.telnor.net.
212-149-157-12.rev.dnaip.fi.

It seems unlikely that someone is trying to attack those specific
endpoints. Unless the attack is *very* widely distributed and they are
actually attacking the ISP infrastructure. But in that case, this seems
to be a simultaneous attack on almost every major ISP, which I find
unlikely.


-----BEGIN PGP SIGNATURE-----

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHYHGhUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsG2xwCeNRKi5df2TdmaWyJQJhGCraf1UIoA
n0zp1wmsrlc9yeDc/wXJCy8xBToC
=Ir5g
-----END PGP SIGNATURE-----


_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Richard T.A. Neal
2021-04-13 22:42:28 UTC
Permalink
[snipped]
It seems unlikely that someone is trying to attack those specific endpoints. Unless the attack is *very* widely distributed and they are actually attacking the ISP infrastructure. But in that case, this seems to be a simultaneous attack on almost every major ISP, which I find unlikely.
Yes, another individual & I were discussing this off-list today. We wonder if those queries are from malware on infected hosts that are trying to determine whether a given nameserver can be used in a distributed reflection attack? The source IP is not spoofed (because it wants to get the answer), so if it gets either "refused" or a timeout then it knows that nameserver can't be used in the reflection attack. But if it gets a response with data then it knows it *can* be used in the reflection attack.

A lot of the "bad clients" that I block are also domestic IP addresses, and I've yet to come up with any other explanation so am always open to any plausible causes.

Best,
Richard.
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Carl Byington via bind-users
2021-04-14 00:18:29 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Post by Richard T.A. Neal
Yes, another individual & I were discussing this off-list today. We
wonder if those queries are from malware on infected hosts that are
trying to determine whether a given nameserver can be used in a
distributed reflection attack? The source IP is not spoofed (because
it wants to get the answer), so if it gets either "refused" or a
timeout then it knows that nameserver can't be used in the reflection
attack. But if it gets a response with data then it knows it *can* be
used in the reflection attack.
That makes sense, but in that case the malware is badly written (what a
surprise). In 28 hours a single dns server here saw 1182 such queries
from 80.2.150.110 = cpc99574-brnt1-2-0-cust621.4-2.cable.virginm.net.

I am now using the equivalent of fail2ban to firewall those clients.

-----BEGIN PGP SIGNATURE-----

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHY0yhUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsEkYwCfT3lTQO8NIdgSkMvAS03QmrnixiUA
n0IYWwS3qImFMByQzfUbWhK1v850
=D55z
-----END PGP SIGNATURE-----


_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Paul Kosinski via bind-users
2021-04-13 23:30:17 UTC
Permalink
Interesting observation. I just did lookups on 4 recent (< 24 hrs ago) 'sl/ANY/IN' queries logged by our BIND and got:

2 Comcast cable IPs (hsd1.tx.comcast.net and hsd1.ma.comcast.net)
1 OVH Hosting IP (Montreal)
1 Afranet IP (Tehran!)

The whois info for the OVH IP contains the line:

Comment: Failover IPs


On Tue, 13 Apr 2021 14:04:14 -0700
Post by Carl Byington via bind-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Post by Julien Salort
Reading this thread, I considered simply enabling the fail2ban
named-refused jail, but they advise against it because it would end up
blocking the victim rather than the attacker.
In the particular case of the .sl denied queries, I don't think these
are forged queries from the attack victim. Something else is going on
here. We see queries from systems like these, almost exclusively
142-197-133-231.res.spectrum.com.
mta-162-154-195-235.kya.rr.com.
mobile-166-173-63-176.mycingular.net.
prg03s05-in-f193.1e100.net.
prg03s05-in-f1.1e100.net.
pool-173-79-59-79.washdc.fios.verizon.net.
174-30-51-96.wrbg.centurylink.net.
c-174-53-75-253.hsd1.va.comcast.net.
174-081-062-250.res.spectrum.com.
cpe-174-106-58-62.ec.res.rr.com.
192.sub-174-214-12.myvzw.com.
stop-looking-at-drifteds-ip.gov.
252.243.53.179.d.dyn.claro.net.do.
ip184-186-26-40.no.no.cox.net.
dsl-187-193-200-41-dyn.prod-infinitum.com.mx.
dsl-189-178-58-206-dyn.prod-infinitum.com.mx.
customer-189-216-112-75.cablevision.net.mx.
189.223.57.66.dsl.dyn.telnor.net.
212-149-157-12.rev.dnaip.fi.
It seems unlikely that someone is trying to attack those specific
endpoints. Unless the attack is *very* widely distributed and they are
actually attacking the ISP infrastructure. But in that case, this seems
to be a simultaneous attack on almost every major ISP, which I find
unlikely.
-----BEGIN PGP SIGNATURE-----
iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHYHGhUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsG2xwCeNRKi5df2TdmaWyJQJhGCraf1UIoA
n0zp1wmsrlc9yeDc/wXJCy8xBToC
=Ir5g
-----END PGP SIGNATURE-----
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Richard T.A. Neal
2021-04-14 08:07:15 UTC
Permalink
...1 OVH Hosting IP (Montreal)
Comment: Failover IPs
Just out of interest, because I run some services on OVH, I know what that term means. When you rent a dedicated server from OVH you are assigned a single IPv4 address. Let's assume that you then want to use VMware or Hyper-V on that dedicated server to run some VMs - for many of those VMs you'll obviously want a distinct public IPv4 address. So OVH assign you what they term a "failover" block of IPv4 addresses. I don't know why they use that term, I just know that they do! So really it's just confirmation that it's an OVH customer (running a VM on a dedicated server) that is either the source IP or the spoofed target.

Best,
Richard.
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Jim Popovitch via bind-users
2021-04-14 10:22:04 UTC
Permalink
Post by Richard T.A. Neal
Just out of interest, because I run some services on OVH, I know what
that term means. When you rent a dedicated server from OVH you are
assigned a single IPv4 address. Let's assume that you then want to use
VMware or Hyper-V on that dedicated server to run some VMs - for many
of those VMs you'll obviously want a distinct public IPv4 address. So
OVH assign you what they term a "failover" block of IPv4 addresses. I
don't know why they use that term, I just know that they do! So really
it's just confirmation that it's an OVH customer (running a VM on a
dedicated server) that is either the source IP or the spoofed target.
Additional IP address are one thing, Failover IPs are something else.
In OVH land they unfortunately lease additional IPs using the same
french-to-english translated text form. OVH "Failover IPs" are probably
used more for adding an additional IP to a leased server
(VPS/Cloud/Physical), but the true purpose and benefit of OVH (and other
provider's) Failover IP is that the customer can have one or more
reserved IPs and quickly transfer them from server to server using the
OVH API. This is great for database resiliency/failover, etc.

-Jim P.

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Brett Cooper
2021-04-14 00:49:08 UTC
Permalink
Of the small amount of name servers I run, each and every name server
has had persistent attacks (I guess) in the form of "(sl): query (cache)
'sl/ANY/IN' denied". These attacks appear to be originating from
legitimate ISP resolvers, but the majority of the attacks appear to be
drones/malware of sorts. I am assuming the majority of these IP's are
spoofed. These attacks appeared to begin in Dec 2020 / Jan 2021, and
have persisted up to this writing. The worst of it was in Jan 2021 for
me.
Prior to me crafting a firewall rule, log monitoring and triggers, and
adding some loose rate limiting (The various *-per-second options), I
would see well more than 2500 queries an hour for the sl query from
copious amounts of IP's. It probably was much more than that, as it was
pegging a VPS single vCPU that I have to 100% - bad on me for not
hardening that particular virtual machine in the first place months ago.
The other name servers had similar attacks, but not to the same
magnitude by a long shot.
Today, and so far, the VPS above that was originally taking in such a
huge amount of sl queries, has temporarily blocked 78 unique IPv4
addresses. Every query from each of the IP's has been in the form of:
Apr 13 22:08:55 ns02 named[432]: client @0x7f98c063d430 50.99.83.201#80
(sl): query (cache) 'sl/ANY/IN' denied
Apr 13 22:08:55 ns02 named[432]: client @0x7f98c063d430 50.99.83.201#80
(sl): query (cache) 'sl/ANY/IN' denied
Apr 13 22:08:56 ns02 named[432]: client @0x7f98c063d430 50.99.83.201#80
(sl): query (cache) 'sl/ANY/IN' denied
[...]
Apr 13 22:44:02 ns02 named[9487]: client @0x7fc8740c7310
46.102.130.246#80 (sl): query (cache) 'sl/ANY/IN' denied
Apr 13 22:44:02 ns02 named[9487]: client @0x7fc8740c7310
46.102.130.246#80 (sl): query (cache) 'sl/ANY/IN' denied
Apr 13 22:44:04 ns02 named[9487]: client @0x7fc8740c7310
46.102.130.246#80 (sl): query (cache) 'sl/ANY/IN' denied

--Brett

------ Original Message ------
From: "Richard T.A. Neal" <***@richardneal.com>
To: "bind-***@lists.isc.org" <bind-***@lists.isc.org>
Sent: Apr 13, 2021 17:42:28 PM
Subject: FW: Preventing a particular type of nameserver abuse
Post by Richard T.A. Neal
[snipped]
It seems unlikely that someone is trying to attack those specific endpoints. Unless the attack is *very* widely distributed and they are actually attacking the ISP infrastructure. But in that case, this seems to be a simultaneous attack on almost every major ISP, which I find unlikely.
Yes, another individual & I were discussing this off-list today. We wonder if those queries are from malware on infected hosts that are trying to determine whether a given nameserver can be used in a distributed reflection attack? The source IP is not spoofed (because it wants to get the answer), so if it gets either "refused" or a timeout then it knows that nameserver can't be used in the reflection attack. But if it gets a response with data then it knows it *can* be used in the reflection attack.
A lot of the "bad clients" that I block are also domestic IP addresses, and I've yet to come up with any other explanation so am always open to any plausible causes.
Best,
Richard.
_______________________________________________
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
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Richard T.A. Neal
2021-04-13 22:37:22 UTC
Permalink
Do you block specifically the dns queries in the firewall, or straight out block the IP?
I specifically block both UDP 53 and TCP 53, but that's essentially a full block because these servers are only running BIND, nothing else.
Reading this thread, I considered simply enabling the fail2ban named-refused jail, but they advise against it because it would end up blocking the victim rather than the attacker.
I'm happy to be corrected by more knowledgeable people than me, but I don't necessarily agree with fail2ban's recommendation. By blocking traffic to the victim (which is what I'm doing by blocking traffic from the spoofed Source IP, because no inbound traffic means no outgoing replies) then I'm helping to protect the victim, or at least prevent my server being used in the reflection attack against that victim.


Best,
Richard.
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Alessandro Vesely
2021-04-14 10:46:44 UTC
Permalink
Post by Richard T.A. Neal
Reading this thread, I considered simply enabling the fail2ban named-refused jail, but they advise against it because it would end up blocking the victim rather than the attacker.
I'm happy to be corrected by more knowledgeable people than me, but I don't necessarily agree with fail2ban's recommendation. By blocking traffic to the victim (which is what I'm doing by blocking traffic from the spoofed Source IP, because no inbound traffic means no outgoing replies) then I'm helping to protect the victim, or at least prevent my server being used in the reflection attack against that victim.
That behavior might expose the victim to some kind of spear DoS. If the
attackers know the victim is going to seek services from .myzone, they can
spray the authoritative servers of .myzone with illegal requests apparently
coming from the victim's resolvers. That way, when the victim tries to resolve
needed.service.myzone it will be DoSsed.


Best
Ale
--
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Kevin Darcy via bind-users
2021-04-12 20:41:32 UTC
Permalink
[ 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
Post by Peter Coghlan
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
https://lists.isc.org/mailman/listinfo/bind-users
Paul Kosinski via bind-users
2021-04-13 04:16:53 UTC
Permalink
We also get *lots* of suspicious queries of the same kind, from various privileged and unprivileged ports, which I'm pretty sure are DDoS attempts. For example:

12-Apr-2021 23:44:17.767 security: info: client 107.213.131.17#80 (sl): query (cache) 'sl/ANY/IN' denied
12-Apr-2021 23:44:19.477 security: info: client 107.213.131.17#80 (sl): query (cache) 'sl/ANY/IN' denied
12-Apr-2021 23:45:00.908 security: info: client 98.229.97.172#80 (sl): query (cache) 'sl/ANY/IN' denied
12-Apr-2021 23:45:01.263 security: info: client 98.229.97.172#80 (sl): query (cache) 'sl/ANY/IN' denied

Besides not wanting to be an unwilling DDoS amplifier, these bother me because they're filling up my BIND/named log files.

I've tried using IPtables hashlimit to throttle the requests, but have had little success. I've even tried blocking the responses with IPtables packet content matching plus hashlimit, but that doesn't help my log files!

============================================

On Mon, 12 Apr 2021 20:41:13 +0100 (WET-DST)
Post by Peter Coghlan
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.
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Ondřej Surý
2021-04-13 05:12:02 UTC
Permalink
BIND 9.11 has minimal-any option that’s helpful to reduce the attack impact: https://www.isc.org/blogs/bind-release-911/

RRL should also help to limit the responses: https://kb.isc.org/docs/aa-01000

Usually the source IP is spoofed, so blocking it might be causing collateral damage in case the target of the attack is a resolver, but again in general case fail2ban that parses named log files might be a good option to add a temporary ban on the ip. Just bear in mind you are not blocking the attacker, but the victim.

Ondrej
--
Ondřej SurÃœ — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.
Post by Paul Kosinski via bind-users
12-Apr-2021 23:44:17.767 security: info: client 107.213.131.17#80 (sl): query (cache) 'sl/ANY/IN' denied
12-Apr-2021 23:44:19.477 security: info: client 107.213.131.17#80 (sl): query (cache) 'sl/ANY/IN' denied
12-Apr-2021 23:45:00.908 security: info: client 98.229.97.172#80 (sl): query (cache) 'sl/ANY/IN' denied
12-Apr-2021 23:45:01.263 security: info: client 98.229.97.172#80 (sl): query (cache) 'sl/ANY/IN' denied
Besides not wanting to be an unwilling DDoS amplifier, these bother me because they're filling up my BIND/named log files.
I've tried using IPtables hashlimit to throttle the requests, but have had little success. I've even tried blocking the responses with IPtables packet content matching plus hashlimit, but that doesn't help my log files!
============================================
Post by Paul Kosinski via bind-users
On Mon, 12 Apr 2021 20:41:13 +0100 (WET-DST)
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.
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users
Julien Salort
2021-04-13 09:31:31 UTC
Permalink
BIND 9.11 has minimal-any option that’s helpful to reduce the attack
impact: https://www.isc.org/blogs/bind-release-911/
<https://www.isc.org/blogs/bind-release-911/>
https://kb.isc.org/docs/aa-01000 <https://kb.isc.org/docs/aa-01000>
Usually the source IP is spoofed, so blocking it might be causing
collateral damage in case the target of the attack is a resolver, but
again in general case fail2ban that parses named log files might be a
good option to add a temporary ban on the ip. Just bear in mind you
are not blocking the attacker, but the victim.
I also have a lot of these (sl) queries in my logs.

Would it not be possible to have an option to tell bind to refrain from
answering to all unauthorized queries over UDP?

Is there really a usefulness to reply with code 5, instead of silently
ignoring the request?

A built-in option would be much easier than to require every server to
have a dedicated fancy firewall rule.

But I have no idea how much work it would be to add this feature in bind.


Cheers,


Julien

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-
Ondřej Surý
2021-04-13 09:47:38 UTC
Permalink
Yes, the legitimate client would be susceptible to spoofing. No answer means larger time windows to guess the port+msgid combination.

--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.
Is there really a usefulness to reply with code 5, instead of silently ignoring the request?
_______________________________________________
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-***@lists.isc
Anand Buddhdev
2021-04-13 10:02:25 UTC
Permalink
Hi Ondrej, and others,

A legitimate client, following a normal chain of referrals, has *no*
reason to query a server for zones it is not authoritative for. Most of
the time, such a query would only arrive at a name server from a naughty
client. And then, replying with any response, even REFUSED, is
satisfying this client's naughtiness.

I think it's quite okay for an authoritative name server to simply DROP
UDP queries for zones that it's not authoritative for. It's better to
ignore naughty clients, and give them the cold shoulder, and not
participate in reflection attacks using REFUSED responses.

Regards,
Anand
Post by Ondřej Surý
Yes, the legitimate client would be susceptible to spoofing. No
answer means larger time windows to guess the port+msgid combination.
_______________________________________________
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-***@lists.isc.org
ht
Tony Finch
2021-04-13 10:40:25 UTC
Permalink
Post by Anand Buddhdev
A legitimate client, following a normal chain of referrals, has *no*
reason to query a server for zones it is not authoritative for.
That's true for cases like .sl and other domains whose delegations are set
up correctly, but if a server is accidentally lame then it's helpful to
return REFUSED so that resolvers don't have to wait for a timeout before
trying other servers. A quick REFUSED will also avoid messing up the
resolver's per-server statistics that might interfere with queries for
authoritative zones.

Tony.
--
f.anthony.n.finch <***@dotat.at> https://dotat.at/
Southwest Fitzroy: Southeasterly 5 to 7, becoming variable 2 to 4 at
times in south. Moderate or rough, occasionally slight in south.
Thundery showers, fog patches. Moderate, occasionally very poor.

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
@lbutlr
2021-04-13 22:29:01 UTC
Permalink
Post by Anand Buddhdev
A legitimate client, following a normal chain of referrals, has *no*
reason to query a server for zones it is not authoritative for.
Well, that's not really true. A mobile user might have their device configured to always check their corporate DNS server first, for example, then fall back if that fails.

Refusing makes everything faster, ignoring breaks things and makes things slower.

When a DNS host refuses a query, it will not be queried again, wen it times out, is is still in the rotation.
Post by Anand Buddhdev
Most of the time, such a query would only arrive at a name server from a naughty
client.
Unlikely as there is no benefit to the "naughty" client. This is not a amplification attack, the refusal is a short packet, meaning the query from the client is probably larger than the response. Very inefficient for naughty clients.
Post by Anand Buddhdev
And then, replying with any response, even REFUSED, is
satisfying this client's naughtiness.
How?
Post by Anand Buddhdev
I think it's quite okay for an authoritative name server to simply DROP
UDP queries for zones
It's not.
Post by Anand Buddhdev
that it's not authoritative for. It's better to
ignore naughty clients, and give them the cold shoulder, and not
participate in reflection attacks using REFUSED responses.
How do you imagine this is a reflection attack? It is far too small to be an effective attack for anything.
--
'Today Is A Good Day For Someone Else To Die!' --Feet of Clay

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Anand Buddhdev
2021-04-14 07:48:48 UTC
Permalink
Post by @lbutlr
Post by Anand Buddhdev
A legitimate client, following a normal chain of referrals, has *no*
reason to query a server for zones it is not authoritative for.
Well, that's not really true. A mobile user might have their device
configured to always check their corporate DNS server first, for
example, then fall back if that fails.
I'm not talking of DNS *resolvers* here. I'm talking of authoritative
servers. If my authoritative server is authoritative for zones A, B and
C, then I should only get queries for those zones from legitimate
resolvers and clients. Queries for any other zones should *not* be
coming to my server. I shouldn't even be obliged to answer with REFUSED.
I should just be able to ignore those queries completely as junk.
Post by @lbutlr
Refusing makes everything faster, ignoring breaks things and makes things slower.
When a DNS host refuses a query, it will not be queried again, wen
it times out, is is still in the rotation.
This is a misbelief. When a resolver fails to get an answer from an
authoritative server (whether explicitly with a REFUSED response, or
just a timeout), it may lower the preference for that name server, but
will eventually retry, in case that server is able to answer for that
zone again.
Post by @lbutlr
Post by Anand Buddhdev
Most of the time, such a query would only arrive at a name server from a naughty
client.
Unlikely as there is no benefit to the "naughty" client. This is not
a
amplification attack, the refusal is a short packet, meaning the query
from the client is probably larger than the response. Very inefficient
for naughty clients.
Amplification isn't necessary for causing a DDoS towards an innocent
client. Even a high-enough packet rate (with small packets), can
overwhelm the upstream router of the client, or use up a significant
portion of the bandwidth. It can also cause problems for the client
whose networking stack has to deal with the packets. Whether an unwanted
packet is of 100 bytes or 1000 bytes, the network stack has to deal with
it somehow.
Post by @lbutlr
Post by Anand Buddhdev
And then, replying with any response, even REFUSED, is
satisfying this client's naughtiness.
How?
A spoofer gets to generate responses, however, small, towards an
innocent client.
Post by @lbutlr
Post by Anand Buddhdev
I think it's quite okay for an authoritative name server to simply DROP
UDP queries for zones
It's not.
If you try to SSH to a server that you're not supposed to connect to,
and it drops your packets, you won't complain right? So why are you so
bothered about a DNS server that drops queries it's not supposed to be
receiving? The DNS resolution protocol is clear. A resolver is supposed
to follow a chain of referrals, and not query any random server on the
Internet. So a legitimate resolver has no business querying random
authoritative servers for zones they're not supposed to serve.
Post by @lbutlr
Post by Anand Buddhdev
that it's not authoritative for. It's better to
ignore naughty clients, and give them the cold shoulder, and not
participate in reflection attacks using REFUSED responses.
How do you imagine this is a reflection attack? It is far too small
to be an effective attack for anything.
This is a short-sighted opinion. If just one authoritative server sends
out REFUSED responses towards an innocent, it won't matter. But if 1000
authoritative servers all send out REFUSED responses towards an innocent
IP address, their combined volume and packet rate *is* significant.

Regards,
Anand
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Ondřej Surý
2021-04-14 08:20:43 UTC
Permalink
Anand,

I understand that this topic is something you feel passionate about, but alas, it’s more complicated than just dropping REFUSED answers. Any lame delegation would be then susceptible to cache poisoning. Also it would be a protocol violation.

A small well-maintained authoritative server might be able to safely disable such answers, but it’s not cure-all, and it could quickly bite you back even in case of small authoritative servers. Imagine admin of example.org botches up delegation of vpn.example.org and would be able to poison the cache somewhere. There too many possible scenarios where things might go wrong and shifting the blame from lack of BCP38 implementation to well-behaved DNS servers isn’t particularly helpful.

I think dropping such answers would be very similar to: https://www.cvedetails.com/cve/CVE-2008-3337/ and https://doc.powerdns.com/authoritative/security-advisories/powerdns-advisory-2008-02.html

Ondřej
--
Ondřej SurÃœ — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.
Post by Anand Buddhdev
Post by @lbutlr
Post by Anand Buddhdev
A legitimate client, following a normal chain of referrals, has *no*
reason to query a server for zones it is not authoritative for.
Well, that's not really true. A mobile user might have their device
configured to always check their corporate DNS server first, for
example, then fall back if that fails.
I'm not talking of DNS *resolvers* here. I'm talking of authoritative
servers. If my authoritative server is authoritative for zones A, B and
C, then I should only get queries for those zones from legitimate
resolvers and clients. Queries for any other zones should *not* be
coming to my server. I shouldn't even be obliged to answer with REFUSED.
I should just be able to ignore those queries completely as junk.
Post by @lbutlr
Refusing makes everything faster, ignoring breaks things and makes things slower.
When a DNS host refuses a query, it will not be queried again, wen
it times out, is is still in the rotation.
This is a misbelief. When a resolver fails to get an answer from an
authoritative server (whether explicitly with a REFUSED response, or
just a timeout), it may lower the preference for that name server, but
will eventually retry, in case that server is able to answer for that
zone again.
Post by @lbutlr
Post by Anand Buddhdev
Most of the time, such a query would only arrive at a name server from a naughty
client.
Unlikely as there is no benefit to the "naughty" client. This is not
a
amplification attack, the refusal is a short packet, meaning the query
from the client is probably larger than the response. Very inefficient
for naughty clients.
Amplification isn't necessary for causing a DDoS towards an innocent
client. Even a high-enough packet rate (with small packets), can
overwhelm the upstream router of the client, or use up a significant
portion of the bandwidth. It can also cause problems for the client
whose networking stack has to deal with the packets. Whether an unwanted
packet is of 100 bytes or 1000 bytes, the network stack has to deal with
it somehow.
Post by @lbutlr
Post by Anand Buddhdev
And then, replying with any response, even REFUSED, is
satisfying this client's naughtiness.
How?
A spoofer gets to generate responses, however, small, towards an
innocent client.
Post by @lbutlr
Post by Anand Buddhdev
I think it's quite okay for an authoritative name server to simply DROP
UDP queries for zones
It's not.
If you try to SSH to a server that you're not supposed to connect to,
and it drops your packets, you won't complain right? So why are you so
bothered about a DNS server that drops queries it's not supposed to be
receiving? The DNS resolution protocol is clear. A resolver is supposed
to follow a chain of referrals, and not query any random server on the
Internet. So a legitimate resolver has no business querying random
authoritative servers for zones they're not supposed to serve.
Post by @lbutlr
Post by Anand Buddhdev
that it's not authoritative for. It's better to
ignore naughty clients, and give them the cold shoulder, and not
participate in reflection attacks using REFUSED responses.
How do you imagine this is a reflection attack? It is far too small
to be an effective attack for anything.
This is a short-sighted opinion. If just one authoritative server sends
out REFUSED responses towards an innocent, it won't matter. But if 1000
authoritative servers all send out REFUSED responses towards an innocent
IP address, their combined volume and packet rate *is* significant.
Regards,
Anand
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users
s***@nethelp.no
2021-04-14 08:30:55 UTC
Permalink
Post by Anand Buddhdev
I'm not talking of DNS *resolvers* here. I'm talking of authoritative
servers. If my authoritative server is authoritative for zones A, B and
C, then I should only get queries for those zones from legitimate
resolvers and clients. Queries for any other zones should *not* be
coming to my server. I shouldn't even be obliged to answer with REFUSED.
I should just be able to ignore those queries completely as junk.
Agree that you should be able to ignore them. But as a practical matter,
ignoring them *may* result in the question being asked again and again,
while REFUSED *may* stop the client from asking more.

I run one of the authoritative name servers for no (Norway). That name
server receives its share of completely irrelevant queries, e.g. (25
queries from just now):

NS? .
ANY? sl.
ANY? sl.
A? d2cnv2pop2xy4v.cloudfront.net.
NS? .
A? www.google.li.
A? tussilagobarnehage-no02c.mail.protection.outlook.com.
A? handball-havdur-no.mail.protection.outlook.com.
A? tronica-no.mail.protection.outlook.com.
A? storage-support.glb.itcs.hpe.com.
A? msgr-latest.c10r.facebook.com.
NS? .
A? mqtt.c10r.facebook.com.
A? inappcheck.itunes.apple.com.edgekey.net.
Type65? inappcheck.itunes.apple.com.edgekey.net.
Type65? e69896.dscapi6.akamaiedge.net.
A? e69896.dscapi6.akamaiedge.net.
A? javvs-no.mail.protection.outlook.com.
A? clients4.google.com.
A? clients.l.google.com.
A? storage-support.glb.itcs.hpe.com.
A? au-bg-shim.trafficmanager.net.
NS? .
ANY? sl.
ANY? sl.

And here again we see the queries for .sl. In any case, the volume of
these queries is so low (on the order of 0.1% of the total) that I
don't really care. I'm not going to spend any time worrying about the
resource usage of these queries.

Steinar Haug, Nethelp consulting, ***@nethelp.no
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Tony Finch
2021-04-14 14:19:42 UTC
Permalink
Post by s***@nethelp.no
Agree that you should be able to ignore them. But as a practical matter,
ignoring them *may* result in the question being asked again and again,
while REFUSED *may* stop the client from asking more.
REFUSED leads to retries too: if the client is a legit resolver it will
retry using the other authoritative servers. For example, when I changed
private.cam.ac.uk from refusing external queries to replying with an empty
answer, the load on our auth servers dropped by half.

Retries following REFUSED are also one reason why the RFC 8482 minimal-any
option is not refuse-any: when an ANY attack is bouncing off a recursive
server, the authoritative server can reduce the power of the attack by
returning a small cacheable answer. This reduces the load on the
authoritative servers (no retries), and on the recursive servers (no need
to recurse and retry), and reduces the volume of the attack traffic.

Probe traffic like these sl/IN/ANY queries is a very different matter. I
wouldn't expect any kind of reasonable behaviour, so it makes sense to
drop the queries as early as possible.

Tony.
--
f.anthony.n.finch <***@dotat.at> https://dotat.at/
North Fitzroy, Sole: Easterly or southeasterly 4 to 6. Moderate or
rough. Showers at first in northwest Fitzroy, otherwise fair. Good.

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
@lbutlr
2021-04-15 01:35:40 UTC
Permalink
Post by Anand Buddhdev
This is a short-sighted opinion. If just one authoritative server sends
out REFUSED responses towards an innocent, it won't matter. But if 1000
authoritative servers all send out REFUSED responses towards an innocent
IP address, their combined volume and packet rate *is* significant.
Is it?

How big is a REFUSED response?

Even if it is 100 bytes (and I think it is not that large, but I cannot find it), 1000 refused would be 100K.

How many thoudanss of servers do you need in this "DDoS" to overwhelm a pretty average connection? (My home connection is only 200Mbps down).

Granted, a million machines would be generating a 100MB of data, which is insignificantes, but the number of pockets at that scale would probably be an issue. But is a million servers realistic?

I don't think calling this a DDoS is accurate. It is more likely;y there is a known exploit for some servers and they are probing or it is some script kiddie just blasting out packets hoping to get lucky.
--
"Are you pondering what I'm pondering?"
"I think so, Mr. Brain, but if the sun'll come out tomorrow, what's
it doing right now?"

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Mark Andrews
2021-04-15 02:44:30 UTC
Permalink
Post by @lbutlr
Post by Anand Buddhdev
This is a short-sighted opinion. If just one authoritative server sends
out REFUSED responses towards an innocent, it won't matter. But if 1000
authoritative servers all send out REFUSED responses towards an innocent
IP address, their combined volume and packet rate *is* significant.
Is it?
How big is a REFUSED response?
Approximately the same size as the request. It depends on the request and
the server’s capabilities.
Post by @lbutlr
Even if it is 100 bytes (and I think it is not that large, but I cannot find it), 1000 refused would be 100K.
How many thoudanss of servers do you need in this "DDoS" to overwhelm a pretty average connection? (My home connection is only 200Mbps down).
Granted, a million machines would be generating a 100MB of data, which is insignificantes, but the number of pockets at that scale would probably be an issue. But is a million servers realistic?
I don't think calling this a DDoS is accurate. It is more likely;y there is a known exploit for some servers and they are probing or it is some script kiddie just blasting out packets hoping to get lucky.
If you really want to do something, talk to your local politician and get laws written up that require ISPs to deploy BCP38. This is completely fixable if ISPs deploy BCP38 filters on themselves and all of their customers. There is some CAPEX and OPEX to deploying BCP38 filters and making it a requirement under law levels the playing field between ISPs.
Post by @lbutlr
--
"Are you pondering what I'm pondering?"
"I think so, Mr. Brain, but if the sun'll come out tomorrow, what's
it doing right now?"
_______________________________________________
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
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-user
Borja Marcos
2021-04-13 09:53:08 UTC
Permalink
Is there really a usefulness to reply with code 5, instead of silently ignoring the request?
Yes, we do it.

imagine a customer who uses to connect from different locations (hence different ISPs) and for whatever
reason keeps a static list of resolvers in resolv.conf.

If the customer queries your DNS servers from a non authorized location and they ignore the request you
will force the resolver to time out. If, however, the query is refused, the resolver will send it to the next
server in the list.

Being short messages means they are useless for a DDoS. Anyway we keep an eye on it.





Borja.

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Tony Finch
2021-04-13 10:29:24 UTC
Permalink
Post by Peter Coghlan
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.
There have been several helpful replies, but to be honest I wouldn't spend
too much effort on low levels of abuse unless you want to use it as a
learning exercise. (I would care if it was multiple abusive queries per
second...)
Post by Peter Coghlan
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.
RRL is designed to avoid interfering with legitimate traffic, but that
does mean that some abuse traffic leaks through. Its aim is to stop
amplification, so that the attackers don't get any benefit from abusing
your server.

But it sounds to me like your problem traffic is more like background
radiation (e.g. probes) than active abuse; if so it's likely that RRL will
not deter them.
Post by Peter Coghlan
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.
If all the problem traffic is sl. IN ANY, then I suggest permanently
leaving in place a filter to drop those queries. Use a string match rule,
like Grant Taylor suggested, but match the queries instead of the
responses, so they don't clutter your query logs.

Tony.
--
f.anthony.n.finch <***@dotat.at> https://dotat.at/
Southwest Shannon: Southeasterly 4 or 5 increasing 6. Moderate
becoming rough. Fair. Good.

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Paul Kosinski via bind-users
2021-04-14 16:58:55 UTC
Permalink
Interesting, although we host different domains, in and from different geographic areas, we got the same queries as yours on the same day, with some at about the same time (we're EDT).

13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074 (sl): query (cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:58.638 security: info: client 76.20.145.58#3074 (sl): query (cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:59.365 security: info: client 76.20.145.58#3074 (sl): query (cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:59.366 security: info: client 76.20.145.58#3074 (sl): query (cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:03.568 security: info: client 76.20.145.58#3074 (sl): query (cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:03.820 security: info: client 76.20.145.58#3074 (sl): query (cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:04.546 security: info: client 76.20.145.58#3074 (sl): query (cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:04.546 security: info: client 76.20.145.58#3074 (sl): query (cache) 'sl/ANY/IN' denied


13-Apr-2021 03:04:25.379 security: info: client 92.204.191.45#2927 (sl): query (cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:25.553 security: info: client 92.204.191.45#2927 (sl): query (cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:26.539 security: info: client 92.204.191.45#2927 (sl): query (cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:26.539 security: info: client 92.204.191.45#2927 (sl): query (cache) 'sl/ANY/IN' denied

This is not a complete list, but they all were on Apr 13 (and near your times).

==========================================================================

On Tue, 13 Apr 2021 15:23:20 +0100 (WET-DST)
Hi Paul,
Many thanks for your reply. Yours is exactly the sort of reply I was hoping
for because I feel like I have been banging my head on a brick wall for months
now looking for someone else who cares whether their nameserver is an engine
for this sort of abuse. I was beginning to wonder if I was the only person
in the world seeing this kind of abuse and regarding it as a problem.
I will leave another while to see if more clueful replies like yours arrive
and then I will reply back to the list again myself to try to move the thread
in the direction of requesting a solution which can easily be implemented by
anyone and does not involve packet filters, firewalls, IPtables and so on.
In the meantime, I thought it would be interesting to see if I also got
the same abusive queries you logged below. Unfortunately (or fortunately)
I am packet filtering incoming queries with source port 80 so they did not
make it as far as the logs in my case. Here are a few that did make it to
my logs. Maybe they are in yours too?
Regards,
Peter Coghlan.
13-Apr-2021 06:20:10.867 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
13-Apr-2021 06:20:11.396 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
13-Apr-2021 06:20:11.743 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
13-Apr-2021 06:20:11.804 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
13-Apr-2021 07:04:32.746 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
13-Apr-2021 07:04:32.935 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
13-Apr-2021 07:04:33.993 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
13-Apr-2021 07:04:34.047 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Carl Byington via bind-users
2021-04-14 17:47:40 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Post by Paul Kosinski via bind-users
Interesting, although we host different domains, in and from different
geographic areas, we got the same queries as yours on the same day,
with some at about the same time (we're EDT).
13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074
(sl): query (cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:58.638 security: info: client 76.20.145.58#3074
(sl): query (cache) 'sl/ANY/IN' denied
These times are PDT (-0700)

Apr 12 23:18:13 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
(sl): view normal: query (cache) 'sl/ANY/IN' denied
Apr 12 23:18:13 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
(sl): view normal: query (cache) 'sl/ANY/IN' denied
....
Apr 12 23:19:15 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
(sl): view normal: query (cache) 'sl/ANY/IN' denied

So either 76.20.145.58, or someone forging that source ip, made queries
to servers in (+0000), (-0400), and (-0700) at the same time. Malware
running on 76.20.145.58 is one explanation. Would the REFUSED replies
carry enough information from the original query to be used as a covert
communication channel into something listening on 76.20.145.58?

vpn over dns query-refused replies? That seems a bit far-fetched.



-----BEGIN PGP SIGNATURE-----

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHcqsRUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsEvgACgh6muAlNI6qk99Rd9sLaSp29IESQA
njJo7E3ajD0Yw/ja7VOStNhgkxDd
=tlQQ
-----END PGP SIGNATURE-----


_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Sten Carlsen
2021-04-14 18:21:56 UTC
Permalink
Thanks

Sten
Signed PGP part
Post by Paul Kosinski via bind-users
Interesting, although we host different domains, in and from different
geographic areas, we got the same queries as yours on the same day,
with some at about the same time (we're EDT).
13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074
(sl): query (cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:58.638 security: info: client 76.20.145.58#3074
(sl): query (cache) 'sl/ANY/IN' denied
These times are PDT (-0700)
(sl): view normal: query (cache) 'sl/ANY/IN' denied
(sl): view normal: query (cache) 'sl/ANY/IN' denied
....
(sl): view normal: query (cache) 'sl/ANY/IN' denied
So either 76.20.145.58, or someone forging that source ip, made queries
to servers in (+0000), (-0400), and (-0700) at the same time. Malware
running on 76.20.145.58 is one explanation. Would the REFUSED replies
carry enough information from the original query to be used as a covert
communication channel into something listening on 76.20.145.58?
vpn over dns query-refused replies? That seems a bit far-fetched.
I wonder if it may be an attempt to keep track of the Internet speed across the world?
If you send off these queries at the same time to different locations what would the round trip time tell you?
It would probably be a fair assessment of the speed of the net - might be a replacement for pings.
Peter Coghlan
2021-04-14 16:46:40 UTC
Permalink
Post by Tony Finch
Post by Peter Coghlan
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.
There have been several helpful replies, but to be honest I wouldn't spend
too much effort on low levels of abuse unless you want to use it as a
learning exercise. (I would care if it was multiple abusive queries per
second...)
I think a learning exercise would be very useful as there seems to be very
little awareness of this issue and I found it very difficult to find any
discussion or analysis of it anywhere. From the replies to my posting here,
it seems apparant that my nameserver is definately not the only one which is
experiencing this abuse.

I am seeing abusive query rates of 5 per second for sustained periods of the
day. As far as I can see this is specially designed to get in under the
widely suggested "errors-per-second 5" rate limiting.
Post by Tony Finch
Post by Peter Coghlan
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.
RRL is designed to avoid interfering with legitimate traffic, but that
does mean that some abuse traffic leaks through. Its aim is to stop
amplification, so that the attackers don't get any benefit from abusing
your server.
Sure but something is clearly benefitting from the abuse because it is
going on day in, day out for months now and it it is apparantly happening
on servers other than mine too.

Also, my nameserver doesn't receive any legitimate traffic at all which my
nameserver replies to with "refused" responses.
Post by Tony Finch
But it sounds to me like your problem traffic is more like background
radiation (e.g. probes) than active abuse; if so it's likely that RRL will
not deter them.
I wouldn't describe it as background radiation or probes. It doesn't seem
to be caused by misconfigured or faulty resolvers or anything of that nature.
Exactly the same queries (including the same source port and query id) are
repeated over and over again whether a "refused" reply is provided or not.
It seems pretty clearly abusive to me even if the exact purpose of the abuse
is not so obvious yet.
Post by Tony Finch
Post by Peter Coghlan
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.
If all the problem traffic is sl. IN ANY, then I suggest permanently
leaving in place a filter to drop those queries. Use a string match rule,
like Grant Taylor suggested, but match the queries instead of the
responses, so they don't clutter your query logs.
From what I can see, roughly half of the problem traffic is sl/IN/ANY and the
other half is ./IN/ANY. Some of the problem traffic has source ports less
than 1024 and some doesn't. ([tos 0x8] is often thrown in for good measure
too. I wonder what that's about?)

It is possible for me to apply filtering that catches most or maybe all of
this but this only fixes the problem on my server and does nothing to prevent
the abuse of lots of other servers out there.

Besides, I'm not really that concerned about the effect on my nameserver, I am
more concerned about the effect of the abusive traffic being reflected by
my nameserver and various other nameservers onto innocent third parties
with little or no awareness that this is happening.

Also, I don't believe a sufficiently portable filtering mechanism exists
which can be deployed across all the platforms that bind can be deployed
on.

Even if everybody could start filtering queries for "sl" and the root
nameservers, what's to stop the abusers moving on to using a different
domain name when they discover this filtering being applied?

Instead, isn't it the case that bind knows what domains it is authoritative
for (or which ones it is supposed to be authoritative for) and bind is
therefore in the ideal position to know which queries are abusive and which
are not rather than wrapping kludgy filtering mechanisms around it?

If there is a resistance to having bind ignore the abusive queries
altogether, could we at least have something like "errors-per-minute 1"
which would reduce the problem by a factor of 60 compared with
"errors-per-second 1"? "errors-per-hour 1" would be even better still :-)

Regards,
Peter Coghlan.
Post by Tony Finch
Tony.
--
Southwest Shannon: Southeasterly 4 or 5 increasing 6. Moderate
becoming rough. Fair. Good.
_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Tony Finch
2021-04-14 20:55:29 UTC
Permalink
Post by Peter Coghlan
I wouldn't describe it as background radiation or probes. It doesn't seem
to be caused by misconfigured or faulty resolvers or anything of that nature.
Hmm, maybe air pollution would be a better metaphor? What I mean is the
kind of continuous low levels of abuse that's definitely harmful in
aggregate, but it's not clear who is responsible or what can be done about
it. These sl/IN/ANY queries are exactly the kind of thing I had in mind.
Post by Peter Coghlan
It is possible for me to apply filtering that catches most or maybe all of
this but this only fixes the problem on my server and does nothing to prevent
the abuse of lots of other servers out there.
Yeah, it's a wicked problem. There's very little one can do as a server
operator except for relatively limited mitigations. The real fix is to
trace back the traffic and do malware analysis of the sources and all that
fun forensic blue team stuff that is a very long way away from my job or
abilities :-) Before DNS I did anti-spam stuff for several years so I have
had to make peace with protecting my systems and users from the worst of
the abuse, without being in a position to do much about the causes, other
than helping to keep our networks clean.
Post by Peter Coghlan
Instead, isn't it the case that bind knows what domains it is authoritative
for (or which ones it is supposed to be authoritative for) and bind is
therefore in the ideal position to know which queries are abusive and which
are not rather than wrapping kludgy filtering mechanisms around it?
Not always, sadly, because of misconfigured (lame) delegations. See the
earlier messages from me and Ondřej -

https://lists.isc.org/pipermail/bind-users/2021-April/104408.html

https://lists.isc.org/pipermail/bind-users/2021-April/104423.html
Post by Peter Coghlan
If there is a resistance to having bind ignore the abusive queries
altogether, could we at least have something like "errors-per-minute 1"
which would reduce the problem by a factor of 60 compared with
"errors-per-second 1"? "errors-per-hour 1" would be even better still :-)
There is probably something that might improve things, but I'm not sure
what it is. I think the minimum RRL rate of 1 per second might be intended
to work with resolver retry times. I'm wary of suppressing error responses
without thinking through the possible consequences.

Tony.
--
f.anthony.n.finch <***@dotat.at> https://dotat.at/
Viking, North Utsire, South Utsire, Forties: Northerly or
northwesterly 3 to 5, becoming variable 3 or less later. Moderate
becoming slight. Showers. Good.
Peter Coghlan
2021-04-14 20:58:46 UTC
Permalink
Post by Tony Finch
Post by Peter Coghlan
Instead, isn't it the case that bind knows what domains it is authoritative
for (or which ones it is supposed to be authoritative for) and bind is
therefore in the ideal position to know which queries are abusive and which
are not rather than wrapping kludgy filtering mechanisms around it?
Not always, sadly, because of misconfigured (lame) delegations. See the
earlier messages from me and Ondřej -
https://lists.isc.org/pipermail/bind-users/2021-April/104408.html
https://lists.isc.org/pipermail/bind-users/2021-April/104423.html
But I don't have any misconfigured (lame) delegations and even if I had,
I think I would rather put up with the consequences of the lame delegations
on rare occasions than having my nameserver foisting abuse on others all
the time.

Those that are more worried about having lame delegations don't have to
use any option that would cause error responses to be dropped.

(I've been there and done that with the lame delegations years ago. When
I fouled up the master, the slaves toiled on regardless, presumably because
the master returned "non-authoritative" or "refused" and nobody noticed there
was any problem. Meanwhile, the slaves were unable to get zone transfers
from the fouled up master and much much later, they hit whatever the relevant
timeout was and the zone failed completely. There then followed lots of head
scratching as to why the domain had failed when nothing had changed recently.
I think I would have preferred if it had failed immediately I made the
incorrect change (and I probably failed to notice bind trying to tell me about
it too) because I would have known exactly where to look for the problem.)
Post by Tony Finch
Post by Peter Coghlan
If there is a resistance to having bind ignore the abusive queries
altogether, could we at least have something like "errors-per-minute 1"
which would reduce the problem by a factor of 60 compared with
"errors-per-second 1"? "errors-per-hour 1" would be even better still :-)
There is probably something that might improve things, but I'm not sure
what it is. I think the minimum RRL rate of 1 per second might be intended
to work with resolver retry times. I'm wary of suppressing error responses
without thinking through the possible consequences.
But isn't this what the filtering that has been suggested is going to do?
Except isn't the filtering marginally more likely to get fouled up because
of the danger of not keeping the filtering configuration and the bind
configuration in sync with each other?

Regards,
Peter Coghlan.
Post by Tony Finch
Tony.
--
Viking, North Utsire, South Utsire, Forties: Northerly or
northwesterly 3 to 5, becoming variable 3 or less later. Moderate
becoming slight. Showers. Good.
_______________________________________________
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-***@lists.isc.org
https://
Loading...