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
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.
Excell
> 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
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.
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
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 t
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 q
[ 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 packet
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
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?
>
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
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
13 matches
Mail list logo
