I had an infrastructure consist of load balancer(nginx configuration) and two servers,
one is for UK and other is US,
Now requirements are I have to deploy runtime application to one of these servers based on client ip, that part is done in nginx conf with geoip module.
and will do server entry as well if not available in nginx upstream list.
Now second part is these servers e.g UK US having an ip's, I want runtime DNS entries for them as well,
Servers can be of AWS,Azure,GCP their domain providers may vary,
So its possible to do DNS entry during deployment stage like first application will be deployed to corresponding server then that server should do entry as well in DNS and get domain name (should be provided by user in runtime).
in short, there is script which is doing runtime domain entries like as.blabla.com in nginx
but I need to have an another parameter for server like 190.80.0.13 for asia, and i want dns entry for this ip as well either this belong to GCP,AWS or any DNS related system.
Question may seem alot twisted, its okay we can discuss further.
In AWS you will be better with AWS Elastic Load Balancer and Route53, using Geolocation, or Geoproximity as routing policy.
For better performance you can add (CDN) Cloudfront distribution.
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html
Related
I have a site running on ECS in AWS with the DNS being handled by Route53.
There are two network interfaces which I can use the Public IP addresses of to access the site. The problem is Google has indexed this IP addresses as well as the domain name.
How do I "redirect" the IP addresses to the domain name?
There are 2 aspects in your question:
You want your access using IP to resolve to your domain name
Google indexing your site with the wrong URL
For your 1st challenge, there isn't a native way to force browsers from IP back to URLs. You have to handle this in your application or infrastructure. Since you're running in ECS, that could either be a rule in a Load Balancer (e.g. if using Application Load Balancer, a rule that checks if Host-Header doesn't match your domain then redirect to your domain URL), or you could write the logic into your container.
Regarding the #2 problem, that might be because your IP was added to some site in the internet (remember that IPs are re-used in AWS), and as a result Google has the IP in the cache and it's refreshing it. To handle this problem, you might need to review if it's possible using Google's Removals Tool.
I currently have a GKE cluster and service set up at app.companyname.com. It lives in the prod GCP "project". I am now spinning up a dev project, and it's all good, except I don't know what to do with the domain name and certificate settings. I want the app available at dev.companyname.com
Do I have a public DNS zone per project, or should I have one, in the prod enviromment that dev accesses somehow? Do they share nameserver settings? Does the prod project forward to the dev project?
Do I have a separate SSL certificates, one per environment? Or one in prod environment that dev accesses.
What is the general overview on how this should be set up with GCP?
Essentially the question is about separation between Prod and Dev. Following this approach ("spinning up" a separate Dev project in GCP) you should stay consistent and separate public DNS as well. This will make projects scalable and align GCP service boundaries accordingly with the administration, trust, management and billing scopes managed by different teams.
Do I have a public DNS zone per project? - Broadly speaking, you should have a separate DNS zone per environment (but in the described case this means "per project"), in particular because SOA settings like REFRESH or TTL could be set different between Prod and Dev. Also, since each managed zone that you create is associated with a Google Cloud project, you can leverage IAM access control features to stick with the principle of least privilege in DNS zone management.
Do they share nameserver settings? - With a managed service such as Cloud DNS your projects will use name servers provided by vendor. You can find them in GCP Console or with gcloud:
$ gcloud config set core/project myworks-240610
Updated property [core/project].
$ gcloud dns managed-zones list
NAME DNS_NAME DESCRIPTION VISIBILITY
my-works myworks.example.com. public
$ gcloud dns managed-zones describe my-works --format="flattened(nameServers)"
nameServers[0]: ns-cloud-b1.googledomains.com.
nameServers[1]: ns-cloud-b2.googledomains.com.
nameServers[2]: ns-cloud-b3.googledomains.com.
nameServers[3]: ns-cloud-b4.googledomains.com.
$ dig ns-cloud-b1.googledomains.com +short
216.239.32.107
NS address is different for different projects (that way between Prod and Dev).
See Updating your domain's name servers
Do I have a separate SSL certificates, one per environment? - In different DNS zones hosts will have different CNs, so you will have separate certificates in Prod and Dev. You can use wildcard certificates to make things simpler, for example in Dev environment.
I am not familiar with the specifics of GKE, but I can speak to general domain system.
Answers:
There is one DNS record for companyname.com, the NS records are set for the overall domain. But there would be two A records, one for prod and one for dev. The A record points to the IP, so you can host them on any two servers, or the same one, or in a subdirectory of the other one, as long as Apache, or whatever serves the website, can match the full subdomain name to the directory in which the subdomain's files live
There are separate SSL certificates for each subdomain
Here is the example as the final DNS zone record to give you an idea of how to set your DNS settings:
; Name Servers
companyname.com. IN NS ns1.somehost.com.
companyname.com. IN NS ns2.somehost.com.
companyname.com. IN NS ns3.somehost.com.
; A records
# IN A XXX.XXX.XXX.XXX ; IP for the main companyname.com
prod IN A XXX.XXX.XXX.XXX ; IP for the app.companyname.com
dev IN A XXX.XXX.XXX.XXX ; IP for the dev.companyname.com
About URLs
A URL consists of protocol://Domain Name:port/path/file
https://prod.companyname.com:80/index.html
Protocol is just http or https
Domain name is what traverses the entire internet and the Domain Name Systems entire purpose is to map the domain name with the IP of the public facing server that holds that domain
Just the port and hidden by the browser to the user
The server then receives the request (something like Apache, or maybe GKE takes it from there) and maps the domain name to a root directory on the server, and then traverses down the path to the correct files to serve up to the requester
I know it is a lot to take in, but that is the root problem. I can't speak to GKE and someone else might jump in and explain out it might be configured to do what you are doing. But if you can get access to the DNS settings of the domain, and make a proper subdomain, this all gets a whole lot easier for you.
I'm new and I recentely installed Cpanel/WHM into a AWS EC2, everything works fine, but I have a question about it.
It is possible to register an A type registry on R53 pointing to my own DNS server (CPanel/WHM).
For example:
My server is server.com, and there I have a DNS server that works fine and where I have multiple domains registered on it.
If I register ns1.server.com into R53 like A registry and it points to my server. Would it works globally?
You would not really need to register your nameservers with R53 if you just want your server to act as authority on that domain. You would need to go to your domain registrar and point the name server entries there to your DNS server that is running on the EC2 instance.
But you would also need a DNS entry for that name server somewhere. If you are running your app on AWS unless you need your own NS for some kind of custom setup I would just use R53. Works great and is much cheaper than using a server specifically for that purpose.
Sorry in advance if this doesn't make much sense. I'm fairly new to this, so bear with me please.
I'm trying to specify a domain to a specific folder depending on the domain name the user use (example.com or test123.com), through Amazon Elastic Load Balancer (Application load balancer to be specific).
My current setup is that all traffic from the internet goes to a Load Balancer (ELB), from there it round robin between 2 EC2 instances. Both instances are connected to an Amazon Network File System (EFS), as well as a Relational Database (RDS).
I can access the website(s) fine through the DNS of the load balancer (http://web-load-balancer-efs-16512354.us-east-1.elb.amazonaws.com/example/)
What I want to do now set it up so that if someone put example.com as their url it will point to the Load Balancer and from there the server will use the correct folder as root (www.example.com document root would be http://web-load-balancer-efs-16512354.us-east-1.elb.amazonaws.com/example/, but the URL will still be www.example.com).
I created a hosted zone on Route 53 to point the domain name to my load balancer, but currently my load balancer which leads to one of the ec2 instances. Currently the ec2 document root is /var/www/html/efs-mount/.
Is there a way for me to have multiple document root depending on the domain name?
I stumble on something about putting multiple TLS/SSL certificate on your listener and through SNI protocol it'll be able to find right place? http://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#https-listener-certificates. I'm not sure if this is what I need, or I'm completely off track.
If someone can point me to the right direction on how to do this that would be great.
Thanks
You are indeed off track.
While ALB with multiple SSL certificates may be a part of your strategy, since it allows you to attach multiple ACM certificates to a single instance or group of instances, ALB does not re-write the paths of the incoming requests or determine how the instance resolves web paths into filesystem paths.
This is something configured in your web server itself. Start by searching for something like "name based virtual hosting." Each domain name will specify it's own "document root" in the web server configuration files.
I have a web service running on EC2 behind an elastic balancer. I would like to allow my clients to point their A record to my web service so they could have their domain on my server. Similar to shopify or github pages.
However, I don't want to give them the IP of the web service, I'd like the request to go though the load balancer. How can I achieve this? Should I create a small server to forward requests? How does that work?
Many thanks!
If you are running your service behind an Elastic Load Balancer, you usually do not want to use ELB DNS name (which is something like your-service-ELB-1122334455.us-east-1.elb.amazonaws.com). Instead you will configure (probably using Route53, but any DNS service will do) CNAME or ALIAS record with some friendly name, like yourservice.yourdomain.example (this way, name will be easier to remember, and you have the freedom to change load balancer if needed).
All your customers have to do is to create CNAME DNS record pointing their name to your friendly service DNS name, like:
foo-service.theirdomain.example CNAME yourservice.yourdomain.example.
You also need to be aware that HTTP requests will have Host: header containing name entered by user (in case your server/service relies on that info)
You need to consider using Route53 as your clients's DNS service provider might not be supporting this feature beacuse of DNS rule.
See s3.6.2 of RFC 1034
Amazon created a new aliasing system for Route 53. You can now map the apex of a hosted zone to an Elastic Load Balancer using an Alias record. When Route 53 encounters an Alias record, it looks up the A records associated with the target DNS name in the Alias, and returns the IP addresses from that name.
In order to allow all of our customers to benefit from this new feature, there is no charge for queries to alias records when the target is an Elastic Load Balancer.
Associating Your Custom Domain Name with Your Load Balancer Name.
You can also create a Subdomain That Uses Amazon Route 53 as the DNS Service without Migrating the Parent Domain.