[Freeipa-users] DNS forwarding configuration randomly breaks and stops working

[nathan at nathanpeters.com]

>>> Looking at the log entries, it appears that there may have been a
>>> network
>>> connectivity 'blip' (maybe a switch or router was restarted) at some
>>> point
>>> and even after connectivity was restored, the global forwarding was
>>> failing because the "we can't contact our forwarder" status seemed to
>>> get
>>> stuck in memory.
>
> Most likely.
>
>>> [root at dc1 ~]# ipa dnsconfig-show
>>>   Global forwarders: 10.21.0.14
>>>   Allow PTR sync: TRUE
>
> This means that you are using the default forward policy which is 'first'.
> I.e. BIND daemon on the IPA server is trying to use the forwarder first
> and
> when it fails it fallbacks to asking server on the public Internet.
>
> I speculate that public servers know nothing about the name you were
> asking
> for and this negative answer got cached. This is default behavior in BIND
> and
> IPA did not change it.
>
> Workaround for network problems could be
> $ ipa dnsconfig-mod --forward-policy=only
> which will prevent BIND from falling back to public servers.
>
> Anyway, you should solve network connectivity problems, too :-)
>
> I hope this helps.
>
> --
> Petr^2 Spacek
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>

Ok, we managed to figure out what was happening here, but I still think
there is a bug somewhere in the FreeIPA DNS components that is
exacerbating the issue.

We have split DNS in our company.  We have a public copy of our DNS
records, which contain only A records.  We also have an internal copy of
our DNS records, which contains a bunch of CNAME records.

When we use nslookup to query the IPA server for stash.externaldomain.net
NSLOOKUP returns that stash.externaldomain.net is a CNAME and it returns
the associated A address.

When we query FreeIPA though a DNS client, FreeIPA returns that stash is a
cname and does not return the associated A address.  It seems like at that
point, FreeIPA decides that instead of sticking in 'forward' mode and
forwarding the request for the CNAME