I'm trying to learn as much as possible about DNS, and so far I've read most of:
http://www.zytrax.com/books/dns/ch8/soa.html
and all of:
http://computer.howstuffworks.com/dns.htm
I understand that SOA and NS records contain info about the authoritative name server for a domain, but as these are just DNS records, how does the rest of the world even know where to get them?
I assume it starts at the top-level-domain (.COM .NET .ORG, etc) servers. So they must contain a SOA record for my domain? If so, how does that get there? I imagine only registrars like GoDaddy and Network Solutions are able to update those? If they contain a SOA record, why does my DNS server (that I host), need one also? I think there must be something, maybe in the domain registration records (outside of DNS?), that I'm missing.
I think I've got a pretty good understanding of most parts of the DNS system, after reading lots of articles.. but I haven't found any that answer this part, in a way that I understand it.
For example, GoDaddy and Network Solutions both let me change different options (in their web UI) to "host my own DNS server". If these options remove them from the process, so DNS servers never need to query them again, and instead query my server directly (this is what I want, no dependency on GoDaddy/NS)... when I make these changes, what (at the DNS level or otherwise) is GoDaddy/NS doing? Are they asking the top-level-domain servers to update some DNS records for my domain?
Short answer is yes. Godaddy will take care of updating your the TLDs for you. Your other assumptions are also correct except for one small detail...
DNS starts with the "root" domain and then goes to the TLDs (top level domains).
www.somedomain.com. actually brakes down like this:
. The root name servers
com - The TLD name servers
somedomain - Your NS servers
www - The host portion of the dns name.
Setting up your own DNS server is a great way to understand DNS better. Good luck!
So they must contain a SOA record for my domain?
Multiple answers possible, depending on the scenario:
delegated 2nd level:
No; the start of authority of your domain is usually at your level, so the SOA for you.cf is (only) in your nameservers. Same as the SOA for .cf is only in the nameservers of .cf, and not in the root-servers. In case your nameservers are within the same domain (i.e. ns1.you.cf in case of you.cf) then glue records are needed. This means that registry that's operating the TLD's nameservers will insert a A and/or AAAA record with the IP of ns1.you.cf in the TLD zone. Normally you (the registrant) set this in the interface of your registrar.
undelegated 3th level:
No; if your domain was sub.you.cf - but sub.you.cf wasn't delegated (no NS records exist for sub.you.cf) then the SOA is probably at you.cf. Unless...
undelegated 2nd level:
Yes; if you register a domain without having it delegated (no NS records exist for you.cf) then the SOA is at the .cf nameservers. Although most registries run delegation-only zones, some don't. Example: when you use url-fwd'ing in .cf. The SOA then is at the cf level.
Related
I would like to create a subdomain off of my main domain for accessing my raspberry pi at home. My domain register company charges £10 for every subdomain so I thought there might be an easier (and cheaper) way of creating one. It would also help if I knew a little more about them and how they are created.
DNS is built off of a hierarchy for scale-ability and/or for granularity.
If we take the a domain like www.stackoverflow.com. and break it down, here is what we get.
www - This is the host portion of the domain. It is either an A record or a CNAME and eventually points to an ip address.
stackoverflow - This is one of the domain levels. It has it's own DNS servers and config managed by the stackoverflow team. This allows that team to manage the entries specific to their needs.
com - This is called a TLD (top level domain). All other domains that end in .com have an entry on the "com" dns servers.
. - This is called the ROOT. There are 20 somodd root DNS servers scattered around the world. These servers are used to identify where the .com, .org, .edu, .gov, etc dns servers are.
From a client perspective what happens when you query www.stackoverflow.com is:
You query the . name servers to ask where the com dns servers are.
You query the com dns servers to ask where the stackoverflow dns servers are.
you query the stackoverflow dns servers to ask where www is.
A subdomain simply means that you add an additional layer of DNS servers in the mix so that you can add more scale-ability and/or granularity to the mix.
For example, if our dns name is: www.foo.stackoverflow.com we would now have the foo dns server layer.
Having said that, I do not think that you need a subdomain. You probably just need an additional DNS A record or CNAME. For example:
raspberry.stackoverflow.com instead of raspberry.foo.stackoverflow.
They should not charge extra for additional host entries (A record or CNAME), only for subdomains.
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".
Is there a big difference between setting a DNS Zone to have type foward;, and setting an NS record for another name server in the zone file? Does one have better performance/speed? Or am I completely missing the point, and they are completely different?
So there is a difference between the two scenarios... adding NS records is creating a delegation (and you can only do so for subzones when you are authoritative for the parent zone, adding forwarders are simply that. Performance/speed don't really come into it as they are used for different purposes.
Delegation is used when you want delegate the management of a subzone to another server. E.g. you own corp.com, you could delegate the subzone of engineering.corp.com to the engineering team's name server. This is how the whole Internet DNS hierarchy works, zones are delegated down from the root.
Conditional forwarding is used when you want to directly bounce queries sideways to a specific name server which is responsible for a specific domain. If the owner of corp.com bought company.com then during the merging phase when you want internal DNS access available to both companies, you may want to add forwarders for each company in the other's name server, the servers then know where to forward queries to directly instead of traversing the Internet hierarchy and getting the external name servers for either company.
Steve
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 have a server that already has a domain, lets say mysite.com but i want to put another site on it with the domain mysite2.com.
So my questions are, how do i set up the nameserver settings.... My first domain i have listed
ns1.mysite.com
ns2.mysite.com
So would it work if i used:
ns1.mysite2.com
ns2.mysite2.com
for my new site?
Also, i have to set up "glue records". These are the ns1 and ns2 from the nameserver and provide the ip of my server. So for the mysite2.com would i use ns1.mysite2.com and then the ip would be for example 111.111.111.111/MYSITE2 ? Because the glue record for the first site is just 111.111.111.111.....?
Hope this isn't to confusing, i'm just new to this stuff and want to understand it a bit better and i don't want to mess my original site up in anyway.
thanks for the help.
Your DNS records don't have to be within the same domain as the one they host. If you are running your own DNS servers, they can live inside your primary domain. But if you're using another DNS provider like zoneedit.com or easydns.com, just use the hostnames they provide.
"Glue records" are the NS pointers that let the root servers find the DNS servers for a particular domain. For example, there might be:
mysite.com NS dns1.example.com
mysite.com NS dns2.example.com
mysite2.com NS dns1.example.com
mysite2.com NS dns2.example.com
Note that this is entirely different from where your domain's web site is served. For that, you just configure the DNS for each of these domains so that the IP address for the "www" host (and probably the domain itself) points to the same IP ... then you read your web server software's documentation on how to set up "named virtualhosts".
Are you clear on the distinction between DNS hosting and web hosting? If not, I can go into more detail.