DISQUS

Anonymous · 5 years ago

The directions talk about the zone file, the origin, the host and the domain, but they don't mention what the '10' is for in the left most side of the line. ?? Does it have something to do with the address or the zone file or the origin? Is the relation described on another page somewhere? Since this is still new for me, I'm afraid I don't know enough to conclude what it is or does.

qmchenry · 5 years ago

Actually, you led me to find a typo in this recipe that I've now fixed. The goal was to show the resource record (the line in the zone file) for a host with an ip address 192.168.5.10 (it was .100, and that was confusing). So the 10 at the beginning of that line refers to the .10 at the end of 192.168.5.10. The zone file corresponds to the 192.168.5 subnet, so this is the subnet assumed if we only use 10. It would be the same (but contrary to laziness) to start that line with 10.5.168.192.in-addr.arpa. (the trailing period is critical). It's important to realize that a reverse-lookup zone file is not different than a forward-lookup zone file, it just contains PTR records instead of A records.

DNS in general and BIND specifically are very confusing when first starting out. If you are going to be responsible for DNS, I highly recommend the book DNS and BIND, 4th Edition, also known as the Cricket book. This book provides a wonderful introduction for a beginner and a powerful reference for an old-timer.

Anonymous · 5 years ago

Apparently certain email servers use reverse DNS to check that email actually is coming from where it "appears" to come from. How does BIND handle the virtual hosts case where multiple domain names share a common IP address? ie., can it map from one IP address to the correct domain name or can you only ever map 1 IP address to a single domain name?

qmchenry · 5 years ago

My understanding of Sendmail's concern for looking up reverse records is just to make sure the sender's IP address does translate into a hostname by DNS. Beyond that, it can't care what the answer is. You are exactly right in thinking this because many mail servers are responsible for multple domains.

While you can have multiple PTR records for an IP address, the behavior for this is not what you would probably desire. The hostnames resolved for the IP address will be served in a round-robin pattern, so subsequent hits on that IP address will probably yield different answers.

This may be a desirable condition when doing forward lookups in the case when you have multiple servers at different IP addresses that will answer to the same host and domain name (like multiple web servers). The round robin responses will provide a crude sort of load balancing.

If you are getting some specific errors, post them in a reply and we'll take a look at them.

guest · 5 years ago

On a similar note, I have been trying to get a virtual domain to resolve both as www.foo.com and foo.com when served by apache. The virtual www.foo.com works fine but I have been unable to make correct settings in the zone file or in apache virtuals so that foo.com will point to the same site.

Is this possible with a virtual domain and are reverse lookups the way to approach this?

qmchenry · 5 years ago

The DNS side of this situation is straightforward. You need to have an A record for both www.foo.com and foo.com that point to the same address. The PTR records are not necessary from the Apache perspective, but are a good idea.

The Apache side can be more complicated in that there are several ways to accomplish what you are doing. Are you hosting other domains on this server or just one? If just one, you shouldn't have to worry about virtual hosts. Givce us some more detail about what you are trying to do and we'll try to help.

Aaron Cure · 5 years ago

the easiest way to do this in the virtual hosts is:

<VirtualHost 11.22.33.44>

ServerName www.testdomain.com
ServerAlias testdomain.com *.testdomain.com

these directives allow the virtual host to respond for www.testdomain.com, as well as testdomain.com and foo.testdomain.com, etc.