It's may be stupid, but I really interested in this question.
I want make mirror www subdomain for main and can't choose which property to use...
CNAME looks more solid and clearer. I can set it like this:
www.exmaple.com -> A someIP.
Just don't quite know how Google Cloud DNS behaves. If use CNAME, will the client get an subdomain IP or will he get the name of the main domain and make a second request to get his IP?
P.S. Yes, I understand that the time difference in the execution of requests is so small that should forget it.
Google Cloud DNS does not support ALIAS resource records.
ALIAS (A) records are usually faster and are typically used for internal services on the same provider. Example would be a load balancer. ALIAS records typically have a short TTL (typically 60 seconds) so that they are constantly being resolved to the service.
When you resolve a CNAME, a subsequent lookup is required for the returned DNS name, which could then be another CNAME, etc.
There are more factors to consider when select an ALIAS versus CNAME. For example:
AWS does not charge for ALIAS record lookups but does for CNAME lookups.
You cannot use a CNAME for the zone apex (example.com). You can for the subdomains (www.example.com).
A CNAME cannot coexist with another resource record of the same name, whereas ALIAS can.
Related
We are planning to use cloudfront distribution for our main domain and the setup will be as follows.
Cloudfront Origin - route.domain.com -> Remote Server IP address(xx.xx.xx.xx)
www.domain.com, domain.com -> d123.cloudfront.com
As we know, we can setup CNAME for www.domain.com to point to cloudfront distribution(d123.cloudfront.net). However, for domain.com we should point A record to IP address and its not possible to setup CNAME record.
In route53, there is an option called Alias which can be used to point the domain to Cloudfront. But, our domain.com nameserver uses different provider and we would like to stick with current nameserver.
Any help would be appreciated.
Since this is a limitation in DNS itself, there is no way to accomplish this without a DNS hosting provider that supports an alias-like feature, sometimes called an "ANAME" or "flattened CNAME". Route 53 is of course the canonical example. CloudFlare and DNS Made Easy are others.
Or use a service like this one¹ to redirect your naked domain name to the www address, which would be your "real" site. They give you a single IP address for your A record. Note that your current DNS provider may have a "redirection" option that does this. It is not properly a part of DNS, but some providers allow you to configure domain redirections in their DNS portal.
Or migrate your DNS hosting to Route 53, keeping your DNS registration with your current vendor. In my mind, there is really no compelling reason not to use Route 53. See Making Route 53 the DNS Service for a Domain That's in Use for migrating to Route 53 without disruption, noting that the final step -- Transfer Domain Registration to Amazon Route 53 -- is entirely optional, as mentioned in the docs.
¹ this one is not a service I am affiliated with or have ever used in production, because I built my own service for that purpose using EC2, which is another option but outside the scope of this answer. This is intended as an example, not an endorsement.
Let's say I have a website example.com which I bought via a common domain registry nomcheap.com.
I want all traffic to a specific subdomain app.example.com to go to name server ns1.appserver.com so I can serve a specific user app.
I also want all other traffic (www.example.com, hello.example.com, *.example.com, etc.) to go to a different name server from a different provider ns1.squaresites.com so I can serve a general website (think something like a commerce Wordpress site).
None of the name servers are provided by the original domain registry nomcheap.com.
Is this possible? If so, any suggestions on how?
To point a subdomain to a name servers you need to create an NS record for the subdomain:
app.example.com NS ns1.appserver.com
This will make all queries go to ns1.appserver.com
*.example.com NS ns1.squaresites.com
The second record should catch all subdomains that don't have their own records (of any kind).
Delegating name server DNS responses can be done was the answer by #Lanexbg describes.
Realize that chaining your DNS lookups this way adds more time to DNS resolution and adds another potential point of failure in the resolution process. If the parent's name servers are down, they won't able to deliver the NS records to tell the client's resolver to continue the lookup process through a delegated name server.
Consider if using DNS "A" or "CNAME" records at the parent's DNS server would be acceptable alternative.
For more detail on how DNS resolution is delegated see this answer on serverfault.com:
How exactly should I set up DNS to delegate authority for subdomains?
My website is hosted with Firebase Hosting, and I want to make a http post to a NodeJS process running on AWS EC2 instance.
First fail: EC2 was http, I had an error of mixed content (https and http).
Next, I put in a load-balancer in-front of the EC2 instance, and installed my domain certificate (www.mydomain.com)
Second fail: I get an ERR_INSECURE_RESPONSE error, as loadbalancer.amazonaws.com does not match www.mydomain.com
I am at wit's end in resolving what I think is a straight-forward use-case. Please help.
Two options.
You need to register your domain with Amazon, so you can create a Hosted Zone in AWS Route53. There, you can create a record to point "mydomain.com" to your load balancer.
The other option is with your current register (GoDaddy or someone else), to Forward your domain to your load balancer. You will probably need to enable "Forwarding with Masking" so it still looks like your domain, but is served by the AWS load balancer.
Let me know what works (or doesn't) and I'll update this answer.
You are getting the ERR_INSECURE_RESPONSE error because you are using a CNAME which is resolving to loadbalancer.amazonaws.com. Since your certificate is for www.yourdomain.com, it is giving a valid error. CNAME and Alias operate slightly differently. With a CNAME the traffic is not a valid alias of your domain so if you're trying to secure it, you will receive errors. However, when you create an A record for www and alias that to loadbalancer.amazonaws.com now any traffic from loadbalancer.amazonaws.com on www.yourdomain.com is valid traffic for your domain and you will no longer have those errors.
In order to terminate secure traffic for www.yourdomain.com at loadbalancer.amazonaws.com you need to have an A record that will alias there. Unfortunately, ELB's only provide a DNS entry, no IP address, but many DNS providers (ie GoDaddy) will not allow you to have a DNS A record that is aliased to a DNS address; they require you to alias to an IP address. Which makes life a bit more complex.
There are a couple ways to accomplish this (URL forwarding and masking is not supported by SSL), but the easiest solution is to use Route 53. Use of Route 53 doesn't require you to register or transfer your name to AWS and a hosted zone is just $0.50/month per domain.
To use Route 53 follow these steps:
Create a Hosted Zone for yourdomain.com. When you create a Hosted Zone in Route 53 it will complete a few default records (like an A, NS, and SOA records). Note the NS records as you'll need them later.
Next copy your existing zone file entries (like MX records) from your current DNS provider to your new hosted zone.
When it comes to a record that you want to direct traffic for to your ELB you'll enter the name, say www, and then just below the type option field you'll see a radio option that says "Alias: yes no". When you select yes, the value field will disappear and you'll see an option that says "Alias Target: Enter Target Name". When you click that field you'll receive a drop down list of resources in your account that you can alias to. Simply select your load balancer.
Click create, and you're done with Route 53.
Now that all your dns records are copied over, and you'll go to your registrar and change the nameservers to the ones that Route 53 provided you.
Now Route 53 is handling your DNS for you. And loadbalancer.amazonaws.com is a valid alias of www.mydomain.com. Since loadbalancer.amazonaws.com is now a valid alias of www.yourdomain.com when you visit www.yourdomain.com your ELB at loadbalancer.amazonaws.com will terminate the traffic as www.yourdomain.com and your error will be resolved.
Side note: If your instances are in us-east-1 you can get an unlimited number of free standard, SAN, and wildcard SSL certificates for your ELB and domain using Certificate Manager.
Openshift domain (example.com) requires a CNAME pointing to my example.rhcloud.com. However by doing this, and not allowing us to do an A record with IP they are breaking the ability to do an MX record for example.com since an MX record requires that example.com be an A name not a CNAME.
Is there a way around this? I'm using namecheap.
I've seen some hacky stuff to point to www.example.com but I don't want to do that, as I want to remove the www. from the domain.
Its not possible with openshift, because example.com needs to point to an A record for mx.example.com to work properly. Its required by the RFC spec.
Because openshift requires you point example.com to a CNAME (foo-whatever.rhcloud.com), you cannot then point mx.example.com to an IP of email server and expect mail for me#example.com to work.
There are some hacky solutions, like using 3rd party dns resolver and cronjob to update the IP address of the openshift server, but none of these seem like solid solutions to me.
https://www.openshift.com/forums/openshift/methoddynamic-ip-for-your-apps-a-record
OpenShift Online is not a dns provider, you can not create an mx record using it. You would need to create an MX records at your dns provider for your domain.
If you mean "how can i create an mx record using my dns provider along with having a cname for openshift", then you would need to create an mx record that points to your third party mail service.
You can check out this answer (https://serverfault.com/questions/100064/dns-is-it-valid-to-have-an-mx-record-and-no-a-record) which should help you.
Some DNS providers support special types of DNS records that dynamically look up dynamic IP adresses and create the corresponding A records.
DNSimple calls this an ALIAS record.
DNS Made Easy calls it an ANAME record.
You can use these special record types instead of CNAME, if your DNS provider supports them.
Using Rackspace.com, which offers DNS service, I am attempting to point one domain EXAMPLE.NET to a dynamic DNS updated domain EXAMPLE.DYNDNS.ORG.
My problem is that when pointing the Fully Qualified Domain Name (example.net without any subdomain in-front) to the dynamic domain that is updated by the dyn service, I am given the response;
CnameRecord: Fqdn has already been taken by another resource record
while, in fact, there are no other records for this domain (other than the NS records that are required). I am not given this error when a subdomain is used, only when the fully qualified domain name is what is being acted on.
I found one article that gives me the insight to believe that one may point to a CNAME record from the FQDN (example.net).
CNAME records should not point to other CNAME records. This is mainly to avoid possible infinite loops.
CNAME records should not contain other resource record types (such as A, NS, MX, etc.). The only exception are DNSSEC related records (that is, RRSIG, NSEC, etc.) when the zone is signed.
Other resource record that point to the fully qualified domain name (FQDN) of a host (that is, NS, MX, PTR) should not point to a CNAME record.
My goal here essentially is to use a dns service to point my .net domain to a domain that is dynamically updated with my router since the server is stuck in a dynamic IP pool. Any advice?
The error message is exactly correct. You cannot create a CNAME RR because the domain already has NS RR (and in fact, also an SOA RR too) and CNAME is not allowed in combination with anything else (except DNSSEC RRs).
Your best bet is to use dynamic DNS to update example.net directly, instead of or in addition to updating example.dyndns.org.