On ma, 01 elo 2022, Harry G. Coin via FreeIPA-users wrote:
TL;Dr: Freeipa's DNS (especially with dnssec enabled) can appear
to
be working well and pass accuracy tests, yet generate failures
depending on the client's dns provider's response timeout settings.
You can tell whether you're as 'online as you think you are' using
this tool:
https://dnschecker.org/
Freeipa's dns response latency times are near the timeout/give-up
bubble of some of the world largest public / semi-public DNS
resolvers. When 'over time', these large companies report the freeipa
web sites & related services do not exist. DNS resolvers in use by
those 'near to' the host generally have better timing generally and so
give the appearance of working.
Without DNSSEC enabled, the packet sizes and processing requirements
are less, so most services on the same continent as the host operate
as expected. Enabling DNSSec adds enough so that even the 'more
local' dns resolvers time out/report error -- and without notice to
the freeipa hosting organization. Cloudflare and Google in North
America 'worked' without dnssec in my case, but failed more often than
it worked with DNSSEC enabled.
I think the problem is the latency involved in the orchestration
between bind9 and dirsrv/ldap. Work arounds include "throwing faster
computers at it" and/or pointing internet NS records at slave
resolvers that don't depend on interprocess communications.
The way how bind-dyndb-ldap integrates with the bind, a zone is loaded
upfront and then served by the bind similar to any other source. There
is no additional overhead once zone is loaded into the bind process. If
you have no DNS records updated, the cost of serving a query is the same
as with a traditional bind deployment. It is only when an update comes
from LDAP or from a bind's client with the help of dynamic updates and a
change in the zone is needed, a bind-dyndb-ldap driver might get
involved.
So I'd rather look at your networking setup in the first place. Another
place to look is bind's DNSSEC troubleshooting guide:
https://bind9.readthedocs.io/en/latest/dnssec-guide.html#dnssec-troublesh...
DNSSEC indeed needs more queries' processing, more retransmissions in
UDP case due to larger packets but I would expect FreeIPA-integrated one
to have the same cost as with a traditional bind deployment too --
DNSSEC keys also pre-extracted and placed to the locations where the
bind expects them to find when zone is being loaded; it is only when the
keys change we get DNSSEC Python utilities provided by FreeIPA and
OpenDNSSEC to be involved. But in either case bind has to perform record
signing on the primary, like addressed in the answer of the follow
question:
https://stackoverflow.com/questions/70439025/bind-9-restart-performance-w...
A relatively recent (last year) DNS performance test of different bind
versions also found that 9.16 branch had some performance regressions:
https://www.isc.org/blogs/bind-resolver-performance-july-2021/
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland