Preface I use a top level domain provider that only allows me to add "normal" third-party name servers (a list where i can add "ns1.hostingcompany.com" type entries... nothing else) AND "child name servers" which i can later attach to my parent account ( ns1.myowndomain.com and an ip address). They do not provide other means of linking up.
I want to host my own server and dns, even with just one name server (at first).
My setup:
Airport Extreme - get's a static ip address from my ISP
Mac Mini Server - sits behind the Airport and get's a 10.0.1.2
My problem is that i can't seem to configure DNS correctly. I added a "child nameserver" with my airport's external static ip address at the top level provider, so to my understanding i should have all DNS traffic redirected to my Airport. I've opened port 53 UDP to let the traffic in.
Now, what i don't get is this. My Mini Server is sitting on a 10.0.1.2 address and i have setup dns correctly, with an A record to point and resolve my server AND a reverse lookup to that 10.0.1.2. So it's ok for "internal stuff".
Here is the clicker... How, when a request comes from the exterior for a reverse lookup, does the server "know" ... well look i have everything in 10.0.1.2 but the guy outside needs something from my real address.
I can't begin to describe the MX record bonanza...
How do i set this "right"? Do i "need" my Mini Server to sit on the external address directly (i can see how this could be the preferred solution, being close to a "real" server i have in my mind). If not... do i need a PTR record on the 10.0.1.2 server but with the external address in there?
My dream: I will extend this "setup" with multiple Mini's in different cities where i work. I want a distributed something (Xgrid comes to mind).
PS. Be gentle, i've read 2 books and the subject, and bought both the Lynda Essentials and DNS and Networking to boot, still i'm far from being on top of things.
In this situation you really want to have something like a split-horizon DNS setup, where the answers DNS clients get depend on what network (internal or external) they're on. This can be done with OS X server using the BIND nameserver's views feature -- but Apple's configuration UI only supports one view, and it's going to be a pain to set up and maintain. It's much easier to simply use two separate DNS servers, one for inside and one for outside. I'd recommend using a DNS hosting provider for the external DNS (your top level domain provider can almost certainly do this for you), and having the OS X server provide internal DNS only.
EDIT: to get PTR records properly set up, you actually wind up with a third DNS provider: your ISP. Because of the way reverse lookups are delegated, whoever "owns" your public IP is in charge of providing reverse lookup service for it. You can use NS queries to check this: for example, if your public IP is 12.34.56.78, use the command "host -t NS 56.34.12.in-addr.arpa" to see what DNS server(s) serve PTR records for the block of addresses you're in. If that isn't found it's not delegated that finely, so try "host -t NS 34.12.in-addr.arpa" and even "host -t NS 12.in-addr.arpa" until you get a result.
Here's a breakdown of how I'd set it up, assuming you want your server's primary name to be server.myowndomain.com, the Airport's public IP address is 12.34.56.78, and that you'll be hosting your own website and email:
In the public forward DNS zone (myowndomain.com, served by your registrar or whatever):
In the public reverse zone (probably 56.34.12.in-addr.arpa, served by your ISP):
In your private DNS on the Mini server (note the trailing periods all over; this is very important, to keep it from tacking another ".myowndomain.com" onto the end):
myowndomain.com. zone:
1.0.10.in-addr.arpa zone (this will be built mostly automatically, just make sure the PTR record is pointing to server.myowndomain.com, not just myowndomain.com):
You also need to make sure that DNS queries from your private network are directed to your Mini server, rather than out to the public DNS. If possible, change the DHCP settings to hand out 10.0.1.2 as the DNS server to use; if you can't do this (some models of Airport are annoyingly inflexible), configure the Airport itself to use 10.0.1.2 as its DNS server. You shouldn't need to forward port 53, as you should never get DNS lookups from outside.
Then, when you set up a second office w/server in another city, assuming it has hostname 2ndoffice.myowndomain.com, public IP 91.92.93.94 and private IP 10.0.2.2, you'd add (note: please make sure the private IP ranges at the offices do not overlap, or interoffice VPNs will be nearly impossible. In fact, if possible I'd change the IP range you're using now, as that's a very popular range, and someday you'll want to VPN in from a client/hotel/Starbucks/whatever that uses that range…):
Add to public forward DNS:
In the new public reverse zone (probably 93.92.91.in-addr.arpa, served by the ISP in your new office):
Add to your first-office private DNS, myowndomain.com zone:
And in the new office's private DNS:
myowndomain.com. zone:
2.0.10.in-addr.arpa zone:
If you set up a network-to-network VPN between offices, switch both servers' private DNSes to serve each other's private rather than public IPs.
Is the air port a DNS server? if so than forward port 53 TCP AND UDP or do you want your Mini to be the DNS server? As far as the local vs public thing, it will hand out anything it has and the client will close some programs might have logic to detect the local IP and throw it out but I highly doubt it. I'd suggest using .local for your internal stuff and .com for your external stuff. Or if you realy want to use .com edit your hosts file. Unless you have a mail server you don't need a PTR but you can't just use your external address as your ISP is the authoritative server. You may be able to get them to delegate to you but if not they will most of the time host the PTR for you. If you want your primary mail server to be your mini then set a MX of myowndomain.com with a priority of 1.