As an update, TL;DR it doesn't appear that IPA resets any of my override
changes, everything is awesome.
Here's copy paste of my followup on another thread I had started asking
about allow-recursion specifically (so that if someone stumbles upon this
thread instead, they'll get the full howto)
Well, I've tested this and so far no weirdness has occurred when adding a
replica or making various changes via the web UI, as far as I can tell
nothing rewrites the named.conf after the replica has been set up.
Changed "allow-recursion { any; }" to "allow-recursion { internal; }", and
added the following ACL:
acl "internal" {
10.0.0.0/8;
localhost;
localnets;
};
Also figured out that I can change the faked mname in the web UI at Network
Services > DNS > DNS Servers > (select a server) > SOA mname override. This
of course changes the mname for zones that only resolve internally to (most
of them) but it doesn't matter because the external name I set will be
accessible internally too, and everything nominally uses the internal IPs
of the replicas for name resolution anyways. I added externally resolvable
names for the replicas to the public zone, changed the NS records to those,
and set the fake mname accordingly for each server. Presto! Public zone
served from FreeIPA without public recusion, on same server that handles
internal zones with recursion, and so far no changes I've made in the web
UI have rewritten my zones to undo any of this (which apparently used to be
a problem?)
Still would be nice if I could set this up via the UI and thus have the ACL
automatically configured on every replica, but it's no big deal, since once
I set it in named.conf IPA doesn't appear to change it.
On Mon, Nov 12, 2018 at 5:37 PM Jonathan Vaughn <[email protected]>
wrote:
> Thanks for the pointers / explanations everyone.
>
> It would be nice if adding a replica didn't reset the SOA/NS, but the main
> reason I say that isn't due to the actual work of fixing it, but that once
> we're set up with replicas in all our offices we'll add new ones so
> infrequently I guarantee this will get forgotten / overlooked and cause
> confusion, even though I will put it into the internal KB :D
>
> Would be nice if there was a per-zone setting to prevent this reset -
> perhaps even some option to specify public/private IPs for each replica and
> a simple public/private switch on the zone, so that it would default to
> using the correct IPs (and any without public IPs on a public zone would
> just not appear in NS/SOA records), but I understand this is outside the
> scope that FreeIPA is interested in supporting.
>
> If I manually add extra NS records, will they get nuked when adding a
> replica, or just not be listed in SOA anymore? If nobody is sure I'll try
> to test this...
>
> On Thu, Nov 8, 2018 at 10:14 PM, Peter Fern via FreeIPA-users <
> [email protected]> wrote:
>
>> On 9/11/18 3:07 pm, John Petrini via FreeIPA-users wrote:
>>
>>> The mname override now lives in ldap and is configured using the
>>> dnsserver-mod command. fake_mname is no longer included in named.conf.
>>> I think that feature was added to address this issue:
>>> https://pagure.io/bind-dyndb-ldap/issue/162
>>>
>>> We use TSIG for dynamic updates without any issues, not sure if
>>> something has changed there but it works for us.
>>>
>>
>>
>> Good to know - things may indeed have changed, last time I messed with
>> this was on v4.3.x.
>>
>> _______________________________________________
>> FreeIPA-users mailing list -- [email protected]
>> To unsubscribe send an email to
>> [email protected]
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/[email protected]
>>
>
>
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
