Re: Dnssec-policy Purge-keys
On Monday, 12 April 2021 01:18:11 CDT @lbutlr via bind-users wrote:
> Doe anyone know the syntax for using purge-keys in 9.16.13? I've search and
> all I can find is notes that it was added. I've tried a couple of things, but
> I am shooting in the dark. I cannot redefine the "default" policy as that
> gives and error and simply putting "purge-keys P90D;" or "dnssec-policy
> purge-keys P90D;" in options files.
>
> I'm sure it's simple, but simply what?
>
As per the BIND9 ARM section 4.2.21, the purge-keys statement must be contained
within a dnssec-policy statement. A policy such as this one is working well for
me:
dnssec-policy Kreme {
keys {
ksk lifetime P1Y algorithm ECDSA256;
zsk lifetime P3M algorithm ECDSA256;
};
purge-keys 30d;
nsec3param;
};
--
Greg
4.2.21 dnssec-policy Statement Grammar
dnssec-policy {
dnskey-ttl ;
keys { ( csk | ksk | zsk ) [ ( key-directory ) ] lifetime
algorithm [ ]; ... };
max-zone-ttl ;
nsec3param [ iterations ] [ optout ] [
salt-length ];
parent-ds-ttl ;
parent-propagation-delay ;
publish-safety ;
purge-keys ;
retire-safety ;
signatures-refresh ;
signatures-validity ;
signatures-validity-dnskey ;
zone-propagation-delay ;
};
___
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: Still seeing some ALG-7 DNSSE
On 11-04-2021 01:22, @lbutlr wrote:
On 06 Apr 2021, at 01:13, Matthijs Mekking wrote:
In 9.16.13, a new "dnssec-policy" option is introduced, "purge-keys". By
default the keys are retained for 90 days after their latest usage. So in that case keys will be
cleaned up automatically.
Excellent. Does that go in the zone record with default, or does it replace
default> I don't see the syntax in the release notes.
If you don't set "purge-keys" it will be retained for 90 days.
Otherwise, set it inside the 'dnssec-policy' you are using. In other
words, If you want something else, use this:
dnssec-policy "myway" {
purge-keys P30D;
...
// other policy options
};
Or do I add a
dnssec-policy "default" {
purge-keys 30; // (or is that field seconds?)
}
Or will that mess up the predefined for default?
First, you cannot (re)configure "default" policy, it is a builtin policy.
You can configure a new policy and just add a single option
"purge-keys". Zones with that policy will act the same as the default
policy except for how long to retain keys.
The field is a ttl value or a ISO 8601 duration. So a number is treated
as seconds. If you want 30 days, use 30d or P30D.
Cheers,
Matthijs
___
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: Still seeing some ALG-7 DNSSE
> On 12 Apr 2021, at 01:12, Matthijs Mekking wrote:
>
>
>
> On 11-04-2021 01:22, @lbutlr wrote:
>> On 06 Apr 2021, at 01:13, Matthijs Mekking wrote:
>>> In 9.16.13, a new "dnssec-policy" option is introduced, "purge-keys". By
>>> default the keys are retained for 90 days after their latest usage. So in
>>> that case keys will be cleaned up automatically.
>> Excellent. Does that go in the zone record with default, or does it replace
>> default> I don't see the syntax in the release notes.
>
> If you don't set "purge-keys" it will be retained for 90 days. Otherwise, set
> it inside the 'dnssec-policy' you are using. In other words, If you want
> something else, use this:
>
> dnssec-policy "myway" {
>purge-keys P30D;
>...
>// other policy options
> };
I am using dnssec-policy default, not my own dnssec policy
>> Or do I add a
>> dnssec-policy "default" {
>> purge-keys 30; // (or is that field seconds?)
>> }
>> Or will that mess up the predefined for default?
>
> First, you cannot (re)configure "default" policy, it is a builtin policy.
I found that out, yes.
> You can configure a new policy and just add a single option "purge-keys".
> Zones with that policy will act the same as the default policy except for how
> long to retain keys.
So, I have to add a new policy to every zone? That's annoying. I was hoping to
force the old keys to go away faster.
> The field is a ttl value or a ISO 8601 duration. So a number is treated as
> seconds. If you want 30 days, use 30d or P30D.
Thank you, I may just wait and see what happens. Though no alg-7 files have
been deleted yet, even for domains that are not reporting any alg-6 o dnsviz
(and they are updated every hour) along with the lag-13 key.
--
I CAN BE ROBBED BUT NEVER DENIED, I TOLD MYSELF. WHY WORRY? 'I too
cannot be cheated,' snapped Fate. SO I HAVE HEARD.
___
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
Zone 126.0.0.1 has 0 SOIA records
I restored a backup of my named.conf after a little bit of an oops. The file is the same exact file as it was yesterday, bt on starting bind I get: named[24161] named[24161] BIND 9 is maintained by Internet Systems Consortium, named[24161] Inc. (ISC), a non-profit 501(c)(3) public-benefit named[24161] corporation. Support and training for BIND 9 are named[24161] available at https://www.isc.org/support named[24161] named[24161] command channel listening on 127.0.0.1#953 named[24161] zone localhost/IN: CDS/CDNSKEY consistency checks failed named[24161] zone localhost/IN: not loaded due to errors. named[24161] /usr/local/etc/namedb/working/localhost-reverse.db:3: ignoring out-of-zone data (0.ip6.arpa) named[24161] /usr/local/etc/namedb/working/localhost-reverse.db:17: ignoring out-of-zone data (1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa) named[24161] /usr/local/etc/namedb/working/localhost-reverse.db:18: ignoring out-of-zone data (1.0.0.0.ip6.arpa) named[24161] zone 127.in-addr.arpa/IN: has 0 SOA records named[24161] zone 127.in-addr.arpa/IN: has no NS records named[24161] zone 127.in-addr.arpa/IN: not loaded due to errors. named[24161] zone 0.ip6.arpa/IN: CDS/CDNSKEY consistency checks failed named[24161] zone 0.ip6.arpa/IN: not loaded due to errors. named[24161] all zones loaded named[24161] DNS format error from 82.192.82.228#53 resolving 112.242.54.110.in-addr.arpa/PTR for 65.121.55.44#55292: Name in-addr.arpa (SOA) not subdomain of zone 242.54.110.in-addr.arpa -- invalid response named[24161] DNS format error from 82.192.82.228#53 resolving 112.242.54.110.in-addr.arpa/PTR for 127.0.0.1#27795: Name in-addr.arpa (SOA) not subdomain of zone 242.54.110.in-addr.arpa -- invalid response This last repeats periodically Stoping and starting named don't clear the error, but named appears to be fine (checking domains returns expected results). Key files are updating every hour as expected. The secondary servers are in sync… -- "Life is one damned kitten after another." Mehitabel the Alley Cat ___ 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: Zone 126.0.0.1 has 0 SOIA records
Perhaps inspect the zone file? Also the CDS/CDNSKEY consistency checks stick out. Perhaps remove them from the unsigned zone files? Best regards, Matthijs On 12-04-2021 14:52, @lbutlr wrote: I restored a backup of my named.conf after a little bit of an oops. The file is the same exact file as it was yesterday, bt on starting bind I get: named[24161] named[24161] BIND 9 is maintained by Internet Systems Consortium, named[24161] Inc. (ISC), a non-profit 501(c)(3) public-benefit named[24161] corporation. Support and training for BIND 9 are named[24161] available at https://www.isc.org/support named[24161] named[24161] command channel listening on 127.0.0.1#953 named[24161] zone localhost/IN: CDS/CDNSKEY consistency checks failed named[24161] zone localhost/IN: not loaded due to errors. named[24161] /usr/local/etc/namedb/working/localhost-reverse.db:3: ignoring out-of-zone data (0.ip6.arpa) named[24161] /usr/local/etc/namedb/working/localhost-reverse.db:17: ignoring out-of-zone data (1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa) named[24161] /usr/local/etc/namedb/working/localhost-reverse.db:18: ignoring out-of-zone data (1.0.0.0.ip6.arpa) named[24161] zone 127.in-addr.arpa/IN: has 0 SOA records named[24161] zone 127.in-addr.arpa/IN: has no NS records named[24161] zone 127.in-addr.arpa/IN: not loaded due to errors. named[24161] zone 0.ip6.arpa/IN: CDS/CDNSKEY consistency checks failed named[24161] zone 0.ip6.arpa/IN: not loaded due to errors. named[24161] all zones loaded named[24161] DNS format error from 82.192.82.228#53 resolving 112.242.54.110.in-addr.arpa/PTR for 65.121.55.44#55292: Name in-addr.arpa (SOA) not subdomain of zone 242.54.110.in-addr.arpa -- invalid response named[24161] DNS format error from 82.192.82.228#53 resolving 112.242.54.110.in-addr.arpa/PTR for 127.0.0.1#27795: Name in-addr.arpa (SOA) not subdomain of zone 242.54.110.in-addr.arpa -- invalid response This last repeats periodically Stoping and starting named don't clear the error, but named appears to be fine (checking domains returns expected results). Key files are updating every hour as expected. The secondary servers are in sync… ___ 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
Preventing a particular type of nameserver abuse
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
Re: Preventing a particular type of nameserver abuse
On 4/12/21 1:41 PM, Peter Coghlan wrote: 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. 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 smime.p7s Description: S/MIME Cryptographic 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-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
Re: Zone 126.0.0.1 has 0 SOIA records
On 12 Apr 2021, at 07:04, Matthijs Mekking wrote: > Perhaps inspect the zone file? Ah, since it is named localhost-reverse.db I assumed it was not plain txtm but some db format. >>>FILE $ORIGIN . $TTL 3600 ; 1 hour 0.ip6.arpa IN SOA localhost. nobody.localhost. ( 48 ; serial 86400 ; refresh (1 day) 43200 ; retry (12 hours) 604800 ; expire (1 week) 10800 ; minimum (3 hours) ) NS localhost. CDS 0 0 0 ( 00 ) CDNSKEY 0 3 0 ( AA== ) ; ZSK; alg = 0 ; key id = 768 $ORIGIN 0.0.0.ip6.arpa. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR localhost. 1 PTR localhost. FILE That looks… very wrong. I wonder what happened. OK, storing that file from backup too. > Also the CDS/CDNSKEY consistency checks stick out. Perhaps remove them from > the unsigned zone files? Yeah, I don't know what happened to these files; they should be the default ones FreeBSD makes )they are, now, once again) Thank you so much, I would never have found that. -- Keep Virginia clean...throw your trash into Maryland. ___ 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
Grant Taylor wrote: > 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-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone 126.0.0.1 has 0 SOIA records
Please open a ticket at https://gitlab.isc.org/ for this. The zone file is being updated and re-written when it shouldn’t be. We will want more details from you. > On 13 Apr 2021, at 08:19, @lbutlr wrote: > > On 12 Apr 2021, at 07:04, Matthijs Mekking wrote: >> Perhaps inspect the zone file? > > Ah, since it is named localhost-reverse.db I assumed it was not plain txtm > but some db format. > FILE > $ORIGIN . > $TTL 3600 ; 1 hour > 0.ip6.arpa IN SOA localhost. nobody.localhost. ( >48 ; serial >86400 ; refresh (1 day) >43200 ; retry (12 hours) >604800 ; expire (1 week) >10800 ; minimum (3 hours) >) >NS localhost. >CDS 0 0 0 ( >00 ) >CDNSKEY 0 3 0 ( >AA== >) ; ZSK; alg = 0 ; key id = 768 > $ORIGIN 0.0.0.ip6.arpa. > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR localhost. > 1 PTR localhost. > FILE > > That looks… very wrong. I wonder what happened. OK, storing that file from > backup too. > >> Also the CDS/CDNSKEY consistency checks stick out. Perhaps remove them from >> the unsigned zone files? > > Yeah, I don't know what happened to these files; they should be the default > ones FreeBSD makes )they are, now, once again) > > Thank you so much, I would never have found that. > > -- > Keep Virginia clean...throw your trash into Maryland. > > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@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-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Preventing a particular type of nameserver abuse
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) 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. ___ 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
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. > On 13. 4. 2021, at 6:17, Paul Kosinski via bind-users > wrote: > > 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) >> 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 names
