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

July 27, 2007 12:57 PM

Please help me set up reverse DNS properly for an XServe connected to a network I manage.

I need to set up reverse DNS. What's the best way to do this?

I have an XServe. It's going to be hosting mail and websites for a handful of domains, all of which are handled by nameservers I control.

I can set up the ISP side of this either with one public address NATed and then give the XServe a private address, or I can possibly connect the XServe directly to one or more public IP addresses.

All of the tutorials and forum postings say that reverse DNS is required. They aren't clear on the specifics, however. If I give my server a private address, then even if I point one of my hostnames (xserve.example.com) to the public, internal reverse DNS queries will fail to map it.

Do I set up an internal-only DNS zone? Or, do I put the XServe directly on a public address and give it the hostname of xserve.example.com?

What's the "proper" way to set this up? Point all the domains to one IP, or get one IP per domain? Is reverse DNS something I set up, or is that something the ISP needs to do? If so - what specifically do they need to do?

Any advice would be greatly appreciated, mainly because though I could probably get some hack to work, I would rather know what "professionals" actually do in this case.

Thanks for the advice!

posted by odinsdream to computers & internet (10 comments total)

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 Posftfix for a server that sits behind NAT, though it may well be something that Apple provides an easier config interface for.
posted by Good Brain at 1:32 PM on July 27, 2007

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.
posted by hattifattener at 1:47 PM on July 27, 2007

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.
posted by odinsdream at 3:01 PM on July 27, 2007

I should clarify that I help manage the ISP, so I can adjust the zone files for that side of things if need be.
posted by odinsdream at 3:11 PM on July 27, 2007

Ah, I see.

Reverse-DNS in a nutshell: for the IP address A.B.C.D, you need to have a PTR RR of the form "D.C.B.A.in-addr.arpa. IN PTR somename.somedomain.tld." (where A, B, C, D are the parts of a decimal dotted-quad). The "in-addr.arpa." domain is set aside for this purpose.

On the ISP's side, there's presumably already a zone file for any address space they own, and they can just put that RR in there (and remove any generic entry they had for that address).

For your private IP space, it's trickier, since you'll need some way for internal requestors to end up querying your internal zone file. This might be what split-DNS is for, I've never set it up.

I think the reverse DNS for your internal and for your external addresses are basically separate problems.

If you're talking to your Xserve from another Mac that's on the same network segment, you might be able to rely on Apple's multicast-DNS. Each machine will advertise an entry for itself as "machinename.local.", and will resolve hostnames of that form to other machines on the local LAN. This might be good enough for the xserve admin tools to be happy.
posted by hattifattener at 4:49 PM on July 27, 2007 [1 favorite]

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?
posted by odinsdream at 6:08 PM on July 27, 2007

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< - opcode: query, status: noerror, id: 40425br> ;; 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.
eriko.us. 3519 IN NS

posted by eriko at 7:40 PM on July 27, 2007

(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.)
posted by eriko at 7:45 PM on July 27, 2007

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?
posted by odinsdream at 7:13 AM on July 28, 2007

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< - opcode: query, status: noerror, id: 60471br> ;; 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 here. 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.
posted by eriko at 5:36 PM on July 29, 2007