Forum Moderators: bakedjake
I need to set up a DNS server on my VPS, but I don't know the proper settings for BIND. The part confusing me is how to set up a reverse lookup zone when I only control one IP. Every BIND howto I've found talks about setting up a server for an entire Class C subnet like:
zone "789.456.123.in-addr.arpa" { ...
but nothing about an individual IP where the host controls the rest.
Any clues are appreciated. :)
Does your new host not allow you to add vhosts/domains to their DNS?
Your message is a little confusing as you first mentioned "dedicated" but the rest of you message refers to a VPS. If you are on a VPS, your hosting company most likely allows (and wants) you to use their DNS server for your domains.
I'm not worried about Apache yet. I can set up all of that stuff once I know I can get all of the domains pointing at my server correctly.
I was wondering how the reverse zone should be set up, so that my IP address resolves back to my domain name. Since my host controls the entire subnet, they said they would host the reverse zone and let me host the forward, which appears to solve my original problem.
Now, I need to figure out how to set up multiple domain names in DNS. I'm guessing that I can just set up several master zones and update the nameserver IPs at my registrar, but I have some more reading to do yet.
Thanks for the response...
It looks like you've gotten the issue resolved. But for future reference, you would configure this as if you actually had control of the entire class-C block. However, your zone file would only have one entry in it for the IP that you managed. The Domain Name System would not be looking to you to reverse resolve other addresses, so it wouldn't matter if you were configured for them or not.
<Now, I need to figure out how to set up multiple domain names in DNS. I'm guessing that I can just set up several master zones and update the nameserver IPs at my registrar, but I have some more reading to do yet.>
Yes, your named.conf would have multiple zones setup in it, your registrar would have a primary and secondary name server for each domain, and each zone would have its own zone file resolving each domain you wish to setup with its IP address. In addition, each zone file would list the name of the server associated with the MX record, and if that host was at a domain that you hosted, you'd want to make sure that you resolve that host to its associated IP address as well.
How would I tell DNS to use me for that one IP? Right now, my IP resolves to ddd.ccc-bbb-aaa.reverse.theplanet.com, but when you look up the forward for that, it doesn't point back to my IP.
I got the forward DNS all set up and working, so I'm pretty happy about that. :)
[acmebw.com...]
Sean
So in this case, it wouldn't really matter what name your IP resolves to, just so long as it resolves to something. It would be proper for your ISP to take that same name and have it resolve back to the IP, but I don't know that it really matters for functionality.
So in this case, it wouldn't really matter what name your IP resolves to, just so long as it resolves to something. It would be proper for your ISP to take that same name and have it resolve back to the IP, but I don't know that it really matters for functionality.
Then what's the point of having the PTR at all? They could all point back to e.g. google.com and you're saying it wouldn't make any difference.
The problem is that there are some things that won't work from the IP address unless the PTR is correct. For example, if you use SSL with Webmin and try to connect to [111.222.333.444:10000,...] it does a reverse lookup and tries to connect to [444.333-222-111.reverse.theplanet.com:10000,...] which obviously doesn't point anywhere. The same thing happened to me with FTP, and as you said, probably POP3 as well.
I've asked my host to update their reverse zone to add a CNAME to my own reverse zone file for my IP address. We'll see how that goes...
Thanks for the help everybody!
For example, if you use SSL with Webmin and try to connect to [111.222.333.444:10000,...] it does a reverse lookup and tries to connect to [444.333-222-111.reverse.theplanet.com:10000,<...]Chances are your Apache server isn't configured with a Hostname directive, so it's using the reversed name. While the DNS is wrong, the problem is probably with Apache, not DNS.
Sean
Because it's supposed to be setup properly to resolve to the actual hostname. That doesn't mean there are any real security checks to make sure that happens :-). Just like when I connect to an SMTP server, the first command is "HELO sitename.com".. it doesn't verify that I actually am sitename.com, it just accepts that and moves on.
<They could all point back to e.g. google.com and you're saying it wouldn't make any difference.>
For services that simply resolve it so log it as opposed to actually using it, then yes.. it wouldn't make a difference (except that it would show up in the server's logs that google.com was connecting to them).
<The problem is that there are some things that won't work from the IP address unless the PTR is correct.>
That's probably true, which is why I would set it up correctly regardless of whether or not it caused any actual problems. But I don't know of anything that won't function properly if it resolves to something that doesn't exist.
For example, if you use SSL with Webmin and try to connect to [111.222.333.444:10000,...] it does a reverse lookup and tries to connect to [444.333-222-111.reverse.theplanet.com:10000,...] which obviously doesn't point anywhere. The same thing happened to me with FTP, and as you said, probably POP3 as well.>
That's interesting.. because I haven't encountered this with these services. What I have encountered is that establishing an FTP or POP3 connection takes 30 seconds instead of 2 seconds if a name does not resolve, and that a name that resolves incorrectly has acted the same way as a name that resolves correctly.. so long as it resolves.
But there could be two different issues here. One where the IP resolves incorrectly for the client, and one where the IP resolves incorrectly for the server. I'm referring to the former, and in that case, it shouldn't really make much difference.. because the client establishes the connection, not the server.. so what the server resolves the IP to shouldn't make a difference since it won't use any of this information to establish a connection -- It's a server.
Now if the server's IP didn't reverse resolve correctly, then I could see where a particular client may try to use the incorrectly resolved name to make a connection.. but that doesn't seem to make sense, because then the process would be:
1) Resolve hostname to IP.
2) Reverse resolve IP to hostname.
3) Resolve reverse-resolved hostname to IP.
4) Establish a connection to the resolved reverse-resolved IP.
It seems like steps 2 and 3 are a waste.. and I don't know why someone would want write a client program that way. Sure, it adds a little authenticity to the reverse-resolved hostname.. but it's probably not that important that this method is actually practiced.
If that's true.. then you may want to look at other causes for not being able to establish a connection. But in either case, the IP should reverse resolve to an actual hostname that can resolve back to that IP address.
1) Resolve hostname to IP.
2) Reverse resolve IP to hostname.
3) Resolve reverse-resolved hostname to IP.
4) Establish a connection to the resolved reverse-resolved IP.
The problem is that sometimes you can skip #1. For instance, if I decided to FTP using my server's IP address, the process would be:
1) Reverse resolve IP to (incorrect) hostname
2) Attempt to establish connection to the resolved hostname
3) Fail
I think we all agree that the reverse zone can be important to make sure all services work, though...
1) Reverse resolve IP to (incorrect) hostname
2) Attempt to establish connection to the resolved hostname
3) Fail>
That's right.. my original step #1 can be skipped, but step #3 cannot, because you can't establish a connection with a hostname, it must resolved to an IP address.. but the flow of what you're saying is right :-).
