The new "improved" Tiger DNS Configuration GUI has severely limited the ability of the SysAdmins to configure the DNS records the way that they want to.
You should file a bug http://bugreport.apple.com explaining the difficulties you are having.
The only way that they will get a clue about how badly they have "broken" DNS for administrators is by the users filing bug reports.
Also, the documentation is severely lacking. (separate bug report)
As for how to set it up, sorry, I haven't found anyone yet who's been able to do it to their liking. (where "to their liking" is defined as "like I had it in 10.3.x")
thank goodness i'm not the only one who thinks the new DNS setup in Server Admin is stupid. its so limited. i can't get my head around it. i've turned to Webmin to setup DNS instead because its far more powerful and i find it easier to use than the 10.4 server admin utility.
BTW, www.webmin.com. check it out. great for setting up DNS zones and records and heaps more.
I had to go back to hand writing named.conf & /named/*.zone in order to configure DNS.
Admin server is completely useless and a back step when compared with its predecessor in 10.3.x server.
An update of Server Admin is a must now.
Alternatively I'm also using Webmin but Id prefer to have all admin tasks concentrated in a single app that's why we pay a lot of money for Mac Os X server...
exactly. i think apple changed the DNS components of Server Admin with the idea that it would make things easier and faster to configure, but all its done is completely changed the logic behind how DNS is set up. The first time I saw the "Machines" tab and read about Machine Records i was stumped - "What the heck are machine records?!" I've only just got my head around the difference between NS, A, CNAME, MX and PTR records about two weeks ago, and now apple expects me to re-educate myself all over again just so I can use their software (?). strange. very strange.
on the upside, i still think webmin or manual editing of the DNS files is the way to go for now, at least until apple (hopefully) update the DNS part of Server Admin and make it THE WAY IT WAS BEFORE !
I'm not laughin...
I don't want to edit named.conf and var/named/*.zone because I don't have time, I'm afraid of the gui later overwriting my changes, and it's too unapple-like an defeats the purpose of having the gui... so I am trying to figure out tigerz "new logic" to see if I can get a dns configuration comparable to what I was able to do with panther...namely, an authoritative master server with one slave, that gets example.com and www.example.com to the same site.
The first major difference I noticed--even before I got to the "machines" tab--was the different zone layout, with the separate tab for "secondary zones," which seems easy enough to adapt to: master zones go under zones; slave zones are in the "secondary" zones.
But when I added my first master zone, I noticed the new "server name" field and its tendency to create a dimmed-out uneditable entry for the first name server, that is for the SOA for the zone... what if I want a different machine to be the primary nameserver? Even if I add additional nameservers, it won't let me delete its dimmed out version.
Then, in the "machines" tab, I noticed that it already had its "server name" from "general" tab listed as the first "machine", and when you edit it, or create new machines, it tells you in the "hostname" field that the "hostname" will be the basis of the "A" record; it lets you ad an mx record with precedence option which will create the MX records--and it lets you add aliases which, become CNAME records.
Although one of the advantages to this new logic is that you don't have to wonder whether field required a fully qualified entry with a trailing period, or just a relative entry, as you had to in panther--and there's not the "flakey gui alert" where the trailing period gets deleted and has to be entered a second time--but there are of course the new set of limitations inherent in the new logic:
Everytime a new master zone is created with the same ip of a previously created master zone, the new zone replaces the ptr record which gets automatically created everytime you add a machine to a zone, so whenever you are done, you have to check var/named/db.ip.ip.ip and correct the ptr records to point to the domain names you want fully qualified...
Another limitation is that there doesn't seem to be a way to create an "A" record for a domain without a "machine," that is, just plain old example.com, instead of machine.example.com; tigerz gui only creates relative A records; so how do you get example.com going to the same root folder as www.example.com?
The documentation suggests that you do this in two places: in the "machines" tab, edit a machine and add "example.com" as an alias; and also, in the "Web" pane, under "settings" and "Sites" there is an "alias" tab where aliases for the domain can be added; this is not a dns setting, but adds the "ServerAlias" directive to the site configuration files found in /etc/httpd/sites/*.conf.
So, in Tiger, I can almost get the GUI to make the necessary configurations; except, I can't get example.com to go to www.example.com, because I cannot make a CNAME record for a null field. In panther, I did it the other way around, and made A records for example.com, and made "www.example.com" the alias, and was able to get both example.com and www.example.com to the same site that way.
Also in Tiger, there is still no way for adding forward dns zones with gui? At least I still had to go and add the forward option to named.conf.
Has anyone figured out how to get example.com and www.example.com going to the same place with just the GUI in tiger?
Overall, I think that the reason for the "new logic" is that the new GUI is less capable of creating flawed DNS setups, such as multiple A records on the same ip and domain, and forces those newbes like me, laughable though we may feel, into a better understanding of dns.
Well, I am lauging now:
I found the silliest way to get the GUI to do what I want it to, which is making both example.com and www.example.com go to the same site!
I think this has to be completely wrong, but it works, especially if you have multiple ip's to play with. Here's what I did for example.com:
1) clicked "+" under "zones" tab to create new zone
2) zone name: com
3) server name: example
4) server ip address: ip of primary nameserver for example.com
5) clicked on "machines" tab and selected "example"
6) clicked "+" to add alias called "www.example"
And when I saved and started dns service, the correct RR's were created!
However, when I went to GUI to get it to create RR's for next site, say example2.com, I did not have to create a new zone for that site; rather, I only needed to create a new machine in the "com" zone, which I did, and I called the new machine "example2," and I edited "example2" and added an alias called "www.example2".
After saving and restarting dns service, there was A records for example and example2 and CNAME records for www.example and www.example2 in the com zone, and the "host" command was working forwards and backwards for both domains!
By the time I had completed this for about 30 more domains, I had created a zone for each top level domain (com, net, org, info, biz), and had many machines in each zone.
The drawbacks to this method, as far as I see, is that each machine within a master zone must have a unique ip address--I had to have an ip available for every .com site; I couldn't create a different "com" zone, because there cannot be two master zones with the same name. This poses some obstacles to name based virtual hosting, but you can have ip's with multiple sites, as long as each site is in a different zone...
An advantage to the method is that it looks like it forces a type of load balancing (round robin?) by spreading out services accross so many ips.
Was this completely wrong? It seems laughably silly to create zones for tlds. But it's working for me.
I don't think this is right. If you do this, then do your machines get access to the internet (.com) domains if your server is authorative for the domain? The suggested method is saying that only example.com and so forth are the only machines that exist on the .com domain....if you are using this dns server as the authorative server.
Yes this method does create the desired effect of the zones, but essentially broke everything else.
Thanks for keeping the community alive!
I would love to see a couple of screen shots of what you have done. I find the written explanations quite tricky to follow and prefer a visual to help me understand.
Unfortunately the Mac OS X Server Visual Quickstart guide is 10.3 only and does not include the new DNS GUI in 10.4. Hopefully there will be an amended version - or maybe an "errata".
Otherwise I recommend this book, and am looking forward to grabbing the new O'Reilly book on OS X Server too.
So if you could post a screenshot, or maybe email me at hamish @ blair - dot - com - dot - au I would appreciate that very much!
This must be why I thought it was silly and surely couldn't be correct... looks like it's back to manually editing named.conf.
Though, for the sake of understanding how DNS works, and because it is way more convenient to use the GUI, what will happen if I leave msyelf setup as root server for "com" -- will mib from icann show up and arrest me? Am I harming the overall integrity of dns system? I can't afford O'Reily DNS & BIND books, and so I totally rely on the free documentation to try and cope... all clues to dns are always appreciated