Let's say my domain is xyz.com
If
- I had an A record pointing to an IP address, say 193.10.23.1
- then I had a CNAME www points to blah.cloudfront.net
But of course blah.cloudfront.net is not pointing to 193.10.23.1, will dns look up return the A record or the CNAME record? Is there an order of precedence or whether CNAMES overrides the A record?
Thanks
DNS standards does not allow having both CNAME and A record:
https://www.rfc-editor.org/rfc/rfc1034#section-3.6.2
If a CNAME RR is present at a node, no other data should be present;
this ensures that the data for a canonical name and its aliases cannot
be different.
DNS provider will usually will usually prevent you from adding conflicting records:
Cloudflare:
AWS Route53:
Related
When I deploy my website on Google App Engine and add a custom domain(that I own from GoDaddy.com or name.com or namecheap.com etc.), GAE provides me with A, AAAA, and CNAME records which I need to add in the DNS record configuration in GoDaddy.com/name.com/namecheap.com website.
Similarly, When I deploy my website on Digitalocean and add a custom domain(that I own from GoDaddy.com or name.com or namecheap.com etc.), it provides me with nameservers(ns1.digitalocean.com,ns2.digitalocean.com etc.) which I need to add in the Nameserver configuration in GoDaddy.com/name.com/namecheap.com website.
So is adding nameservers equivalent to setting DNS records?
So is adding nameservers equivalent to setting DNS records?
Well, yes and no.
Yes, the "Nameservers" setting actually creates 'NS' type records in DNS – except they are not in your zone; they are in the parent zone. For example, if your domain is example.com, then its nameserver addresses must be known by the com zone.
(That said, your own zone also has identical 'NS' records, but they're not the ones that really matter.)
But on the other hand, no, setting nameservers (NS records) has a completely different purpose from creating A/AAAA type records. An 'A' record directly points to the server where a website is hosted, while an 'NS' record adds indirection – the 'NS' record points to a server which holds the 'A' records.
Can you tell me the complete flow of what happens including DNS and zone file lookup that take place when I type "www.example.com".
Your OS (which has a 'stub' resolver) sends the query to a 'full' or 'recursive' resolver.
The recursive resolver has a built-in list of nameserver addresses for "" (the DNS root).
The resolver sends the query to the root nameservers, receives a referral to the "com" domain's nameservers ("I don't have that record, but I do have com./NS records").
The resolver sends the same query to the 'com' nameservers, again receives a referral to the "example.com" domain's nameservers.
The resolver sends the same query to the 'example.com' nameservers, and finally receives the actual answer.
The recursive resolver returns the answer to you.
See existing documentation:
https://www.cloudflare.com/learning/dns/dns-server-types/
https://royal.pingdom.com/a-visual-explanation-of-how-dns-lookups-work-2/
I am trying to configure a www domain on azure. I want to have website under this domain. My domain is "legia.fitness". I have created the DNS zone as follows:
On this picture you see 4 DNS servers. I have delegated my domain that I bought at home.pl to those servers:
And this doesn't work. When I try to browse legia.fitness I get "ERR_NAME_NOT_RESOLVED" error. What am I doing wrong?
Your Azure DNS zone does not have any A or CNAME records for www or # so the name cannot be resolved to an IP address.
Add a new A record with the label # set to the IP address of your Azure website, and another A record with the label www also set to the same IP address.
Alternatively, create CNAME records (both # and www) and set them to your Azure Website's name (e.g. yourwebsite.azurewebsites.net). CNAME records are aliases of existing A or CNAME records, but are slower to resolve which is why I prefer A records.
You haven't directed the domain anywhere yet.
You have a DNS zone that works. I can see the SOA records on Dig web interface.
Now you have to add CNAME/A records to the DNS zone to direct the traffic to where you want it.
Here is a guide for Azure Web Apps: https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-custom-domain-name
If you use something else, you'll need to find its guide.
Probably simple question and I miss something trivial but...
Typical CDN incapsula setup is:
domain.com A record to incapsula IP
subdomain.domain.com CNAME record to incapsula.host
Why is A record used? Why don't use CNAME record for root domain also?
Because you cannot have a CNAME record for the root domain if you want to have other records under that same domain. This is not allowed by the DNS specification, specifically in RFC 1034 (http://www.faqs.org/rfcs/rfc1034.html)
If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different. This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.
If you had CNAME flattening then you "could" do it.
Whether CNAME record can be used for root domain is decided by the DNS service provider for that domain. It has nothing to do with the CDN provider for that domain.
CNAME to root domain is not standard DNS function, thus why many DNS service providers do not support it. That is also why root domain has to point to A record from CDN provider in some situation.
In other situation where DNS service provider does support CNAME to root domain, and you configure root domain to point to CNAME, you will still find a A record when dig it, this is called CNAME flattening.
Take my this site whatsmycdn.com for example, it is actually pointing to CDN CNAME, but you only see CDN virtual IP when digging it as a result of CNAME flattening:
dig whatsmycdn.com +short
110.232.178.193
Most DNS provider will not allow you to point root domain to other record then A record, the reason for that is that RFC rules prohibits that.
The best practice will be to point the root record as instructed by Incapsula and use their management console to point the root domain to the WWW one to avoid latency (The CNAME uses Geo-location).
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.
I would like to have a DNS server which returns # CNAME example.com. for all requests unless otherwise specified. This will be used as the authoritative server for clients who don't customize their DNS.
Is it possible to configure BIND to have one catch-all zone file for any requests which don't have their own zone file?
You should be able to add a wildcard CNAME record.
*.example.com. IN CNAME example.com.