On 10.9.2013 10:33, Andrew Lau wrote:
On Tue, Sep 10, 2013 at 5:54 PM, Petr Spacek <pspa...@redhat.com> wrote:
On 10.9.2013 05:28, Andrew Lau wrote:
On Mon, Sep 9, 2013 at 9:30 PM, Andrew Lau <and...@andrewklau.com> wrote:
On Mon, Sep 9, 2013 at 8:26 PM, Petr Spacek <pspa...@redhat.com> wrote:
On 8.9.2013 05:54, Andrew Lau wrote:
Hi all,
I wasn't able to find much, but is it possible to configure FreeIPA to
serve as a split horizon DNS server?
I would like the local network to be able to enroll and authenticate
locally, but at the same time bridge remote clients as well.
Suggestions?
Could you give us more details? We can try to find some solution for you
particular situation.
In general, FreeIPA doesn't support so-called views from BIND9 directly,
but you can use e.g. FreeIPA integrated DNS for internal network (the
internal view) and expose flat zone file for external view.
Example configuration (/etc/named.conf):
view "internal"
{
/* This view will contain zones you want to serve only to "internal"
clients
that connect via your directly attached LAN interfaces -
"localnets" .
*/
match-clients { localnets; };
recursion yes;
dynamic-db "ipa" {
library "ldap.so";
arg "uri ldapi://%2fvar%2frun%2fslapd-***
*IPA-TEST.socket";
arg "base cn=dns, dc=ipa,dc=test";
};
};
view "external"
{
/* This view will contain zones you want to serve only to "external"
clients
* that have addresses that are not match any above view:
*/
match-clients { any; };
recursion no;
zone "my.external.zone" {
type master;
file "my.external.zone.db";
};
};
Have a nice day.
Hi Petr,
Thanks - I ended up running a slave DNS server with bind9 views. It's
just
a bit of a pain having to now manage two DNS configs but it'll have to
do.
Thanks,
Andrew.
I spoke too soon..
My scenario I have is internal clients enrolled into FreeIPA, all the IPs
registered on internal.domain.com are internal IPs. I want to use the
FreeIPA server to also serve the DNS for domain.com but because it's
hidden
in a private network I had setup slave DNS servers but they don't seem to
use the authoritative nameserver setting,
So eg.
ipa01.internal.domain.com (private IP Address) --> dns01.domain.com(public
IP adddress)
The records that get served to dns01.domain.com are:
domain.com IN SOA ipa02.internal.domain.com.
hostmaster.domain.com.
(
Any suggestions?
It is most probably caused by 'fake_mname' setting in /etc/named.conf.
Named will respect the value in SOA record if you comment this value out,
but will lose the ability to load balance DNS dynamic updates between
FreeIPA replicas.
The point is that clients use this name to find the server responsible for
zone updates (and nothing else). In FreeIPA's case, any server can update
the zone so all servers report itself as zone 'masters'. This allows to
spread the load among all replicas and there is no single point of failure.
The question is - do you need it for external zone? Do you use dynamic
update for domain.com? I would ignore the internal hostname in the zone
if you don't use DNS updates (if you are okay with such information leak).
Side note:
Don't forget that internal host names normally leak in e-mail headers;
from mis-configured clients in internal network; via roaming clients trying
to access internal resources while they are not on VPN; etc. etc.
--
Petr^2 Spacek
I would like to keep the dynamic updates for domain.com so users can modify
DNS zones without requiring direct access. My concern was, from what people
have been telling me is that the SOA mname resolution is important, on the
other hand many have said it's not. What I've been reading has been leaning
towards the later.
The internal hostnames aren't really hiding anything, it's only because
they resolve to internal IPs
If you want to use real master name to support dynamic updates, then comment
out 'fake_mname' setting in /etc/named.conf and make sure that
internal.domain.com and domain.com have proper values in their SOA records.
You will have to bump SOA serial to enforce new zone transfer, but it should
work.
In theory, you can disable 'fake_mname' only on the FreeIPA replica from which
you do zone transfers and let it enabled on all other replicas.
Does it solve your problem?
--
Petr^2 Spacek
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
