8:37 p.m.
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?
9:14 p.m.
New subject: Manage public DNS using FreeIPA, when FreeIPA is on internal network/IPs?
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
9:38 p.m.
New subject: Manage public DNS using FreeIPA, when FreeIPA is on internal network/IPs?
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).
9:45 p.m.
New subject: Manage public DNS using FreeIPA, when FreeIPA is on internal network/IPs?
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(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
10:07 p.m.
New subject: Manage public DNS using FreeIPA, when FreeIPA is on internal network/IPs?
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.
10:14 p.m.
New subject: Manage public DNS using FreeIPA, when FreeIPA is on internal network/IPs?
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.
5:37 p.m.
New subject: Manage public DNS using FreeIPA, when FreeIPA is on internal network/IPs?
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(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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
7:49 p.m.
New subject: Manage public DNS using FreeIPA, when FreeIPA is on internal network/IPs?
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(a)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(a)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(a)lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-leave(a)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.fedoraho...
>
8:25 a.m.
New subject: Manage public DNS using FreeIPA, when FreeIPA is on internal network/IPs?
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.
8:56 a.m.
New subject: Manage public DNS using FreeIPA, when FreeIPA is on internal network/IPs?
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
3:18 p.m.
New subject: Manage public DNS using FreeIPA, when FreeIPA is on internal network/IPs?
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(a)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
3:26 p.m.
New subject: Manage public DNS using FreeIPA, when FreeIPA is on internal network/IPs?
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(a)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
>
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
1988
days inactive
2009
days old
freeipa-users@lists.fedorahosted.org
11 comments
4 participants
participants (4)
-
Alexander Bokovoy -
John Petrini -
Jonathan Vaughn -
Peter Fern