I have two servers that provide a service to clients.
The client devices access the server through a DNS name. example.com
Now we generally use server1 (primary) but if server one becomes inaccessible, I want the DNS to change its resolving name to server 2 (secondary server)
How can I go about doing this, Is there a service that dyndns provides?
The only way I know to do it is to log into the DNS server and manually change the addresses that the dns resolves 2.
It sounds like you're looking to create an automated failover in the event of an outage. While this is a service that Dyn provides as an added service in the DynECT Managed DNS service (hit up sales#dyn.com for more info on that), you can also use the Dyn Updater API to push an IP update up to your Standard DNS account as well. It would be a matter of using a 3rd party monitoring solution to trigger the update in your code using their API, then using the Dyn Updater API to switch the IP.
http://dyn.com/support/developers/api/
Whether you want to spend the money on upgrading to DynECT Managed DNS or keep using your Standard DNS account, we can help you either way.
Good luck, and if you have any other questions, please do not hesitate to ask.
CL
Related
I am very new to Cloudflare. So please bear with me. I need to access my website (hosted in Microsoft Azure - App Services) via IP address instead of the domain name.
To do this, I need to add HOST=www.mydomain.com into the HTTP header when requesting the website via IP address.
I heard it can be solved via Cloudflare, but the person I asked will not elaborate further. Is it possible? If yes, what service should I purchase? Any manual or instruction will be appreciated.
If Cloudflare isn't possible, do you have any service recommendations?
Thanks :)
The reason the host header is needed is because Azure App Services are multi-tenant (multiple apps on a single IP) by default. So, the server needs some way to know where to route your request to (the host name). In addition, IPs are not guaranteed to be static (they can change as you scale for instance).
It should be possible to secure a single static IP address using the following method -
https://learn.microsoft.com/en-us/azure/app-service/overview-inbound-outbound-ips#get-a-static-inbound-ip
What is unclear is whether or not this IP would also be dedicated (meaning only your domain would use it). This is what would be required in order to allow you to access the app service without a hostname specified.
Cloudflare will not solve this issue, as it sits at the DNS layer (domain name access). Accessing a server via IP would bypass Cloudflare entirely.
Is it possible to have an App Service respond to all domain names that it receives? I would really like to be able to deploy to an App Service plan, rather than a VM. Note I am not trying to do wildcard subdomains - these require adding them through the Azure console. I am trying to accept any domain name that the app service receives. Adding and verifying each domain is not practical.
I have a multitenant app, so this is really important to me so that customers can use their own domain names.
I've tried adding the domain * and ., but it fails validation.
I don't think you can do this because Azure requires validation of domain ownership by adding specific records to DNS. Here is a discussion as to why they do that.
The best you might be able to do is to automate or script the binding, but even then you would need assistance from your third party partners/customers to verify their DNS ownership.
An alternative would be to transfer your DNS to Azure and use subdomains. I know you've said you're not looking at that solution, but using the Azure DNS offering would allow you to fully script out the onboarding process for a new customer.
Could you ensure that the changes to your DNS settings have been confirmed and validated from your DNS provider’s end. For certain providers, such as GoDaddy, changes to DNS records don't become effective until you select a separate Save Changes link.
For more details, refer "Map an existing custom DNS name to Azure Web Apps".
You may refer MSDN thread, which addresses similar issue.
For our SaaS app, we're allowing customers to point their domain name to our server.
The plan right now is to simply hand out one of our AWS elastic IP addresses for them to point their domain to. The elastic IP address would essentially be pointed to a EC2 instance web-server...and maybe a load balancer in time (if traffic demands it!).
The user would specify what their domain is in our app, and we'd be able to resolve the host name coming in as their app.
My concern is the longevity of this solution. This IP cannot change. And we'll certainly be tied to AWS if we go this route.
(Note: Being a 1-2 person startup, standing up a data-center is more than likely no-go, and we hope to use AWS or Azure).
What solutions would make this IP address -> SaaS Web Server concept last in the long run, with flexibility, and as minor of a tie as possible to a cloud provider?
With running the risk of asking "what is the best way to do this"...what's the best way to do this, keeping in mind longevity and small opt-in to a cloud provider?
You can't point an IP address to a load balancer, so this seems like a very bad idea. You need your own domain/subdomain that clients can point their domains/subdomains to via a CNAME record on their end. Then if the location of your service ever changes you just have to update your domain record and their DNS records will continue to be correct.
In the world of microservices endpoints should not (must not) be hardcoded. One of the best ways to do this is to have a DNS and let each microservice register while starting. By doing this whenever microservice A wants to communicate with microservice B it just asks DNS for endpoints where B currently listens.
What I do not understand is: How microservices know where the DNS lives?
Basically DNS is just a 'special' service and I can have one or multiple instances of it right? So I should not hardcode it's endpoint too or should I? And let's say I do - what if DNS instnace is moved to different location? Do I have to manually change it's location in configuration?
Does anyone happen to know how to design this? (or can anyone just point me to any document where this is explained since although there are many information about microservices and dns I can not find this particular information anywhere - maybe it's just too trivial and I am the only one who does not get it)
Manual setup of DNS is possible, as stated by the other answers, but I would recommend to use an infrastructure that supports the service discovery in all respects. For example kubernetes has built in DNS support and makes it very easy to expose a service that can consist of any number of Pods.
An infrastructure technology like kubernetes will also make many other respects of the microservices architectural style easier to implement, including high availability and scalability.
Please see the official docs for some more information.
DHCP solves this problem. When a host boots it sends a broadcast DHCP message. The DHCP server responds with many values, one of which is the location of DNS servers.
In the case of micro services, the host OS (or container host) will be configured for DNS via DHCP. The microservice code uses the OS DNS functions to resolve addresses.
https://en.m.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
You can use your local network to discover services, via Dhcp and whatnot. But that requires that all services are already "registered" within that DNS server.
Microservices can find each other via service discovery, server or client side. If you choose client side service discovery, you can use tools like Consul, which provides a bunch of great features. One of which is a DNS endpoint which allows queries via SRV records with <serviceName>.consul.service domain names.
Consul has it's own DNS endpoint, you can configure your services to use that (usually on port 8600 locally, as Consul agents run locally).
But you can also configure an actual DNS server to forward questions to Consul, so that you can easily mix service discovery drive by Consul with manually setup services within a Bind instance or similar...
Known hostname solution. The fixed part would be the service domain name, for instance xservice.com. You can query this host using standard DNS tools (e.g., dig in your shell, etc).
Finally, in the DNS bound to xservice.com you then add a SRV record with further details.
A SRV record lists all the service details, including:
the symbolic service name;
the canonical hostname of the machine providing the service;
the TCP (or UDP) port on which the service is available.
There are many other info as well. Please see Wikipedia for the complete list.
Please keep in mind this is a somewhat static solution. If you are looking for a more dynamic one, then Oswin answer might be a better fit :-)
The company I work for is considering some changes to our DNS. We host an internal linux BIND9 DNS for primary and secondary authoritative DNS. We are thinking of changing either to hosting our public DNS externally, or keeping the primary on-site and move the secondary to a service like Google. I know it doesn't really make sense to keep our public DNS on-site or splitting it up, but the business owners would like to consider all possible options. I have looked through the documentation on-line and have contacted Google directly, but none of the sources I have checked will tell me if Google will allow us to use their DNS service to replicate a primary DNS server housed on-site and act as a secondary DNS for our domains. Does anyone here know if this is possible, and if it is what specifics they require to make it work. Any assistance that can be offered is appreciated.
Having a name server be a secondary authoritative name server for a domain of yours requires some cooperation from the owner of that server, so the only people who can tell you for sure if Google offers that service are Google themselves.