On ma, 08 elo 2022, Harry G. Coin via FreeIPA-users wrote:
Alexander Bokovoy asked for a note on the use of Unbound as a slave
resolver to freeipa's bind9+dnssec because of the issues discussed
under Re: [Freeipa-users] Re: Dnssec rejected by Cloudflair, Google,
accepted by Verizon, AT&T
Summarizing: Unbound is just a lot faster than bind9+dnssec,
additionally offering native support for DANE, DNS over tls and etc.
Older hardware running bind9 can't process DNS + DNSSec queries under
the timeout limits used by major public dns resolvers relied upon by
thousands, including mail providers. Unbound can and does.
Steps:
1. Work with existing freeipa tools and documentation to get dnssec
working properly under bind9, validate it using at least two of the
public dnssec diagnostic tools (verisign, etc.).
2. Use global dns performance testing tools to see whether all report
good results from several dozen of the world's public dns resolvers.
If they all report 'green' or 'ok', then your servers are 'fast
enough' and you don't need this further work (unless you want DANE,
dns over tls and the other things unbound offers).
3. For at least one, and preferably at least as many freeipa
master/slaves identify an ip4 (and ip6) address for use by the unbound
resolver service. It's best if they are in the same subnet as at
least one of the freeipa machine's interfaces and preferably secured
for physical reasons or, second best, encryption.
4. Load those addresses into the 'Allow Transfer' section of
Freeipa's dns domain manager settings window. Be sure reasonable
values exist in every section measured in (seconds). I also chose to
edit /etc/named/ipa-options-ext.conf to 'notify explicit; also-notify
{ all freeipa and unbound addresses other than the current host } ;
allow-notify { only freeipa and not unbound addresses; } You might
take the chance to set up acls and make good decisions about rate
limiting and allow-* settings. I found only rebooting freeipa &
bind9 caused bind9 to get the updated 'allow transfer' settings from
freeipa. Restarting bind9 alone was not enough.
5. Either in a new network name space on the same host as freeipa or
in a vm on that host, or, well, anywhere really except on the same set
of addresses as freeipa's named daemon: Load unbound and prove up it
is working under default settings using the addresses reserved above.
6. Create a file in unbound.conf.d for access control. I suggest
leading it off with
access-control: 0.0.0.0/0 refuse_non_local
access-control: ::0/0 refuse_non_local
access-control: 127.0.0.0/8 allow_snoop
access-control: ::1 allow_snoop
followed by whatever local address ranges you'd like for full dns
recursive services, such as your 'lan' or equivalent eg
access-control: 10.something.whatnot.0/24 allow
In an related 'options' file, include 'interface' lines for each host
address you want unbound to process incoming queries (your local lan
interface as well), and including at least one of the host addresses
you entered into freeipa above. Include 'outgoing-interface' lines
the interface on the unbound host that matches at least one of the
addresses entered into freeipa.
In another file, or one file per zone, add an 'auth-zone:' section
using 'name:' as the zone to support, and 'primary:..." entries for
each freeipa server.
7. Restart unbound. use dig @unbound-serverip to validate proper operation.
8. Change NS records on all servers to be handled by unbound to point
to the unbound's interfaces named in the 'interface' lines above. I
chose to have public IPs point at the unbound supported slave
resolvers, and left all local lan resolution using freeipa, since
there was no security value added by dns over tls & etc owing to the
physical site-wire security. But YMMV.
9. Revalidate proper DNSSEC validation and worldwide resolver
performance/accuracy.
In my case, 'ancient' servers passed all tests using the unbound
frontend with and without dnssec. They also passed using freeipa's
setup without dnssec (nearly always, one in Australia and one in
Brazil would occasionally fail). Freeipa's servers with dnssec passed
most of them, but failed google and cloudflare always, occasionally
one or two others but passed most.
There are a fair few other options to do with performance and features
you can add and manage, well documented by the unbound support folks.
That's it! Hope that helps others.
Thank you, Harry. This is quite useful. I'm going to turn this into a
wiki page in the coming week or so. I am a bit slow these days as I am
recovering from a medical condition I had this summer, so it might take
time.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland