Configure DNS - OS X Server Next Steps

Mr Hoffman,

The original poster's questions along with your suggestions make it seem like the same thing that I am trying to do. I am a newbie as well. I have deleted the downloads each time I retried an earlier version. I do have my own post, but did not ask the right questions apparently. I will copy what I was replying to from his post and post it in my OP. Here is link to my OP: https://discussions.apple.com/thread/4108783?answerId=18939433022#18939433022

Thanks

Here's why I suggested another thread. Consider that your "I've downloaded a kit and can't run the installer" is not the same as "how do I configure DNS?". "How do I configure DNS?" might be the end goal of your quest here; of getting the installer working and invoked, but it's an entirely different question. The forum guidelines

Now that you've linked to another on-going thread (that's not a new thread), please ignore my suggestion. (I'll continue here; I could continue there, but this is already confusing enough for me.)

Shut off any antivirus or antimalware or add-on security tools you're running on OS X Server, including any security extensions or other related baggage. If your network firewall has any capabilities for monitoring or filtering your network traffic or malware-scanning features, disable that on your firewall.

I'd ensure that the old installer is deleted. That's not strictly necessaery, but there's also little point of keeping a busted installer around.

Then launch the Safari web browser on your Mac OS X Server system, and navigate to the Server Tools 10.7.4 (DL1528) download and download the kit directly to your system. (Finding this stuff involves starting at the downloads page, navigating to the enterprise servers and software, and then digging up the tools. Or using Google or Bing, and going after it more directly.)

Once the download has completed, move to your downloads folder using Finder, and double-click on the download. Then (once the Finder window opens), double click on the installer.

If that's what you've been doing, I'd try the download from another network; on the off chance there's a corruption arising within your network connection, WiFi or related mechanisms.

Maybe another viewpoint will help. Maybe not, but here goes... 🙂

Working back from the assumption that your web site is correct, and that the example dig is correct, my first dig shows that my DNS is set up correctly.

Well, 'correct' is a relative term, here 🙂

The dig shows that the server is responding to a request. So in that respect, yes, the server is 'working'. I think MrHoffman's point, though is that the result of macserver.macserver.local is questional, at best.

Think of it another way - think of an actual, real domain - heck, let's call it 'apple.com' for sake of argument. What you have here is essentially, a machine called 'apple' in the 'apple.com' domain - i.e.apple.apple.com.

That might be what you were aiming for, and that's OK - I guess - but I think MrHoffman's point is that it more than likely points an an error in your setup (or thinking) because you're using .local as the TLD.

If you extrapolate your domain records, though, you're going to end up with things like 'client.macserver.local', 'printer.macserver.local', 'otherserver.macserver.local' and so on - this starts to make less sense since there is no direct relationship between 'maserver' and the 'client', 'printer' and 'otherserver' hosts. 'client.local', maybe, but not 'client.macserver.local'.

You would be far better off scrapping the entire .local setup - let the OS handle that itself, and use a completely different domain for your local network. This opens the question of whether it should be the same domain (e.g. company.co.uk) as your public domain, or something a little different (company.net) or something completely different entirely (mynetwork.com).

If you choose the same domain as your public domain then you will, by extension, implement split-horizon DNS which is where people get different results (or, at least, can get different results) based on where they are - external users would get a public IP address whereas internal users could get a different, local address.

If all your services (mail, web, etc.) are externally hosted then this isn't a big deal, but if you run your own mail server or web server then it becomes more important.

MrHoffman's point (and recommendation) is that you use a different domain for your internal network to avoid the administrative overhead of split-horizon. If it's done properly your users won't notice or care.

At the end of the day, though, as MrHoffman mentioned, this is your own internal box. The sole scope of people affect by any errors are... well, you and maybe users on your LAN (although you're not going to have users on your LAN use this server until you've settled some of the above questions, anyway, so they might not be a factor at this point).

Camelot doesn't interpret my aversion of unicast DNS on .local quit strongly enough. Per discussions with Apple networking engineers, using .local for unicast DNS is not something that they recommend. It's something they've worked to make operate with Bonjour (multicast DNS), but they indicate it's something that probably won't ever work completely right.

The .local top-level domain (TLD) is a "real" TLD (for Bonjour) and it's not a domain where you can register your own domains.

It's perfectly permissible on your own network) to have your own self-invented TLD, too. .FRED or .GONZO are currently open, among many others. If you're going to "squat" in a TLD where you can't register domains, then it's just as easy to "squat" in a TLD that's not going to conflict with a TLD that Bonjour uses.

Though with IANA's recent TLD expansion that's underway, that bogus TLD squatting is going to involve avoiding an increasing number of "real" TLDs. Around a gross of new TLDs is coming online Real Soon Now. Which is where just using a real and registered domain - at US$12 per year, and variously less - or a subdomain of a domain that you already have registered, is usually the simplest solution for your own DNS. That won't ever conflict with another site, and it'll follow all the rules that the rest of the DNS implementations around the planet follow.

Bottom line: stay out of .local when you're running your own DNS servers. Leave that to Bonjour.

DCs PC Repair: this is where the thread confusion starts.. 😉.