subdomain on route53 private hosted Zone - dns

I have been trying to setup a Private Hosted Zone in route53 with current associated VPCs in eu-west-1 and will soon add more. I have conformed that my VPC has DNS resolution option set to yes and necessary DHCP option sets are also created. I have added a DNS record under the domain.local domain and it works fine. However, the issue comes when I tried to created a sub-damain dev.domain.local and tried to associate with the same VPC. I see the following error
"A conflicting domain is already associated with the given VPC or Delegation Set."
My intention is to have one parent private zone as zorotools.local and several subdomain such as dev.domain.local, staging.domain.local, prod.domain.local etc.
I would then associate ec2 instances with these DNS names.
So, please let me know what mistake I am making and how should I proceed.

Just create records with the remainder of the FQDN filled out. So in this case create "server1.dev" and it will resolve to "server1.dev.domain.local".

Related

CloudFront to a public or private Route53 hosted zone

I have an ALB created with Terraform and a CloudFront Distribution which is so old that it's not managed by Terraform. My ALB was given a random number in the DNS name and I have concerns about entering this ALB DNS as Origin in CloudFront.
So my idea was, to setup a Route53 entry that would be more or less fixed and also managed via Terraform. But I haven't found a way so far that CloudFront will point to my Route53 hosted zone. Therefore I ask if a registered domain is necessary.
Is it possible that a CloudFront Origin points to a Route53 entry without a domain being registered, i.e. only to private or public hosted zone entries?
You seem to be concerned about the longevity of the DNS name of your ALB.
The DNS name of your ALB is static as long as your ALB exists. If you delete it, you'll get a new one, but as long as it stays, it will be static.
So if you don't plan to periodically delete your ALB, I'd be perfectly comfortable using it's DNS name as the origin in CloudFront.
About your DNS questions:
You can also add an ALIAS or CNAME record in a public hosted zone that points to your ALB (or it's DNS name in case of CNAME), which is managed by Terraform.
It has to be a public hosted zone with a real domain, i.e. some zone must be delegated through DNS to Route53.
Remember that you'll have to create a SSL/TLS certificate for this to work.
Afterwards you could set up the custom domain name as the origin in CloudFront.
This requires you to have a (sub-)domain that is delegated to your public hosted zone.
You can't do the same with a private hosted zone though.
CloudFront needs a DNS name it can resolve and since CloudFront is not part of your VPC, it needs a publicly resolvable DNS name, which the private hosted zone doesn't provide.

How to map a custom domain name created in freenom.com to a Windows Azure VM with Public IP

I have searched the net and cannot find an answer to this question. I have created a .ga domain with freenom.com.
I created two dns records in freenom.com. The A record maps to the public ip of the virtual machine and the cname record maps to the azure domain name - xxxxx.eastasia.cloudapp.azure.com. I set the ttl in both records to be 3600.
I give some hours for the dns records to propagate and try to do an nslookup on my .ga domain but it does not seem to exist. I try pinging, browsing the url but it seems that my domain does not exist.
Any help on this issue would be greatly appreciated.
For VM, you need to specify it on the Cloud Service level - did you do everything according to the official guidance?
If you use non-classic VM (ARM), then the situation is a little more complicated - you may go with that approach or with the Azure DNS service.
Your VM Name looks like : "name.cloudapp.azure.com". By default public IP address is created not static address that means you can't use DNS record on it.
If you want to use different domain name like "xxxxtest.com" then you have 2 options:
Use 'CNAME' DNS record
Use reserved IP record on Azure and 'A' DNS record
Refer below link for more details:
http://byalexblog.net/custom-domain-name-for-azure-vm

Troubles setting up private name servers WHM/cPanel

So I am trying to set up name servers for my cPanel so when my clients point their domain to ns1.mydomain.com and ns2.mydomain.com their domain will work.
I have my A records NS1 and NS2 pointed to two different IPs on my server (the ones that get assigned when I click assign IP address.
As shown in the image here: http://prntscr.com/8vui67
Although the records don't seem to be working for my clients.
Here is my "show ip address usage"
http://prntscr.com/8vuikz
The name servers don't seem to be displayed here ( is that a problem ).
Sorry for what seems like a noob question, I have been working at this for several hours and I just keep running in circles.
I really appreciate the help.
Please make sure that you have completed the following steps:
[1] Assigned IPs to nameservers from WHM (From screen capture, it seems you already did it)
[2] Register your private nameservers from your registrar where your domain is registered.
[3] Add "A" records for ns1 and ns2 in the DNS zone of your domain (which is used for nameservers)
Now you should be able to use the nameservers without any problem.
EDIT:
Your domain nalhost.com is using your registrar's DNS so you will need to create A record in the DNS zone of your registrar. If you have already registered your private nameservers and add both A records, your nameservers should work. Are you receiving any error message while using your private nameservers?

How to restore values of default VPC Security group within a given availability zone?

I am operating in US-West Availability Zone.
I was trying to solve the problem for ELB and I courageously or stupidly changed the Source IP of my default VPC security group to fix it. It did not fix the original issue but now I am in to another issue.
Now I am trying to restore the default VPC security Group setting in my Amazon Web Service account.
As per my knowledge the default VPC is very restrictive.
I don't quite remember what was the value for inbound source IPs.
The issue is that I have changed the Inbound rule's Source IP (from its original value which I do not remember) to Anywhere (0.0.0.0/0) in the default VPC Security group on AWS Console.
So how do I bring back the original default VPC security rule inbound IP setting that is applicable to my availability zone?
What is the implication of this? As a precaution I am not using default VPC Security Group on any of the EC2 instance or ELB.
Default VPC security group can not be deleted
You can make changes though
The default VPC security group simply points to its own Group-ID.
So you know how to restore the default VPC rule if you mess up with it.
You can search the informations inside AWS Forum https://forums.aws.amazon.com/forum.jspa?forumID=58
Many people open tickets similar to your problem.

Amazon Elastic IP + EC2

I have set up an EC2 instance and an Elastic IP which is associated to the instance. I have also set an A record in my DNS provider's Zone editor so that the domain name points to the elastic IP e.g. example.com = 123.123.123.123.
After reading many posts, this seems like it should be enough to work but my domain name still isn't resolving. I can't even ping the IP address! Weirdly I CAN ssh into the EC2 instance via the elastic IP and everything seems fine, except that my domain name doesn't resolve to the EC2 instance!
Any thoughts?
DNS names take a while to propagate so that is probably your first issue.
Go to http://www.whatsmydns.net/ and enter your domain name. If all of the locations are returning with the correct ip then you can safely assume its not a DNS propagation issue.
Enable ICMP rules in the security group. If using the aws console create a new rule for "All ICMP" with a source of "0.0.0.0/0". Enabling this creates a security risk for your server so only enable this temporarily while testing. At this point you should be able to ping your instance.
If using HTTP or HTTPS enable the correct ports on the security group for those protocols and as long as the instance is configured correctly with Apache you should be up and running.
Please check your EC2 security group & make sure desired ports are open

Resources