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/
Thanks very much Alexander. If it helps guide improving the designs
going forward: Freeipa 'as written out of the box with dnssec enabled'
did pass all the dnssec accuracy and configuration checkers such as
verisign and others, and also did work properly with 4 out of 6 of the
world's public dns resolvers with dnssec enabled, and all of them with
dnssec not enabled. I purposely use 'old hardware' for development,
because when it works on that, it will work on anything newer. On
exactly the same physical hardware that failed Google's and Cloudflare's
dns resolver with freeipa+dnssec, I added unbound as a slave resolver
then retested with dnssec enabled -- all the world's resolvers including
google and cloudflare worked properly and over the course of many re-tests.