On 21/3/23 23:38, Jesus Cea wrote:
Hi everybody.
Bind 9.16 here.
I have this configuration for DNSTAP:
"""
dnstap {auth; client; resolver; forwarder;};
dnstap-output file "/var/cache/bind/dnstap.tap" size 100M versions
100 suffix timestamp;
"""
The "dnstap.tap" is correctly moved to "
'break-dnssec no' looks at the DO flag and whether the data to be returned is
signed. If DO is 1 and the data is signed
then the answer is not modified. If DO is 0 then it is modified as the client
cannot be performing DNSSEC validation on
the response and be expecting it to succeed for respons
Hi,
in line with our deprecation policy, I am notifying the mailing list about our
intent
to deprecated the delegation-only and root-delegation-only options. This is
again
adept for expedited deprecation - it will be removed in BIND 9.20 and deprecated
in BIND 9.18.
The (root-)delegation-optio
Peter,
> On 22. 3. 2023, at 14:40, White, Peter wrote:
>
> First of all, is this script part of the normal BIND distribution, or is it
> part of the RHEL 7 distribution? From what I can tell, it is called weekly.
This is RH's script
> Any thoughts on what could have caused this on two secon
I had the named process fail this past weekend on two secondaries running BIND
9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13. It seems that logrotate.d is calling
the following script at the time of the failure.
/var/named/data/named.run {
missingok
su named named
create 0644 named named
> That's something that's impossible to answer without seeing the full
> configuration (named-checkconf -px).
The full config here : https://pastebin.com/CwWFq73G
Thanks.
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
> On 22. 3. 2023, at 14:26, BONIN Nathanael wrote:
>
> If I add break-dnssec yes ; in my bind conf, it seems to works like I wanted
> to !!! Thanks.
+1
> But what I don’t understand is why, when I use directly SrvA (server that
> have RPZ zone), it works ?
That's something that's impossible
Hi Ondrej !
I think you found the answer !!! It seems that the problem is DNSSEC. The
biopyrenees.net seems to have a dnssec sig :
dig @127.0.0.1 biopyrenees.net +dnssec +short
213.186.33.5
A 8 2 3600 20230414114926 20230315114926 1266 biopyrenees.net.
uUm5BxSqUJFyBhFCkT20zcqD+VkxCOJ47KxDqzvLoa
Hi Nath.
What have you got on SrvB for biopyrenees.net, or net?
On SrvB, please do "dig @127.0.0.1 sri.biopyrenees.net" (please use the
actual address rather than "localhost") and paste the full result here. I
am interested in flags and the query time right now.
Cheers, Greg
On Wed, 22 Mar 2023 a
Hi,
look for break-dnssec in
https://bind9.readthedocs.io/en/stable/reference.html#response-policy-zone-rpz-rewriting
--
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 22. 3. 20
Hi there,
We are using RPZ zone for some times now, but recently we found a weird
behavior from some domains. Let me explain !
We have 2 NS server : Recursive one (let's call him SrvA) and one bebind (let's
call him SrvB, with global forwarder : SrvA ). My RPZ zone is on SrvA.
If we took a lit
11 matches
Mail list logo
