On ti, 02 elo 2022, Harry G. Coin wrote:
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.
Thank you for the feedback, Harry. Could you please provide a shortened
document that outlines how you have used unbound as a slave resolver to
IPA DNS server? We can add something like that to IPA wiki and may be
others will be interested in that too.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland