I'm considering migrating a bunch of individual OpenStack instances, with their own IPs, into a private cloud network, with DHCP to address individual servers. One current problem I'm trying to solve is that a system failure may require the complete reprovisioning of an instance, which will change the IP address, requiring a lot of manual DNS changes with my provider. I want to transition to a less hard-coded environment, using Ansible to define my servers, and using DHCP to failover much more elegantly to a new instance if required. With recent experimenting with the ISPConfig REST API, I feel confident that I can script rapid recovery of any FQDN from one IP to another. Is that a common scenario for ISPConfig DNS? I am assuming that I'll need a ns1.mydomain.tld and ns2.mydomain.tld as authoritative nameservers, each with their own unique IP. The ns2 would be a mirror of ns1 which is running ISPConfig. I'm also thinking that I could use one of my provider's nameservers, like ns3 to serve as a third authoritative server in case my servers fail. What I'm not understanding is, if my private network has a domain hosted at DHCP 10.0.0.1, and my primary ns1 ISPConfig DNS goes down, how would the ns3 provider DNS route to one of my 10.* servers anyway? Similarly, if I do have a mirror ISPConfig DNS in another instance, and my primary "ns1" fails, how would my secondary "ns2" route into my private network to reach my 10.0.0.1? The only way an external ns can route to one of my private network servers is if they are externally network-addressable. How does that work? I hope this is clear. Should I graph this out? Should I restate this more concisely? Thanks!
Do your providers name servers have the data for your zone? Does your provider allow you setting their name server authoritative for your zone? How do you manage them so your own name servers have exact same data for your zone as the providers name servers? That is a confusing paragraph. Name servers do not route, they are not routers. I think what you wanted to ask is something completely different, the terminology used is confusing. If you have three name servers (that all contain the same data for your zone so the actually can work as servers for your zone), you configure all of them as name servers on your hosts. 10.0.0.0/8 is private adress space (defined in RFC 1918) so not routable in the public Internet. So hosts outside your private network can not reach those addresses. I can not undestand what you mean by routing, and what issue you are worried about. If you have three name servers and have configured all of them on your hosts, the name service continues to work when at least one of the name servers is working and is reachable from the hosts.
Thanks for your response. I understand that the specific terms used might have been used in the wrong context. I have setup many provider DNS records, and private routers like Linksys, but never my own zones with failover servers. I'm doing my homework to get a good knowledge base while I'm trying to do this with ISPConfig. Indeed, I was wondering, if my ISPConfig instance goes down, where my zone is defined, might I be able to mirror the zone definition with the provider DNS, maybe with IPV6, so that a public client might still be able to reach a server within the zone. As a secondary ISPConfig DNS instance (I believe?!) provides a backup for a single zone, I was hoping that the provider DNS could also serve as a backup. Stated another way, if two ISPConfig instances are sharing zone detail, why can't I include my provider DNS in that same information exchange? I am checking with the provider but it seems the only way to do this is to create two or three ISPConfig instances running DNS, mirroring the zone definitions, and each of those must be accessible to the public. I used the term route in exactly the same way you did : "so not routable in the public Internet". I just meant "access", "reach", "use an address which resolves to a specific server".
To keep terminology correct, you're not "mirroring" the zone here, when you speak of a DNS "mirror" in ISPConfig context, that is a specific feature/setup you can use so that the same zones and records are created on multiple DNS servers. So eg. in your case, your own ns1 and ns2 servers might be mirrored, but your provider's dns server will not have ISPConfig installed, so it cannot be configured as a mirrored server within ISPConfig. What you can do is have your provider's DNS server be a slave for some or all of your DNS zones. They will then transfer all DNS records in the zone from your server (whichever they specify as the master, eg. say ns1), and store them locally, so that if your own servers go down, clients can query your provider's server to get authoritative answers. (This of course requires changing all your domain registrations to list your provider's DNS server as an additional nameserver.) Then when your ns1 goes down, the provider's server already has the DNS records, and continues serving them. Look up all the values of the SOA record to see how you can influence the behavior of their dns "slave" server with regard to the zones they pull from your dns "master" server. Eg. it will check for updates at a specified time, expire the zone records after some period of not refreshing them from the master, etc.
@jesse-norell - we're 100% in sync, TYVM. Yes, I'm using the term "mirror" to indicate replication of the DNS zone detail between two or more nameservers. So far I've been understanding that I can do this with ISPConfig, so that my ns1 and ns2 are in sync. My initial "What I'm not understanding..." is that I don't know if that same ISPConfig<>ISPConfig data exchange can take place with a different upstream nameserver. I understand that 10.0.0.1 means nothing to a public client, but if my provider DNS has an internal mapping of my zone then I was hoping they would be able to expose an end-point which can access my zone, exacly like a secondary/slave ISPConfig instance. I hope this isn't going off into la-la land ... I'm not familiar with the mechanisms yet by which ISPConfig servers exchange DNS data. If I define a server within my private network through my primary ISPConfig server, is a hook executed to transfer that to a secondary? Is that a push process from the primary, or a pull from the secondary? The reason I'm asking is that my provider exposes a DNS API too, so if the ISPConfig API for DNS is used, I can copy the code into a new module that bridges DNS updates from ISPConfig to my provider. Oh, and not trying to be elusive here: I'm running everything with DreamHost over their DreamCompute network. This is their DNS API : https://help.dreamhost.com/hc/en-us/articles/217555707 ISPConfig DNS API : https://git.ispconfig.org/ispconfig/ispconfig3/-/tree/stable-3.1/remoting_client/API-docs The same concept applies for any provider, like Azure, AWS, or Digital Ocean. Please forgive, as I'm trying to describe functionality and ask if this is what ISPConfig does, because I don't have access to documentation that describes the internals of exactly what ISPConfig does. If someone points me to RTM on this topic then I'll be able to ask more educated questions. If stuff like this is in the 400 page user manual, then I'll run to that now. Thanks to anyone who reads this.
So you have not yeat read ISPConfig manual? RTFM is the first thing to do, it is lazy to start by asking complicated questions with wrong terminology. To learn about DNS and start using correct words: https://en.wikipedia.org/wiki/Domain_Name_System There is a link in my signature to DNS setup with ISPConfig tutorial. Even if both Dreamhost and ISPConfig have API for managing DNS, unless someone has written code to move data using those, you have to write that code yourself or hire someone do code it for you.
Those ansible thingy setup is never related to ISPConfig. I did read that you mentioned you can code in other thread but I don't think you can code all that you wanted if you yourself don't understand. As said by @Taleman what you need are good programmers or coders to do such things and they can refer to the manual in doing so. Guessing is never good in coding or programming.
ISPConfig supports two mechanisms for dns mirroring, its's own mechanism which requires that both servers are ispconfig systems and both servers are part of the same multiserver system, see ispconfig multiserver install guides here at howtoforge, or you use the standard bind secondary zone transfer mechanism which does not require any changes on the ispconfig end, all you have to do is to create a secondary dns zone on your other dns server and set the IP address of the secondary server in the allow zone transfer to field of the zone in ispconfig. And of course you can write an ispconfig plugin that uses the API of your hoster to add dns records and zones at your hoster, the ispconfig API is not involved in that though. Have a look at the powerdns ispconfig (server) plugin to get an idea how one would implement something like that.
Minor clarifications: - I've been developing RFC-level interfaces and business applications for 40 years, so coding isn't an issue. - I am familiar enough with DNS to configure anything I need with a UI, but I've never used BIND directly, and have never setup a multi-system private network other than at home, so doing this with cloud servers is new for me, and of course I'm just learning ISPConfig capabilities. @till - thanks for details. While I have the skills to create a bridge between environments using the APIs, it's now apparent that no interface between ISPConfig DNS and the provider is required. What I've been describing is a scenario where the provider DNS is aware of systems within a private network. This is supported in OpenStack with floating IP addresses, and implemented with a virtual router that forwards requests on the public IP to the internal IP. It's essentially DDNS. This is the answer to my question about "might I be able to mirror the zone definition with the provider DNS, maybe with IPV6, so that a public client might still be able to reach a server within the zone". I didn't have the knowledge to articulate the concepts until now. The solution is different from the direction that I was taking, but the problem has a solution. My plan now is to setup multiserver ISPConfig as ns1.primary.tld and ns2.primary.tld These will be in a private network with 10.* addresses. Floating/Public IPs will also be assigned to these. The provider will serve the authoritative DNS for primary.tld, which will have A records for ns1 and ns2. To avoid having to make all changes for primary.tld in the provider DNS, I'll add ns1.primary.tld and ns2.primary.tld on the registrar list of authoritative DNS - these will be the only nameservers for all other subdomains in the primary.tld zone, and for all other servers in the network. Thanks guys.
