What's the best way to route DNS to a server?

Whatever you settle on, you will need the ISP to set up reverse DNS for you, either by creating the entry on their server, or delegating to a DNS server you control (if they'll even do that). If the Xserv is on a private address, you may have to do something so that it uses the public IP in it's headers. If my quick googling is correct, OS X server uses Postfix for the SMTP MTA. This gives instructions for configuring http://www.postfix.org/BASIC_CONFIGURATION_README.html#proxy_interfaces, though it may well be something that Apple provides an easier config interface for.

I assume the reason you're doing this is so that outgoing connections from the Xserve to the public internet will trip fewer spam filters, etc., and have your domain name in the logs? This is specifically for outgoing mail, or for some other protocol? In any case, what you need to do is figure out what IP address the rest of the world will see the connections as coming from. Since you're behind a NAT, it'll be your NAT's external IP address. Then find the server that responds to reverse-DNS lookups for that range of IP addresses — almost certainly your ISP runs this server, or possibly their upstream ISP. Then send them mail saying, "Hi, can you set the reverse DNS for xxx.yyy.zzz.www to point to happyserve.foobly.com? kthx". Every ISP I've dealt with has simply done this on request, but some will try to charge you for it (although it's just a one-line edit to a file and it doesn't incur any overhead on their part). (Make sure that happyserve.foobly.com resolves back to xxx.yyy.zzz.www, of course.) If the admin on the other side has a clue, then the easiest way to find the address of the responsible party is to look at the name server's SOA (start of authority) record. If the IP address is A.B.C.D, then you can do "nslookup -type=SOA C.B.A.in-addr.arpa." and look at the "mail addr" line of the result. Replace the first dot with an at-sign and there's the DNS administrator's address. Or if they don't have a clue, just mail your ISP's customer service.

Actually, hattifattener, that's only part of the reason. The main reason is that apparently many of the built-in tools for managing the server require that reverse DNS entires are properly set up. I'm having a hell of a time testing out the Server Monitor here at home where the XServe is assigned a private IP address, even though I have static DNS mapped to my ISP's public address. The problem is that the actual XServe IP address needs to match some reverse DNS entry whether or not it's a public IP address. Also, could you tell me a bit more about what needs to be done on the ISP side specifically? I'm familiar with BIND, but not well-versed in it.

I should clarify that I help manage the ISP, so I can adjust the zone files for that side of things if need be.

Since the ISP in this case gets a block of addresses assigned from the local monopoly, can I assume that the PTR records are actually set up on their end, rather than ours?

Yes. Unless you own the netblock, you're dealing with a provider delegated netblock. Almost no providers will delegate reverse lookups. However, almost all of them will gladly install PTR records for you. When I was setting up eriko.us. I emailed Speakeasy with the PTR requests. They promptly pointed out that I'd flipped ns-1 and mail.eriko.us in my request. That's the sort of customer service that I like. All you usually need to ask is "Can you install a reverse record for host.subdomain.tld, please?" You don't have to tell them the actual IP (and you shouldn't -- they can find that by looking it up in DNS, and if they can't, you're not ready to have the PTR record installed.) And this comes up often enough that I'll post it here. The format to check with dig. First, the a record. dig host.domain.tld a and then the reverse dig D.C.B.A.in.addr.arpa ptr (where D.C.B.A is your ip address reversed.) Real life example, using the +short flag to keep this reasonable.~ -> dig +short mail.eriko.us a 66.93.192.242 ~ -> dig +short 242.192.93.66.in-addr.arpa ptr mail.eriko.us. If they match -- the A record returns the IP, the reversed IP returns the same name, then you're good. However, the most important test is the "dig domain.tld any" -- make sure you're presenting MX, NS and SOA records correctly. Example, once again from me, using the full dig output for clarity. ~ -> dig eriko.us any ; > DiG 9.3.2 > eriko.us any ;; global options: printcmd ;; Got answer: ;; ->>HEADER;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 6, ADDITIONAL: 7 ;; QUESTION SECTION: ;eriko.us. IN ANY ;; ANSWER SECTION: eriko.us. 3519 IN MX 20 ns-1.eriko.us. eriko.us. 3519 IN MX 10 mail.eriko.us. eriko.us. 3519 IN SOA ns-1.eriko.us. hostmaster.eriko.us. 2007042201 28800 14400 2419200 86400 eriko.us. 3519 IN TXT "v=spf1 mx ~all" eriko.us. 3519 IN NS ns-1.eriko.us. eriko.us. 3519 IN NS ns-2.eriko.us. eriko.us. 3519 IN NS ns2.mydyndns.org. eriko.us. 3519 IN NS ns3.mydyndns.org.

(oops -- a little trimmage there, but it was one more nameserver.) The things to note -- you have to have a SOA and at least one NS record for a domain to work (and that NS record has to match the SOA record.) You should have more than one name server, thus, more than one NS record. If you want to get mail, you need at least one MX record. All of the hosts named in those records need A records, and the SOA record needs a PTR record. The NS and MX records *should* have PTR records as well (indeed, every A should have a PTR.)

So, what I'm taking away from all of this: Get my domain nameserver records correct - I think I can handle this, since I've at least dealt with this stuff before. Get a public address from my ISP pushed directly to the XServe, and ask them to add a PTR record to one or more of the domains I'm pointing to the XServe. Check the DNS configuration both ways with dig commands. Give the XServe a real hostname, like xserve.mydomain.com. That gets everything working for clients connecting from outside the network. However, as far as connecting the XServe to a private network - should I just use the 2nd ethernet port and attach it to a private network? If so - what do I do DNS-wise? I can run a DNS server on the XServe, but what do I need to do as far as PTR records and such go?

If so - what do I do DNS-wise? I can run a DNS server on the XServe, but what do I need to do as far as PTR records and such go? You run two DNS services, one for the world, one for the internal network, or you use BIND 9 and views, which return different answers depending on the source address. I'm really glad that I used the example above that I did, because now I can show you the magic of views. Watch what happens when I do the same lookups from my desktop at home.eriko2 ~ -> dig +short mail.eriko.us 192.168.0.25 eriko2 ~ -> dig eriko.us any ; > DiG 9.3.3 > eriko.us any ;; global options: printcmd ;; Got answer: ;; ->>HEADER;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3 ;; QUESTION SECTION: ;eriko.us. IN ANY ;; ANSWER SECTION: eriko.us. 3600 IN SOA ns-1.eriko.us. eriko.eriko.us. 2007051301 10800 3600 604800 86400 eriko.us. 3600 IN NS ns-1.eriko.us. eriko.us. 3600 IN NS ns-2.eriko.us. eriko.us. 3600 IN MX 20 ns-1.eriko.us. eriko.us. 3600 IN MX 10 mail.eriko.us. ;; ADDITIONAL SECTION: ns-1.eriko.us. 3600 IN A 192.168.0.21 ns-2.eriko.us. 3600 IN A 192.168.0.25 mail.eriko.us. 3600 IN A 192.168.0.250>>>Note how all the answers are different, and are returning private addresses. ns-1 and ns-2 are the same boxes that were answering before, but since the request came from inside, they give the internal view. If the request comes from outside, they give the external view. (At my office, there are *four* views -- internal, external, vpn, and dmz.) More on views http://www.oreillynet.com/pub/a/oreilly/networking/news/views_0501.html It is not only handy, it is *correct* for a machine name to go to the right machine, even if the IP is different. This became a problem with network translation (so that mail.eriko.us is acutally 192.168.0.25, but answer to the net as 66.93.192.242) and view are the best solution I've found. Aside: that advice that you should name your windows AD domain with .local? That's because the authors didn't understand DNS. My AD uses .com, and it works -- if you type www, you get the main webserver. Doesn't matter what network you are on, you get the right IP -- it can be done, and views are how you do it. My network at the office isn't even that complicated, three sites, six routers, dynamic routing.