On 30/05/2023 12:23, Alexander Bokovoy wrote:
On Tue, 30 May 2023, lejeczek via FreeIPA-users wrote:
>
>
> On 30/05/2023 10:43, Alexander Bokovoy wrote:
>> On Mon, 29 May 2023, lejeczek via FreeIPA-users wrote:
>>> Hi guys.
>>>
>>> That is on first master which was happy for short while
>>> and then suddenly:
>>>
>>> ...
>>> 29-May-2023 12:38:23.597 info: client @0x7f6484005538
>>> 127.0.0.1#43235 (onet.pl): query failed (broken trust
>>> chain) for onet.pl/IN/A at ../../../lib/ns/query.c:7355
>>> 29-May-2023 12:39:08.518 info: client @0x7f64b0080088
>>> 127.0.0.1#48441 (onet.pl): query failed (broken trust
>>> chain) for onet.pl/IN/A at ../../../lib/ns/query.c:7355
>>>
>>> and that is for any & every query.
>>> With given forwards or no forwarders.
>>> Time is in sync, network works, everything else seem
>>> good too... and the second master/replica does not
>>> complain.
>>> What might the issue (beside the obvious)?
>>
>> The obvious part is described in the error message: you
>> have broken
>> DNSSEC trust chain for onet.pl and that causes the issue
>> because you
>> have DNSSEC validation enabled.
>>
>>
> Yes, that part is obvious - perhaps I did poor job
> formulating my question - this is fresh new IPA
> installation of first master(in container), which master
> worked for a short while - meanwhile I did add a replica
> to the domain - and then... this.
> Like I said - every query every domain DNSSSEC fails that
> same way ! on that first master, whereas... the second
> master continues to be a okey.
DNSSEC validation is enabled by default for any DNS
requests. DNSSEC
signing is disabled for IPA-hosted domains so you have to
enable that
explicitly. However, if you have some zones that already
use DNSSEC and
then IPA DNS zone is a sub-domain of those but is not
signed, DNSSEC
validation would cause this issue.
It cannot explain why it didn't fail right away, though.
> There is nothing else I can think of that happened to
> that master - one more thing I did was backup on that
> master - before DNS broke.
> One conspiracy theory, the only one I can come up with,
> is - could a broken replication affected newly set up
> master? -> another domain's one master had
> 'ipa-healthcheck' reporting some troubles, mentioned the
> host-name of that new domain first-master-fqdn, which was
> before a member of already existing domain.
Broken replication could affect it if you had DNSSEC keys
enabled for
the domain already.
Okey... well, it seems it reproduces every time(so far)
It's all in containers -
I deploy first master, then two replicas (simultaneously,
when first master is ready)
First master - DNSSEC broke (immediately?) after I run backup.
On another master after I deployed KRA, DNSSSEC broke, on
last master after I restarted the container.
All that above happened within a few minutes span.
Can anybody have a clue ? I have none.
I was thinking perhaps host's fcontext labeling of the
mapped volumes - so I relabeled with the that of
/var/lib/containerd, I also switched selinux into permissive
- none of these made a difference - but that was ever the
root cause then container & IPA would, should not have
deployed successfully to begin with, I think.
'healthcheck' reports no issues, nor any other issues
really, also inside the container.
DNS only resolves - on all three mastesr - own domain,
anything else brakes with 'trust chain'
This new domain - only mention this for the sake of
argument, I don't think it matters - new deployment
FQDN/realm is the same as already existing IPA domain, but
they both are meant not to know about each other,, obviously.