Is DNS lookup time slowed down by the use of subdomains and CNAME? As I understand it, if a client wants to lookup for example rweb.stat.ucla.edu at least four steps are needed:
[registrar] NS ucla.edu ==> ns2.dns.ucla.edu
[ns2.dns.ucla.edu] NS stat.ucla.edu ==> dns.stat.ucla.edu
[dns.stat.ucla.edu] CNAME rweb.stat.ucla.edu ==> id-86-243.stat.ucla.edu
[dns.stat.ucla.edu] A id-86-243.stat.ucla.edu ==> 128.97.86.243
Does this mean the client has to connect to each of these servers when visiting the page? Or do the DNS servers connect to each other and directly resolve (and cache) rweb.stat.ucla.edu ==> 128.97.86.243? Also it is not clear to me how much work is involved in finding the initial record for the root domain?
First of all, the registrar is never involved in the actual DNS lookup. Registrars (and indeed, registries) are administrative entities outside the scope of the DNS protocol. The actual lookup process looks more like this:
Ask root servers for A of rweb.stat.ucla.edu..
They won't tell you, but they'll point you to servers for edu..
Ask the edu. servers for A of rweb.stat.ucla.edu..
They won't tell you, but they'll point you to servers for ucla.edu.
Ask the ucla.edu servers for A of rweb.stat.ucla.edu..
stat.ucla.edu could be a zone that is delegated to yet another set of nameservers, in which case you'll get a referral answer for the third time.
But let't say it's not.
You get an answer: rweb.stat.ucla.edu. has CNAME id-86-243.stat.ucla.edu.
Now you have to start all over again and look up id-86-243.stat.ucla.edu...
...except that because the target of the CNAME is inside the same zone as the original record (or, in general, inside any zone that happens to be served from the same nameserver), the nameserver will helpfully give you the A record for id-86-243.stat.ucla.edu in the additional section of the DNS response. The resolver will notice this and won't have to run after the A record itself.
Because resolvers cache answers, many queries can be answered from the cache and don't actually have to be asked every time. Especially the first few steps of the query are all likely to be already cached by the resolver, except immediately after it starts up with a cold cache. So the resolver can probably usually start at step 3 (because it remembers what the nameservers for ucla.edu. are from its cache) or at least at step 2 (because it remembers what the nameservers for edu. are) if it doesn't already know the final answer.
So the short answer to your question is yes, using CNAME makes more work for the resolver and makes the resolution process take longer. But in practice it doesn't matter very much because the resolver's cache is so helpful. And if the CNAME's target is in the same zone as the CNAME record itself, it matters even less because of the helpful additional record.
Related
This is a code example from MSDN: getaddrinfo.
You can use "baidu.com" and "www.baidu.com" to test.
Because baidu.com and www.baidu.com are different addresses!
www.example.com is registered in DNS with an A type record (or a CNAME, which points to an A record - this is slightly simplified) An A record is a name, in this case www that points to an IP Address 12.34.56.78. (as I'm sure you already know!)
example.com can also have an A record registered (though not a CNAME) this is called the Apex (or naked!) domain. example.com's A record could very well point to 123.45.67.89
A little history
Part of the reason that this came about, is that in the early days of the internet, a server would have a hostname of something like LOCUS.UC.EDU because it can be difficult to know what services LOCUS might provide. you could attach the CNAME FTP.UC.EDU to point to that machine. that way people knew what services it offered. at that point, www was just another service, it had no special place in the collective consciousness. (all of this was happening over the decade or two that the internet was developing!) but you could also quite probably want bob#UC.EDU to work. so UC.EDU needed to be a host name also
In actual fact it started with just the hostname (and host records that got telexed - I do love that fact) - but we'll ignore that for this case.
back to the facts
What usually - should - happen is that there is an A record registered at the Apex and a CNAME registered at www But there is certainly no requirement for this and you can have whatever records you wish at your domain.
I'm creating a project on Microsoft Azure. We only get a nameserver instead of an IP address. Since I have multiple domains pointing to Azure, I would like to redirect all my domains to a nameserver that is redirecting to Azure. This way, if Azure change my nameserver, I’ll only have to change one nameserver instead of changing it for all my domains.
However, is it a bad practice to create a nameserver pointing to another nameserver. Is it slower to resolve the IP address ?
Thank you !
I guess you mean having NS records point to a CNAME record?
It's not allowed. However, it usually works. Doing this has always been discouraged but the original DNS specification was never perfectly clear about it.
RFC 2181 clarifies that it is not allowed, and RFC 1912 is relevant too. This ServerFault question contains more details and is where I found the refences to those two RFCs.
Nonetheless, it "usually" works (but I wouldn't recommend doing it). In answer to your question, yes, it will be slightly slower (there's an extra name that must be resolved) but not significantly, and resolvers will cache everything after the first time anyway.
I have inherited a web server that is hosting 5 websites for my client. Call them domian1, domain2, etc I just discovered that all the domain nameservers for all 5 domains are set to ns1.domain1.com and ns2.domain1.com. The single server is running the DNS for all the domains including domain1.com. ns1 and ns2 are both pointing to the same web server.
Aside from the fact that there is no redundancy, and the domain1 name servers are using the DNS to resolve their own IP's, why would anyone do this? Am I missing something?
There are two options when creating NS records for zones:
1) Set the NS record of each zone to point only to itself. Hence, domain1.com would get ns1.domain1.com, etc. The advantage of this is that the remote site doesn't need to do a cross reference to somewhere else and go look it up too. EG, if you have domain1.com's NS records pointing to ns1.domain2.com, then a lookup of the NS records for domain2.com have to be checked too to ensure it has the right location to go lookup where ns1.domain2.com really is. You could imagine the case where domain2.com's NS records point to domain3.com's name servers... This is obviously inefficient and results in a lot of unneeded chasing. So... pointing entirely internal seems like a no-duh, right! Less chasing! But... it also means you need to keep com's notion of your name servers in sync with your notion of your name servers, and when you add or remove them and/or change the IP addresses, you need to notify your com (through your registrar) that things have changed. (tech speak: update com's notion of your glue records).
2) Add an NS record pointing to an external server. This is common for server farms that sell you DNS services as part of their transaction as your registrar (ie, where you went to go buy domain1.com). They set your NS record to something like "ns1.godaddy.com". In your case, the previous zone owner set the NS records to all point to the domain1.com zone. This is actually helpful when you expect to change your address in the future. Rather than have to go change the IP address in all 5 of your zones, you only change it in domain1.com's ns1.domain1.com record and you're good to go. The other zones don't need to be touched. Yay! It's even more yay-full when you are managing 100 zones.
So, there isn't a right or a wrong here... It's a trade-off and different administrators do different things. Feel free to change it to the other model if you don't mind the zone-editing maintenance if you ever change anything. Personally, it's what I do when possible too: I like them internally self-contained. But then, that's also when most people fail to update the parent's glue records to match and there are tons and tons of zones in the world that are out of sync for exactly this reason: "oh, I'll do that tomorrow".
Let's say I have a server (DNS and other), myserver.com. Now I register a domain, mydomain.com, and set it's NS at the registrar to myserver.com - it is therefore the authoritative server, if there is any such thing.
In the authoritative records for mydomain.com, can I set the NS to ns.mydomain.com?
I have two domains set up like that, one works, the other one seems reluctant to propagate. So I'm wondering if there is something wrong with that - I mean how can you resolve the name of the NS when you need to resolve the name of the NS to resolve the name of the NS...
And, If yes, how come parallels plesk sets them automatically in this way?
Ps: there is an A record for ns.mydomain.com on that same server, pointing to the proper IP
There's a solution for this problem - it's called "glue records", i.e. A records hosted in the parent zone that contain the IP addresses of the name servers.
See http://en.wikipedia.org/wiki/Domain_Name_System#Circular_dependencies_and_glue_records
Why would you want to set the NS record for the "mydomain.com":
to "myserver.com" in the delegation record that goes into the parent zone (com.), but
to "ns.mydomain.com" at the zone apex (inside the mydomain.com. zone)
? This creates an inconsistency (two different DNS servers answer the same question with two different answers) without any apparent benefit. You should try to help the DNS system as a whole issue consistent answers.
Unless you have a good reason to make the DNS inconsistent, you should decide what the correct, canonical name for your nameserver is, and publish that name in the NS record both in the delegation and at the zone apex for "mydomain.com".
That being said, it will still work:
If a recursive resolver which does not yet know anything about "mydomain.com" asks about it, it will be told by the gTLD servers to go look at "myserver.com". The gTLD will also issue A and AAAA glue records to help find "myserver.com", but even if they don't, you have A and AAAA records for "myserver.com" in the "myserver.com" zone file (right?).
If a recursive resolver which wants to refresh its cache for the "mydomain.com" NS record, it may query the authoritative server it already knows about. This server will answer that the nameserver is "ns.mydomain.com", with a glue record. This is different from what it had in its cache before, but ultimately it will map to a server with the same IP address.
As for "parallels plesk", I know nothing about that.
I'm trying to setup a subdomain elstest1 on my example.com domain to redirect to a certain IP. Following some instructions on the web, I created an A DNS record.
Currently, if I do this:
dig elstest1.example.com
I get:
...
...
;; ANSWER SECTION:
elstest1.example.com. 14400 IN A 994.93.999.990
(IP address hidden)
Will going to http://elstest1.example.com take me to the IP address above?
Its not working presently, but that's to be expected because the web server isn't up + I just made the DNS changes, etc. But I want to make sure the above DNS settings are what they need to be.
Yes, your record is correct - that's exactly what an A record would do.
If this entry is brand new it should be visible very quickly across the rest of the internet. So called "negative answers" (i.e. "this domain does not exist") are usually only cached for 15 minutes or so, or at worst a few hours. See RFC 2308.
If the entry previously existed, but only just got this value it might take longer, depending on the (previous) value of the TTL. To be on the safe side it's normally suggested that it takes up to a day or two for all caches to flush the previous entry and then pick up the new one.
First, you've created an alias, not redirect. Alias points to IP, not redirects to it. Actually, all domains are aliases.
Second, changing DNS records takes some time. From 15 minutes to 1-2 days. It happens because there are lots of DNS servers in the world, and they all have to be updated.
Will going to http://elstest1.example.com take me to the IP address above?
Indeed, after your ISPs DNS will update.