I run a 4-node IPA cluster on AWS spanning a few global regions and tied
into a particularly complex AD forest -- never had the DNS issues you
mention but I've never had to talk to IPA on-prem either. And our setup
is strange as we could never get the global AD admins to make DNS
entries for us among other issues so we ended up choosing a totally new
TLD domain name to run IPA on and bind our servers against; this works
fine except we can't leverage kerberos based features because our realm
is different from our domain. All we needed was RBAC login using AD
usernames and passwords though so our needs are met.
For DNS on AWS though ...
- You can override or alter DHCP level nameserver assignments at a
VPC-level if you want to adjust DHCP option sets. This is a big
decision as it is VPC-wide in scope but works well to push out "global"
DNS and nameserver preferences
- If VPC level changes are too much then it's pretty easy on an EC2
instance to override or alter DNS resolution, nameservers and search
order in ways that persist beyond reboot. Specific method depends OS you
are using and if you want to this on the CLI via ansible or manual
operations or if you want to do this at the cloud-init "just booting up"
level
I did have a nasty DNS issue in the past with an old school client that
believed all DNS should be served out of AD and that pre-creating
reverse PTR records was "nonsense" and "not needed" which broke a ton
of
AWS HPC and EMR use cases and other projects where software does a
reverse lookup on it's IP to learn more about its self. In that setting
we built our own custom DNS server based on DNSMasq -- DNSMasq is
perfect because you can construct a totally bespoke DNS environment
combining delegated nameservers, local name servers and you can even
have DNSMasq read DNS entries from an /etc/hosts style file so you don't
have to maintain a complex bind-format zone file
I don't know the exact scope of your situation but this seems like a
case for overriding the DNS settings on the EC2 hosts running IPA to
talk to your colo nameservers rather than the AWS designated ones that
show up via your DHCP Option Set
Chris
William Muriithi via FreeIPA-users wrote on 5/27/20 10:30 AM:
Hello everyone
We want to move some of the systems for a co-location into AWS. IPA
systems are some of our candidate servers.
I have attempted to get this working by setting up a replica server in
the cloud and attempting to setup replication - over VPN - and its not
working. This is due to DNS issue on AWS being biased toward AWS DNS.
If I use nmap, it verify I can reach port 53 (TCP and UDP) on the
co-location from AWS, but if I do a dig against existing DNS, it
doesn't seem to resolve.
Have anyone gone through the exercise recently and managed to figure
how to work around this limitation? Would be grateful if someone can
share how the worked around this problem.
Regards,
William
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...