we have a customer who is using a lot of subdomains for special project servers and thus want to separate them from the webspace of the main domain. So far so good, this can easily be done via a subdomain as secondary domain.
But those naturally get their own zonefiles set up automatically. Since those subdomains are only running webapps and no Mail, FTP and nothing else, all I would actually need is the one CNAME entry at the main domain instead of a zone file for each and every subdomain.
I am tending towards simply deleting the zone files and setting them as CNAME records for alls subdomains (much easier to manage). The other, much more tedious way would be to edit each subdomain zone file and throw out all the obsolete stuff (MX, SPF, CNAMES, NS etc.). But I guess thers is absolutely no reason to do that and deleting the zone files is the way to go.
I hope you don’t mind my thoughts, and we have similar clients, but my thoughts have always been the same, the resources are used when referenced and they would never be referenced, therefore there usage is negligible in my mind.
My concern is if the template is used in overall zone settings, you would be changing these as well, but as I said above, I have never concerned myself with the extra dns records as they would never be referenced.
I’m sorry if that sounds lazy, and you would be correct, it is, but it is so small to me it does not matter against the size of our drives.
I’m sorry if I am wrong and other users may have third own ideas, which may be more preferred.
Hmm, theres actually one more thing: When I set up a subdomain as secondary domain, it’s zone file is created (see above) and it is listed under “Secondary Domains” in Sitworx with its IPv4 address. Now if I delete the zone file and just give it a CNAME under the second-level domain, this entry in Sitworx is naturaly still there.
So my guess would be, the iworx-server still has the subdomain assigned to that IP but it doesn’t matter as any external DNS request points to the CNAME I’ve set up, right?
Or am I screwing things up this way?
So you’re saying simply ignore the zone files? Maybe you’re right, but I know I would get up one night, walk to the PC and clean them out I know, OCD… hehe
But what I take from your answer is, my thoughts were correct… Thanks - as always.
I’m sorry, it’s late here and I’ve had a cold beer, sorry, it’s been a real hot day.
I’m thinking it might also involve the vhost file, but could be wrong and may be worth having a quick check in case there’s anything referencing the subdomain etc…
I could be wrong sorry and I’ll have a think and reread tommorow if alright.
To answer your dns question, if external dns request, I would think your correct but internal may not be a dns request but referenced in vhost file.
I call that playing Star Wars, which I once did and brought a server down for hours, was called into a board room meeting to explain, oh… Only ever did this once and never forgot it.
jep, you’re right about the IPv6 entry. But for DNS there are A and AAAA records for both. You say some internal means. Maybe the {ipv4} variable is accessing that record? Can someone from iworx confirm or explain?
Those records are required to correctly use dns and they identify both the ipv4 A record and ipv6 AAAA record, this allowing dns to distinguish between the 2.
sorry, not sure what you are saying. But to define the ipv4 record you use an A record and for defining ipv6 you use AAAA, so why the need for creating additonal ipv4.{domain} and ipv6.{domain} default records?
I’m not saying they are useless, I am trying to learn what they are good for and since I couldn’t find much on the subject on the web either.
Hey John, yep you really got confused or I simply didn’t write it clearly Sure I know about A and AAAA records, that was I was saying. What I don’t know about are the additional ipv4.{domain} and ipv6.{domain} records.
I know, OCD… hehe
