Configure DNS - OS X Server Next Steps

You're setting up internal DNS services, you referenced your ISP DNS servers and you should not have, and now those servers have no translations for your hosts. This is a common misconfiguration.

See [configuring DNS on Mac OS X Server|http://labs.hoffmanlabs.com/node/1436] for how to set up your internal DNS server.

And if there are any references to your ISP DNS servers here (within your client settings, within your server settings, your Airport settings, etc), then you're usually going to have DNS and connectivity problems. You're running a server now, so you'll be running your own services, and (particularly because of NAT here) referencing only your own DNS server(s).

You may be setting up external DNS (if and when you need that), but that should happen after you set up your internal DNS. The above article has a link to setting up external DNS, when you get around to that, if/when you need in-bound connections into your LAN.

Please don't over-think this, please don't bring along assumptions, and please don't bring along other documents.

Follow what is written in the document that I linked to.

What is written in the document is complete, has been very widely tested, and works.

If you have questions about the document after reading through it, please post them up.

First off, the OS didn't create that document - some technical writer at Apple did, and it was included in the installation disk. Therefore it is as prone to error as any other human-authored document.

Secondly it may or may not be correct - the devil is in the details, as they say. The problem is that there are about 14 gazillion and two ways to configure servers and the document can only cover the most common two or three scenarios. Even if you're in that group it's possible to missed a step (or misinterpreted what it was telling you) and therefore you fell outside of the document's realm of competence.

Thinking logically, you say you do have a DNS record for your server in your DNS zone (when viewed via Server Admin). That's great. Did you also check that your machine is actually using this machine's DNS server for DNS resolution? It doesn't help if your DNS server has the right data, but no other systems on the network are using this server to resolve queries.
In other words, if your server is using some other DNS server on your network (or your ISP's DNS server, or one of the numerous public DNS servers out there such as Google DNS) then it doesn't matter what your zone data contains since no one is querying it. That's the comment that the document says (or, at least, means) when it talks about updating the server that you're using for resolution.

MrHoffman,
I have been having problems, which I suspect are DNS based. I found your DNS Tips: Establishing a DNS Server on Snow Leopard, and like Jimbooo, I'm having difficulties getting my head around exactly what I need to do, I am also very inexperienced in this area.
Can I please ask you to clarify a few points before I dive in and start.
You give 4 options, example.net, subdomain.example.net, example.com and xyzzy.
The Step-by-step guide appears to relate to the subdomain.example.com option, am I correct?
If I set the primary zone to example.com, will I be relying on the forwarder to direct internal traffic for my real website, www.example.com, to the external server where it's hosted?
Thanks in anticipation.
Patrick

You give 4 options, example.net, subdomain.example.net, example.com and xyzzy.
The Step-by-step guide appears to relate to the subdomain.example.com option, am I correct?

Nope. It's the same for all four. I've tried tweaking the wording a little.

If I set the primary zone to example.com, will I be relying on the forwarder to direct internal traffic for my real website, www.example.com, to the external server where it's hosted?

I usually select an internal domain or subdomain, and a different external domain.

This tends to be less confusing, there is less overlap, and there is less parallel maintenance if and as your network scales up. For example, the zone example.net is internal and uses private addresses, and the example.com zone is external, and usually implemented out at your ISP.

Selecting the same domain for both is full-on split-horizon.

As for your question, if your server is authoritative for the zone and has (or lacks) a translation for the host name, then there will be no further communications.

Put another way, you need to have translations for everything your DNS server is authoritative for.

www is a host. If you want a translation, then the www host is an entry in your zone, and has an address. With split-horizon, that IP address might be internal or external, depending on how your IP network is configured.

You'll therefore end up with host www in the internal DNS zone, and a duplicate entry for www in the external DNS zone, if you're running full-on split-horizon. What IP address is associated with each depends on how your IP network and your hosts are configured.

This because your DNS server is authoritative for the zone, and won't go looking for another DNS server that's authoritative for the same zone.

Forwarders aren't involved here and (in general) aren't necessary.

MrHoffman,
Thank you for the prompt reply, unfortunately I still can't get my head around it. I'm either looking at this all wrong, misunderstanding some basic point, missing some vital piece of information, or, I'm just too dumb.
Can I revert to plain English, and try and explain the situation from my perspective?
www.example.co.uk is my web-site, it is registered, hosted on an external server, if anybody in the world types in www.example.co.uk into a web browser, the domain name servers of the world wide web will deliver them to my site. I have no need to host my web-site on my local server.
My local Mac OS X server needs to be a DNS server, I tried turning off the DNS Server service, and it really threw a sulk. From the original install it has the name MacServer.local, which, after reading your tips, I understand is incorrect, I should not have used .local. But it seems to work, most of the time, the only problem I have is that when I'm using some of the server tools, Server Admin, Workgroup Manager, etc. they can be very slow, and sometimes say the can't find the server.
When I dig it I get the following:-

pjharnett$ dig -x 192.168.48.16

; <<>> DiG 9.6.0-APPLE-P2 <<>> -x 192.168.48.16
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28286
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;16.48.168.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:
16.48.168.192.in-addr.arpa. 10800 IN PTR MacServer.MacServer.local.

;; AUTHORITY SECTION:
48.168.192.in-addr.arpa. 10800 IN NS MacServer.MacServer.local.

;; ADDITIONAL SECTION:
MacServer.MacServer.local. 10800 IN A 192.168.48.16

;; Query time: 1 msec
;; SERVER: 192.168.48.16#53(192.168.48.16)
;; WHEN: Tue Feb 15 16:59:39 2011

From my understanding, the above seems to be saying that everything is OK. So, do I need to change the .local, is my DNS OK and should I be looking somewhere else for the problems I have?
Regards,
Patrick

Your dig and your glacial Server Admin performance tells me your internal DNS configuration is messed up.

Your description of your domain of external DNS configuration; that which is outside your gateway.

Follow the step-by-step instructions in the article.

Select the domain (and thus the zone) you will be using.

Set up your internal DNS by following the steps. The steps in the document are known to work, and have been widely tested.

If you have questions, post them.

And no; you do not use .local as your own top-level domain. And that MacServer.MacServer.local. stuff is completely wacky. It looks like the part of the instructions where the existing zones are deleted was skipped.

MrHoffman.
I appreciate your help in this matter, but you are obviously seeing something that I'm not. You say that my dig tells you that my internal DNS configuration is messed up. I can not see how, below I have copied the dig example from your article, and my latest dig, they are identical, except for the obvious difference in names, and IP addresses.

*My dig.*
$ dig MacServer.MacServer.local

; <<>> DiG 9.6.0-APPLE-P2 <<>> MacServer.MacServer.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25222
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;MacServer.MacServer.local. IN A

;; ANSWER SECTION:
MacServer.MacServer.local. 10800 IN A 192.168.48.16

;; AUTHORITY SECTION:
MacServer.local. 10800 IN NS MacServer.MacServer.local.

;; Query time: 3 msec
;; SERVER: 192.168.48.16#53(192.168.48.16)
;; WHEN: Wed Feb 16 14:28:49 2011
;; MSG SIZE rcvd: 73

*The dig from your article.*
$ dig hostname.example.net

; <<>> DiG 9.6.0-APPLE-P2 <<>> hostname.example.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35339
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;hostname.example.net. IN A

;; ANSWER SECTION:
hostname.example.net. 10800 IN A 192.168.21.9

;; AUTHORITY SECTION:
example.net. 10800 IN NS hostname.example.net.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 17 16:12:21 2010
;; MSG SIZE rcvd: 68

Your dig is showing MacServer.MacServer.local which implies that you are not looking for or are not running unicast DNS, or that you are using .local as your TLD, or that you are (incorrectly, confusingly) obfuscating your domain name. Each of these would be an incorrect configuration.

Your second dig shows no response for a bogus and non-existent domain that (if I grok what you're up to there) that you're entering literally.

I am not in a position to grok what's confusing you here (I have no frame of reference), and I can't see into your DNS server. I can try to address specific questions from specific steps in the article. These might be things that confuse you, or that might require further elaboration within the article.

I can't address a general "I don't understand" question, other than to suggest that you get somebody in to load DNS for you, or that you review videos or other materials, or a different explanation might be in order. It's becoming clear that what I've posted is not something you understand (and there's nothing wrong with that), so a different resource and a different explanation might be the path you want to follow here.

First of all I would like to thank you for taking the time to respond to my posts, and also trying to establish an understanding, or grok, as Robert A Heinlein called it. However I feel that we have two very different viewpoints here, I'm trying to understand the basics of an internal DNS, before I do something stupid and screw up a working network, and you are looking at it from the "been there, got the t-shirt, position"
Be that as it may, and before I give up and accept your suggestion to review other materials, I would like to clarify one point about the two digs I posted, and your response to them.
Starting with the second dig, on which you commented..
+Your second dig shows no response for a bogus and non-existent domain that (if I grok what you're up to there) that you're entering literally.+
*This is not my dig, this is your dig,* cut and pasted from your web-site, where it is shown as an example of what a dig will show if your DNS is set up correctly.
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. The only difference being the name and IP address of the DNS server.
Your dig had the name hostname.example.net
My dig has the name MacServer.MacServer.local
What is your reasoning for saying that MacServer can not be used as a replacement for hostname, or example? I accept you point about .local being wrong for a TLD, though the Mac OS seems to like it, but that's another subject, and I suspect we don't want to go there.
Regards,
Patrick

It's your box and your network. Have at. Experiment away. Chances are good that you won't break the Internet, and you'll probably only confuse Bonjour in the worst case.

As for using the .local TLD, the Apple network engineers have publicly stated that mixing unicast and multicast DNS in the .local TLD doesn't work entirely reliably. They recommend leaving .local to Bonjour.

I generally prefer to avoid operating unicast DNS in a domain that somebody else has allocated or has registered, and that includes in the .local TLD. I recommend getting and using a real and registered domain.

The dig command posted in the article presupposes that a host named hostname.example.net in the DNS zone example.net has been established. The response posted in this thread shows it has not.