Newbie needs mega help - Dynamic DNS, Open Directory, iChat...

If you don't have an investment here yet, then rip it all out and start over. Wipe and reload. If folks have been whacking away on the box, who knows what weirdness you're dealing with.

Then, first and foremost and before anything else and in the beginning and bar none and don't skip this and start here and never forget and always get [static-addressed DNS configured and going|http://labs.hoffmanlabs.com/node/1436]. First. Skipping this step is Very Bad.

Ok, so I kid. Just a little.

You can run DNS Server on the local box, or you can get this stuff set up on the local LAN. But Mac OS X Server really wants functional DNS, and if you skip this step, various services and sequences Get Weird. You don't have to make this DNS available and visible outside your LAN (and particularly if you're using NAT and a private IP address space), but you do need DNS.

Then deal with the rest of the services here.

(And strangely enough, I'll be in Albany Real Soon Now, too.)

+One question: You wrote as one of the steps "Select the forwarding server(s) as your upstream ISP DNS server(s), or you can configure Google DNS as your forwarding servers." in Settings - are you referring to the "Forwarder IP Addresses" box???+

Yes.

siobahn wrote:
Hello again - in terms of the DNS, I followed the instructions you sent (total wipe and reconfig) but I was not successful...I am still getting "The DNS hostname is not available, please repair DNS and re-run this tool" errors

I'm guessing that you missed or misinterpreted this sentence: +You'll have references to your new DNS server entered in your DHCP server(s) (in an Airport Extreme, Time Capsule, Mac OS X Server DHCP Server box, or firewall/router), and also set within any static-configured NICs you might have.+

I've re-worded that sequence to clarify the requirements.

In particular, what DNS server is the NIC on the Snow Leopard Server box aimed at?

Machine Name: myservername (Fully Qualified is NOT checked)

That looks wrong. You need FQDNs here. +Add a forward primary zone for example.com. (note that trailing dot), and select the DNS server for that zone as 192.168.1.30 or whatever the IP address of your host (and now your DNS server).+ In particular, +note that trailing dot.+

Under that:
IP Addresses:
IP Address: 192.168.1.xxx (the static IP we assigned on the router to the box)

Terminology: IP routers don't typically do that; routers don't assign addresses. DHCP servers can. And you do not really want to involve DHCP here; you just want DHCP not to issue the address(es) you've manually assigned to the static servers boxes and static network resources (like the router).

Reverse Info:
Reverse Zone Name: 1.168.192.in-addr.arpa.
Nameservers:
Zone: 1.168.192.in-addr.arpa
Nameserver hostname: myservername.mydomainname.com
Reverse Mapping states:
Resolved 192.168.1.xxx to myservername.mydomainname.com

Please don't obfuscate. Don't obfuscate DNS names. Don't obfuscate IP addresses. You don't know what you're doing with DNS yet, and attemping obfuscation means I can't see what you're actually working with, which means I can't spot mistakes you don't know you're making quite yet.

FWIW, you probably don't hold a registration for mydomainname.com; that's a registered domain, and it already has DNS servers out of Dotster. If you really want to use an obfuscated example domain here, then use example.com, example.net or example.org. These domains are RFC-reserved for this purpose. (This also goes to why I don't recommend making up and using an unregistered domain name; if you've thought of it, chances are somebody else already has or will soon register it.) Don't use domains you have not registered. And if you're going to make something up, use example.com, etc., as that is clearly a made-up domain.

What does the following show:
dig -x whateverIPaddressIsYourSnowLeopardServer
dig whateverDomainNameIsYourSnowLeopardServer

for your boxes both on your local Snow Leopard Server, and from one of your other client(s) that is now configured to use this new Snow Leopard Server DNS Service via static NIC setting or via its reception from your newly-configured DHCP server?

I've strengthened and extended the wording in various sections of [the DNS article|http://labs.hoffmanlabs.com/node/1436] in the areas described above; I've used your confusion as feedback to try to improve the text.

Like I mentioned in my first post, this Snow Leopard server that I want to run DNS on(heretoforth known as "mini" below) is behind a firewall (a DLink box) that is getting the dynamic IP address for the domain name (unifiedmediagroup.com) via DynDNS and then routing all traffic pointing to that domain to the "mini" box (which has an internal IP of 192.168.1.127).

You have DynDNS DNS servers involved and your own DNS server involved, and that's a conflict; you're trying to have two disjoint sources of DNS data, and both believe they're authoritative. Which means it's anyone's guess what's going to happen when the box requests a translation. And which means your host configuration is probably going to be cranky.

Pick DynDNS for your public domain information.

Pick your own DNS for your private DNS, and as a linkage out into the public.

This is what I describe, and why I keep coming back to that one-outward reference to the ISP DNS server. You have two (and disparate) DNS server references here.

The NIC on "mini" shows the following when I check the DNS server:
127.0.0.1
192.168.1.1 (this is the IP of the firewall from inside).

So your Mac Mini can get its own DNS with its own view of unifiedmediagroup.com via 127.0.0.1 and it can get a second and separate and disjoint and also authoritative view of unifiedmediagroup.com from your ISP DNS servers? That's going to be a problem.

That's what I had intended to reference with the: +The only references to your ISP DNS servers or to Google DNS or such will be as forwarding entries within your DNS server.+ You have two references here.

Put another way, get rid of 192.168.1.1 reference here. Get rid of the ISP DNS reference inside the D-Link box, too. You should refer only to 192.168.1.127 in both places. The only reference to your ISP DNS or to Google or otherwise should be in your own DNS server, or in any local client(s) you intend to completely bypass your own local DNS server.

In terms of your statement "You'll have references to your new DNS server entered in your DHCP server(s) (in an Airport Extreme, Time Capsule, Mac OS X Server DHCP Server box, or firewall/router), and also set within any static-configured NICs you might have.", I don't have a good sense of where/how to reference it on the DLink router, at least as it pertains to DNS, other than to tell it to forward all traffic on ports related to mail, web, etc to forward onto the "mini" box.

You're going to have to learn how to configure your D-Link gear. D-Link has a gazillion different boxes of varying capabilities and features and interfaces and vintages. I'd expect the ISP DNS Server entry on the main page, or on a DHCP-specific page within the box. How your particular D-Link works, you're going to have to figure out with a trip through the particular manual(s).

As a side-note here while you're looking at your DHCP server configuration within your D-Link box: make absolutely certain 192.168.1.127 is not in the pool of available addresses the DHCP server can issue.

In the near term, you probably don't want to be running your own public-facing DNS yet, which means you won't be allowing incoming DNS queries through your firewall, and your DNS server you're configuring won't be serving public requests. Leave that to DynDNS or to your ISP or whomever is hosting your public static IP, and leave the associated security and redundancy and reliability requirements to somebody else. Get yourself a public static IP address (and that's not the 192.168.1.127 address discussed elsewhere; the whole 192.168.0.0/16 block is a private IP address block), and have that aimed at your own firewall, and have your firewall port-map that through to your internal IP address. To 192.168.1.127 or whatever host will be serving your public static IP address. Have your ISP or DNS provider serve up the translation from your public-facing address(es) to your public static IP address(es).