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".
Related
I have a site where users can point their own custom domain through the use of DNS records.
For example, someone might point example.com to theirsite.mysite.com so that they are free to use their own domain rather than a subdomain.
Which record would be best for users to set up?
An ALIAS record pointing to mysite.com
An A record pointing to xxx.xx.xx.xx
A CNAME pointing to mysite.com
What are the advantages of using each one?
Which is best depends on the specifics of what you're establishing. Here are the differences:
If you set up an A record, the DNS will resolve to an IP and the end user's browser will make a call to that IP with the host name. That's the call that you have to listen for and handle. Since it's direct to IP right from the start, at scale that IP should be a redirector or load balancer.
Otherwise if you need to switch it to a different machine as an endpoint, you have to deal with inconsistencies on how that traffic is routed due to DNS cacheing and whatever TTL you set expiring. Beyond that the biggest issue you're going to run into is that the customer registers their domain and if it's an A record you give them, they're putting in that IP and to change it you're going to have to get the customer to do it, which is definitely not best practice.
CNAME and ALIAS records are similar. In the brief outline you give above, either of these would seem to be better than an A record. You can give them a domain to enter and that doesn't ever change on their side - but you can switch the end IP they're going to as your architecture expands. There are a few minor differences, but the only significant one is that a CNAME cannot be used as an apex record, e.g. example.com, so most likely you'd need to use an ALIAS record.
If you want to read more about the differences between CNAME and ALIAS, there is a good article on it here.
The intent of this post is that I ran into things I had a hard time understanding and wish to implement things in a more professional and objectively better way. Some of my choices I simply don't know to be good or bad. I believe the open questions are very instructive for people that can follow documentation to set up a working local DNS server - but wish to understand and learn how things are done the right way. Hence I opted to ask here!
I have a domain sakujo.tld and use namecheap's FreeDNS service as the authorized DNS. I configured entries for the following host.domains in their zone configuration
nas.home.sakujo.tld, gateway.home.sakujo.tld (A record via DDNS via curl via cron to my router)
vps.sakujo.tld (A record to my VPS on lowendspirit)
*.home.sakujo.tld, home.sakujo.tld (they map to CNAME gateway.home.sakujo.tld)
mysql, ns01, nzbget, sonarr (.sakujo.tld) (they map to CNAME nas.home.sakujo.tld)
So far so good and very simple. I run a home NAS based on Arch linux on an eeePc that can handle quite a lot of things at once apparently. One of them is now a bind installation. My intent is to override home.sakujo.tld and all its hosts but apparently I have to introduce quite a bit of redundancy to achieve those things.
The need for a second zone
I want to achieve a set-up, naively speaking like this
gateway IN A 192.168.0.1
nas IN A 192.168.0.91
phone IN A 192.168.0.41
user2.phone IN A 192.168.0.42
tab IN A 192.168.0.43
htpc IN A 192.168.0.51
tv IN A 192.168.0.55
quad IN A 192.168.0.101
red IN A 192.168.0.111
I was hoping that a zone set up like this one would be all that is needed but sadly this turned out to be too naive and did not suffice. My hopes were that
nas.home.sakujo.tld (and gateway.home.sakujo.tld) would now resolve to 192.168.0.91 (and 192.168.0.1) instead of the DDNS A record on namecheap's external DNS.
That way, if I used mysql.sakujo.tld or for instance sonarr.sakujo.tld, a DNS look up would first find the canonical name (CNAME) nas.home.sakujo.tld (as it of course does) and I was hoping that that canonical name had an A record to now 192.168.0.91 as defined in the zone file above. Sadly, in reality, mysql or sonarr resolve to nas.home.sakujo.tld (which is fine and wanted), but that one still has the external A record as defined on namecheap (the place that also defined the CNAME for nas.home.sakujo.tld).
So in essence I had to set up a second zone. I already had home.sakujo.tld and now I added sakujo.tld. That new zone now uses all the info that is already defined in namecheap's configuration I have externally. It goes like this:
mysql IN CNAME nas.home
nzbget IN CNAME nas.home
sonarr IN CNAME nas.home (I can't seem to get code to work here, apologies)
But mysql, nzbget, sonarr already have the zone entries set on namecheap exactly this way. This seems redundant. Do I have to do this? Or can I make some vodoo entry somewhere on namecheap or in home.sakujo.tld and have it transfer/update/authority whatnot (I really don't understand things from here on out at all anymore, you probably noticed I tried to learn and understand everything that leads up to this point - from now on I am 5 years old).
The # and NS entries
First thing's quick: I don't know what to put into sakujo.tld # A record and just have it point to 127.0.0.1. Ideally I would just leave that entry out as I don't have anything that makes sense to map sakujo.tld to.
Next on, I am told / need to add these lines into the zones to make them "good"
$TTL 30
; home.sakujo.tld
# IN SOA ns01.home.sakujo.tld. postmaster.home.sakujo.tld. (
2015041917 ; Serial
28800 ; Refresh
1800 ; Retry
604800 ; Expire - 1 week
86400 ) ; Minimum
IN NS ns01
IN NS ns02
ns01 IN A 192.168.0.91
ns02 IN A 192.168.0.91
# IN A 192.168.0.1
I know what the TTL is, the comment is probably irrelevant. I am sure I can look up the things in the brackets and I already know the Serial setting. My questions on this one are of more practical nature. Do I need all those entries?
both NS entries and both A records referring them?
The # A record?
The # SOA entry? (I understand this is a very likely yes - heck I ask because chances are this is related to the first paragraph)
I also tried to replace the A record for # with a CNAME entry to no avail. It would not resolve.
Either way, I read a lot that I should have two name servers. I guess it makes sense to set up another external DNS on a VPS? Is that trivial/would be identical to how I set up the first one? I guess there is a relation between the two ns01 entries and the appearance of ns01 in the SOA entry as well.
Are there best practices I am missing?
Are domains even supposed to be set up that way? I currently use two distinct kinds of entries
Unique FQDNs for physical/virtual hosts like nas.home.sakujo.tld for my NAS or tv.home.sakujo.tld for the tv (home being the location, a subnet) - so that is why for instance vps.sakujo.tld is not under home.
Aliases that are semantically labeled. Like mysql.sakujo.tld. This will be my main MySQL server - I currently only use a single db in a MariaDB installation. Or sonarr.sakujo.tld - so that should map to whichever physical machine hosts my Sonarr installation. The advantage of this is that in a year I might use another machine for the MySQL database so the references in my configuration and data should be agnostic of the physical/virtual host .
Maybe there are things I don't see? Even if it is things like "It's more common to name your router portal/router instead of gateway".
For posterity, I pasted my complete /etc/named.conf and zone files. Now that I mention that I don't really know if I need the allow-update and notify settings but that part of the documentation I am able to follow myself (I just thought I'd mention this in case there are questions about why I have them in, I simply don't know)
named.conf
named.conf
zone config
Now that I think about things it would be best to have the following nameservers set up
ns01.sakujo.tld pointing to nas.home.sakujo.tld
ns02.sakujo.tld pointing to the namecheap DNS
Can I use CNAMEs here? Do I have to set up ns0#.home.sakujo.tld as well? If so can I use CNAMEs there?
Edit
Somebody in #bind on freenode wondered why I was using a separate subdomain for my home network to begin with. He advised me to use views instead.
Is it not arbitrary whether I put the hosts on my local network into their own subdomain? After all they are in their own subnet, too and semantically speaking it seems to make sense.
I read up a bit on views, but his advise does not seem to apply to me on a first quick and naive glance. I mean I don't intend to expose my local DNS to the internet so there is no point in having separate zone configuration for different clients. I want all the zone configuration to apply to all clients that use the DNS.
Maybe he was suggesting to use views on namecheap's DNS instead? Would that even work? Also, how would namecheap tell whether I make the DNS request from my home network or an external network to begin with? After all mapping my hosts on home.sakujo.tld to 192.168.0.0/24 would not help all that much when I am not in my local subnet.
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.
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.
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.