On 8/2/22 03:08, Alexander Bokovoy wrote:
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-troubleshooting
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-with-dnssec
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.
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
