PTR record
 

Hi guys,

I've been studying for a while now about DNS, Web Servers and Mail and my question is : Why do i really need the PTR record?-i know what PTR is and all about in-addr.arpa domain, but in my opinion things work without it.
I mean what applications or services really need the reverse mapping?

My second question is: Can i put BIND, Apache and Sendmail on the same machine, with just one IP address? Will this setup work?

Probably the best reason to have a PTR record that matches each A record, etc. is that it's the "Right Way (tm)" to set things up. Keeping DNS (this is actually true for a number of things, but we'll keep this confined to DNS for the time being) functioning properly and at its peak throughout the entire net depends on every person who runs a name server doing so correctly. It doesn't take much to cause headaches for both yourself and a lot of other people. Please, if you either don't know what you're doing, or don't plan on setting your name server up properly, don't inflict it upon the rest of us.

That said, the one you're most likely to cause grief for without reverse zones properly set up is yourself. You may encounter some mail servers that won't accept mail from you if your domain name won't reverse-resolve properly, but largely, those rules were relaxed, as there's been a shortage of IPv4 addresses for several years now.

Which apps you're likely to have a problem with is something that depends more on what hardware, software, and policies you have in place for security. On a local network, where you're not constrained with respect to availability of IP addresses, it isn't uncommon to require that an IP address resolves in reverse prior to allowing requests from that address through to or to be processed by pretty much anything. What many network admins do is run name servers with a "split horizon"; you advertise those names you want everyone on the 'net to know about to everyone on the net, but keep other machine names that are only meaningful locally, private. There's some debate as to how much extra security this actually buys you; as far as I'm personally concerned, if it gets me anything, it's worth the effort (it's not very difficult to set up and administer at all).

Yeah, you can; a better question might be "do you want to"? In one situation where a client had only one public IP address, and a pretty low budget, I set up a name server & its cache, a firewall, web server, mail server, etc. on one machine. The problem was that only one host could be designated as "directly connected" to the 'net, all other hosts got their 'net connectivity via a transparent proxy (eg., NAT).

Doing that involved setting up several virtual ethernet interfaces (eth0:0, eth0:1, etc.), and using iptables for both software firewalling and packet forwarding. I wouldn't recommend doing something like that if there was any way it could be avoided; it's not pretty. It has, however, worked, for three plus years now (knock on wood).

Nothing terribly fancy about that setup; it's just plain ol' Linux with plain ol' Apache and plain ol' iptables. I did use djbdns (aka "tinydns") for DNS and qmail + vpopmail for mail in place of BIND and sendmail, though; I've been using qmail, djbdns, etc. for years now (http://cr.yp.to), they're both free - and, they're rock-solid stable, and extremely secure. I'd strongly suggest checking them out.

- Larry

Thank you very much for taking the time to write this post.
But how about this situation: the client has one public ip address. Why do i have to use NAT in the first place?And why do i have to setup virtual interface (eg eth0:0, eth0:1 etc) ?
I can just install BIND, Apache, Qmail and vpopmail just like that on the same machine with just one NIC and one public ip address. The daemons bind to a port (BIND on 53, Apache on 80 etc)
In the zone file for my domain i can specify the same ip address for my website, for MX etc what is problem? The reverse will give different results (BIND uses round robin i think) but the name to ip address resolution will work.

I haven't tested this setup but in my opinion it should work because a client software (eg firefox, another MTA etc) connects to a socket (ip+port combination) What do you think?

Thank you again for taking the time to answer my questions

If you're only trying to connect one interface on one host to the internet then you don't. Beyond that, you're pretty much stuck with NAT, or SOCKS, or some other form of proxying.

How you set up the interfaces, etc. on your host(s) depends largely on your software configuration. For example, djbdns has the ability to separate a nameserver's cache (what local clients ask to resolve names) from the forward-facing nameserver (the server that responds to requests from the outside world; usually, other nameservers). They're two separate services (daemons), but they both bind to UDP #53, which means they have to sit on different addresses.

One caution, though; namesevers (particularly, IMO, BIND nameservers) don't like being NAT'd, they expect to be using a public IP address (remember, a nameserver is designed to do a number of things besides just answer queries on UDP #53). Running the nameserver on a public IP address, without simulaneously making it available on a local, private IP address, has some pretty nasty security implications. Separating out the cache and the nameserver, running the former on a local, private IP and the former on a public one helps out there; it also speeds things up considerably for users on your LAN w respect to DNS lookups. Setting up > 1 nameserver (eg., using a "split horizon" setup, etc.) can help secure things, too. But to do either, you have to have another IP address (an additional NIC, or a virtual interface). In some situations, at least as far as a second, private nameserver is concerned, you might be able to get away with running the thing on a non-standard port; my experience with trying to do things like that is they usually work out to be more of a hassle than they're worth, though.

Does that make a little more sense now?

Another terrific reason for using virtual interfaces is that they make it extremely simple to move a server from one host to another. Say my web server dies. If I have everything set up so that ports 80 & 443 are forwarded to a specific host, then all I have to do is change the address that packets are being forwarded to, and (assuming I set up another web server ahead of time, and kept everything backed up, ...) I'm back in business (that really does work; the last time I had a web server fail, i was able to get everything back up and running in under 2 minutes).

That should be fine. Like I suggested above, it isn't uncommon to route everything at a firewall, and forward packets to whereever they need to go from that point, on.

One last thing; if you're using a consumer-grade (home, small-office, etc.) broadband router to hook all this up, I wouldn't make too many assumptions as to how it was getting packets from any one point to another. Nor would I be too surprised if, say, the web server was only seeing requests from one IP address, ever. And so on. They all have their own little quirks...

Hope that helps,

- Larry