> On 3 Jun 2023, at 07:04, Alex wrote:
>
> Hi,
> I'm using bind-9.18.15 on fedora37 and I'm trying to understand and
> troubleshoot some errors I'm receiving in the debug logs:
>
> 31-May-2023 16:58:11.399 query-errors: info: client @0x7f8d18203b68
> 127.0.0.1#56268
Hi,
I'm using bind-9.18.15 on fedora37 and I'm trying to understand and
troubleshoot some errors I'm receiving in the debug logs:
31-May-2023 16:58:11.399 query-errors: info: client @0x7f8d18203b68
127.0.0.1#56268 (bounce.bwnews.bestwestern.com): query failed (SERVFAIL)
for
On 2/6/23 7:59, Nick Tait via bind-users wrote:
On 2/06/23 15:02, Jesus Cea wrote:
What I get from your reply is that BIND is not expected to do anything
about this. It is a bit disappointed but I agree that BIND is doing
the right thing. Too bad big players don't care. But I need to "solve"
On 2/6/23 10:38, Cathy Almond wrote:
Has this just started - as in, it worked before ... when?
No idea. We have been biten by this because a new client. The issue
could be for ages, no idea.
It sounds like 'they changed something', possibly by accident (maybe
adding more servers or
* Matthijs Mekking [2023-06-02 14:10]:
> Did you wait until the migration was complete? Everything needs to be
> omnipresent after the migration before you can making DNSSEC policy changes
> safely.
Well there was no easy way to tell if migration was complete, there
were no indications if the DS
Hi,
On 6/2/23 13:53, Sebastian Wiesinger wrote:
Hi,
I recently moved from auto-dnssec to dnssec-policy and after the
switch I tried to change a zone from an RSA ZSK/KSK to an ECDSA CSK.
When I changed the dnssec-policy from rsa to ecdsa-csk the old keys
immediately got removed which lead to a
Hi,
I recently moved from auto-dnssec to dnssec-policy and after the
switch I tried to change a zone from an RSA ZSK/KSK to an ECDSA CSK.
When I changed the dnssec-policy from rsa to ecdsa-csk the old keys
immediately got removed which lead to a bogus DNSSEC for the zone. I
was expecting a
On 01/06/2023 15:58, Jesus Cea wrote:
I am getting errors "Name huawei.com (SOA) not subdomain of zone
cloud.huawei.com". The problem raises when requesting on
oauth-login.cloud.huawei.com . The problem was described in the mailing
list:
On 2/06/23 15:02, Jesus Cea wrote:
What I get from your reply is that BIND is not expected to do anything
about this. It is a bit disappointed but I agree that BIND is doing
the right thing. Too bad big players don't care. But I need to "solve"
this, so dropping BIND (nooo!) or patching
9 matches
Mail list logo
