If I set up FreeIPA on 10.x.x.x internal IP, and have it manage company.net, it seems to want to set the NS record to it's FQDN that only will be reachable internally. The internal IP is SNAT mapped to an external IP (vs using DMZ), so DNS requests can reach the server via the external IP.
Other than assigning a public IP to FreeIPA server instead (and placing that IP in DMZ vs how our firewall/router is currently set up with SNAT), is there a way to serve public zones managed by FreeIPA functionally ?
Is it safe to just edit the NS/A records such that they're using externally resolvable addresses? Or will that break something?
Yes. When you create a new zone it creates NS records for each IPA server by default but you can change them to whatever you want.
If you do this you'll probably want to remove the SOA mname override from each of your IPA DNS servers otherwise changing the authoritative name server on the zone will have no effect on the mname in the zones SOA. It's been a while since I've done it but if I remember correctly you just have to set it to and empty string to remove it.
Get a list of the of the IPA DNS servers: ipa dnsserver-find
Remove the mname override from each one ipa dnsserver-mod <ipa-server-name> –soa-mname-override
On 9/11/18 2:14 pm, John Petrini via FreeIPA-users wrote:
Yes. When you create a new zone it creates NS records for each IPA server by default but you can change them to whatever you want.
If you do this you'll probably want to remove the SOA mname override from each of your IPA DNS servers otherwise changing the authoritative name server on the zone will have no effect on the mname in the zones SOA. It's been a while since I've done it but if I remember correctly you just have to set it to and empty string to remove it.
Get a list of the of the IPA DNS servers: ipa dnsserver-find
Remove the mname override from each one ipa dnsserver-mod <ipa-server-name> –soa-mname-override
I don't know if this method provided here works, but the method I used was to comment out the `fake_mname` arg for the ipa dynamic-db in the bind configuration (named.conf).
It can be done, but there are some caveats you should be aware of:
- You'll need to disable the fake_mname that bind gets configured with for your SOA to show up correctly - Any time you add/change a replica, you'll need to check your NS/SOA records and probably correct them again, as they get reset. - TSIG updates for dynamic DNS don't work, as the nameserver in the SOA record doesn't match the required service principal. You can kind of work around this by creating a new service for DNS/yournameserver.here.com to match your SOA record, delegating that to the appropriate hosts, and adding the kerberos key for that service to the bind keytab. Even after doing this though, I've found it to be unreliable, and somewhat difficult to debug.
I filed an issue or two about related problems some years ago, but they weren't given much in the way of attention, because public DNS is deemed an unsupported configuration, so you probably shouldn't expect much in the way of help if things go poorly.
On 9/11/18 1:37 pm, Jonathan Vaughn via FreeIPA-users wrote:
If I set up FreeIPA on 10.x.x.x internal IP, and have it manage company.net http://company.net, it seems to want to set the NS record to it's FQDN that only will be reachable internally. The internal IP is SNAT mapped to an external IP (vs using DMZ), so DNS requests can reach the server via the external IP.
Other than assigning a public IP to FreeIPA server instead (and placing that IP in DMZ vs how our firewall/router is currently set up with SNAT), is there a way to serve public zones managed by FreeIPA functionally ?
Is it safe to just edit the NS/A records such that they're using externally resolvable addresses? Or will that break something?
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste...
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.
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.
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 < freeipa-users@lists.fedorahosted.org> 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 -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@ lists.fedorahosted.org
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 jonathan@creatuity.com 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 < freeipa-users@lists.fedorahosted.org> 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 -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste...
Good to know mname override is available in the WebUI. I had no idea.
Just another bit of info you might find useful, if you make the mname override blank it removes it and you can control the SOA mname per zone via the Authoritative nameserver option.
On pe, 30 marras 2018, John Petrini via FreeIPA-users wrote:
Good to know mname override is available in the WebUI. I had no idea.
Just another bit of info you might find useful, if you make the mname override blank it removes it and you can control the SOA mname per zone via the Authoritative nameserver option.
John and Johnathan, would you please make a short write up with steps (screenshots) how to set this up? Markdown would be great and any plain text is good too.
You can send it to me and I'll add it as a howto on freeipa.org.
John, thanks for the tip on removing the MNAME to allow the SOA to define it (changing the SOA was actually the first thing I tried, and when that didn't work I remembered reading something about fake_mname, which Google results kept telling me was in named.conf but at some point moved to LDAP and was accessible via the UI). I might stick with just changing it at the server level vs SOA level (so that all replicas list themselves in the SOA and not just the one set on the zone), but it's good to know we have the option if it turns out to be a better course of action.
Alexander, I can try to write it up when I get the chance. I can't guarantee any kind of ETA for it though ;)
On Fri, Nov 30, 2018 at 8:56 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On pe, 30 marras 2018, John Petrini via FreeIPA-users wrote:
Good to know mname override is available in the WebUI. I had no idea.
Just another bit of info you might find useful, if you make the mname override blank it removes it and you can control the SOA mname per zone via the Authoritative nameserver option.
John and Johnathan, would you please make a short write up with steps (screenshots) how to set this up? Markdown would be great and any plain text is good too.
You can send it to me and I'll add it as a howto on freeipa.org.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
On pe, 30 marras 2018, Jonathan Vaughn wrote:
John, thanks for the tip on removing the MNAME to allow the SOA to define it (changing the SOA was actually the first thing I tried, and when that didn't work I remembered reading something about fake_mname, which Google results kept telling me was in named.conf but at some point moved to LDAP and was accessible via the UI). I might stick with just changing it at the server level vs SOA level (so that all replicas list themselves in the SOA and not just the one set on the zone), but it's good to know we have the option if it turns out to be a better course of action.
Alexander, I can try to write it up when I get the chance. I can't guarantee any kind of ETA for it though ;)
Thanks. I think we are all moving into traditional festivities and then our traditional conferences so if there is a chance to get it around FOSDEM/DevConf.cz in the end of January/beginning of February, that would be fantastic. If not, later comes spring time and it will also be comfortable. ;)
On Fri, Nov 30, 2018 at 8:56 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On pe, 30 marras 2018, John Petrini via FreeIPA-users wrote:
Good to know mname override is available in the WebUI. I had no idea.
Just another bit of info you might find useful, if you make the mname override blank it removes it and you can control the SOA mname per zone via the Authoritative nameserver option.
John and Johnathan, would you please make a short write up with steps (screenshots) how to set this up? Markdown would be great and any plain text is good too.
You can send it to me and I'll add it as a howto on freeipa.org.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
John Petrini -
Jonathan Vaughn -
Peter Fern