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
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
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
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.
> 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
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]
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
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
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
[ 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
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
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?
>
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. (
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
14 matches
Mail list logo
