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.
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
