reverse lookup problem while using a private classless network ID

lectricjunky · 05-04-2008, 03:16 AM

Well, the view clause is working great with my caching DNS server, I'm basically treating /etc/named.rfc* (included in view clause) as a "zones" (keeper of zone configs) file rather than placing the zones directly into the named.conf file. I have a master server working with forward lookups now but upon trying to do a reverse lookup as instructed by this page:

http://tldp.org/HOWTO/DNS-HOWTO-5.html

I find that there is (or was (I hope)) a problem with classless IP addresses

. I'm not finding any answers yet... My subnet is 10.0.0.0/28 and I've done a good deal of work to create dhcp reservations via my router in order to keep certain hosts static while allowing guests to jump on with little little to no network cofiguration.

I would like to keep the 10.x.x.x network scheme as 192.160.x.x conflicts with my personal & work vpn (cheap linksys vpn).

I tried switching from /28 to /24 with no luck.

Does anyone know if there is a work around to this classless problem in BIND? Or am I going to have to create a seperate zone for each host IP?

any help is much appreciated.

dkm999 · 05-04-2008, 06:55 PM

I am guessing a bit as to what exactly you are trying to achieve, but it seems to me that you just need to make your local nameserver authoritative for the reverse zone. This is actually a safe thing to do, since your 10.0.0.x network is one of the Private Networking ranges, and any public Internet router worth its salt will unceremoniously drop any packet destined for one of your addresses. Therefore, even if there were some way to get the public DNS to supply the address-to-name mapping for your private zone, no one could send packets to those addresses anyway.

To do this, you just need to include something like this in your named.conf file

Code:

zone 0.0.10.in-addr.arpa {
  type master;
  file "your_inverse.zone";
};

Deciphered, this tells your cacheing server that it should not ask anybody else for inverse mappings of addresses in the range 10.0.0.x. This is larger than the actual range of host numbers, since you are using a /28 hunk of this range, rather than a /24 hunk. But since there is no sense it any of your local machines trying to resolve any 10.0.0.x that is elsewhere on the Internet, this will produce the right behavior: names for addresses that you have defined, and "no such domain" for all the rest.

Then, you just put the PTR records into your_inverse.zone, and the address-to-name resolution should work the right way.

lectricjunky · 05-04-2008, 09:24 PM

Thanks dkm999. I tried what you said which was similar to what the tldp.org how to said to do it, but still no avail. Forward zone works fine . I found this page which may have the answer, but I'm still trying to decipher it:

http://www.wains.be/index.php/2008/0...ate-directive/

lectricjunky · 05-04-2008, 11:27 PM

I'm without words...
I finally made the connection. the left most column in the reverse zone file IS the last octet in the IP address. zone has to be called 0.0.10.in-addr.arpa and the zone file could be called anything. The inside of the file has to look something like this though:

$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; Serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR hosta.linux.bogus.
89 PTR hostb.linux.bogus.
93 PTR hostz.linux.bogus.

etc etc. apparenly it doesn't matter what order it is, but in decending would be nicer

though showing it not as 1,2,3 would have made more of a distinction in my mind...The point is I didn't realize that the left column had to coorespond to the hostname and the last octet of its respective ip in the forward lookup zone file. I could have been done with this last night and working on squid or sendmail if the documentation would have spelled it out a little clearer...I guess that is just supposed to be common knowledge...I feel like a dummy now that I know it...oh well, thanks again.

dkm999 · 05-05-2008, 12:20 PM

Glad you found the answer. And you are right: for the reverse mapping to work, you need two things: a zone with a name that is a portion of the special in-addr.arpa domain, preceded by the first portion (the part matching most of the network number) of the IP address in reverse-octet order, and then a zone file containing PTR records. The fields of each of those records are:

reverse_name IN PTR forward_name

In the fully-expanded version, such a record would look like this:

Code:

12.0.0.10.in-addr.arpa  IN  PTR  your_machine.bogus.

Because of some general rules about what DNS assumes about partial names and which parts of the record are optional, you can shorten this in these ways:
1. If your zone is 0.0.10.in-addr.arpa, you do not need to supply this for each PTR record; it is appended automatically unless you terminate the reverse name with a period (.)
2.Once upon a time, DNS was thought to be useful for more than just IP name resolution, and so there is an address class field defined for each record, just after the reverse_name. If you do not supply it, the class is assumed to be IN (for Internet).

This brings us to the result you came up with, where you only need to supply the last part of the IP address in the zone file, and can follow it (after some whitespace) with the record-type word PTR.