[ Current Issue Home | Issue #5/6 Home | FAQ ]��

The FreeBSD 'zine
Featured Articles: Reverse DNS
## Classless Reverse DNS
## Mark Turpin <>

Classless reverse, while seemingly hard, is really quite simple once you get the hang of it. It basically consists of understanding what network mask you have, and getting your upstream to cooperate (and not be afraid of what they may not know!).

What does classless reverse mean?

Classless reverse is simply doing reverse for a network smaller than /24, or a Class C network. This means, you can assign out a /26, a /29 or whatever, to a downstream site, or customer, and allow them to control their own reverse. When dealing with many customers that have small /29 subnets, having them do their own DNS becomes critical if you don't have time to continually do DNS updates. Setting it up initially takes some time, but is worth it once you get it going. I'll include an example, a /26 that we use for a customer. I'll throw in a forward file just in case someone doesn't know how to do forward. (Hint: a helpful sheet on subnetting is available at: )

Prerequisites

General understanding of DNS, and the DNS system. General Unix knowledge, and a working knowledge of how to kill, restart, and start services. An understanding of how forward lookup works, and the capability to do forward. Also, clue helps!

Assuming you have a working/running version of bind8 going on your system, the following shouldn't be hard to grasp after awhile. If you don't, refer to Issue #2's DNS and BIND article.

Example 1: Customer A has a /26 in 205.216.216.0 and owns foo.com

	Provider's named.conf
	---------------------
	zone "216.216.205.in-addr.arpa" {
		type master;
		file "db.205.216.216.0";
	};

	Customer's named.conf
	---------------------
	zone "0-26.216.216.205.in-addr.arpa" {
        	type master;
	        file "db.205.216.216.0-26";
	};

	zone "foo.com" {
		type master;
		file "db.foo.com";
	};

	Provider's zone file
	--------------------
	(db.205.216.216.0)
	$ORIGIN 216.205.in-addr.arpa.
	216             IN      SOA   	provider.com point-of-contact.provider.com (
				1999041201 ;serial
				3600 900 3600000 3600 )
			IN	NS	ns1.provider.com.
			IN	NS	ns2.provider.com.
			IN	NS	ns3.provider.com.
	$ORIGIN 216.216.205.in-addr.arpa.
	0-26            IN      NS      ns.foo.com 
					;this is the customer's name server
			IN	NS	ns1.provider.com.
			IN	NS	ns2.provider.com.
			IN	NS	ns3.provider.com.
	1               IN      CNAME     1.0-26.216.216.205.in-addr.arpa.
	2               IN      CNAME     2.0-26.216.216.205.in-addr.arpa.
	3               IN      CNAME     3.0-26.216.216.205.in-addr.arpa.
	4               IN      CNAME     4.0-26.216.216.205.in-addr.arpa.
	5               IN      CNAME     5.0-26.216.216.205.in-addr.arpa.
	6               IN      CNAME     6.0-26.216.216.205.in-addr.arpa.
	...
	60              IN      CNAME     60.0-26.216.216.205.in-addr.arpa.
	61              IN      CNAME     61.0-26.216.216.205.in-addr.arpa.
	62              IN      CNAME     62.0-26.216.216.205.in-addr.arpa.
  

What this does is simply state that the 0-26 belongs to foo.com and for information regarding it, check out ns.foo.com, as it is authoritative for it. The standard I use, is start_of_network-network_slash. So in this case where the customer has 205.216.216.0/26, I use 0-26, and the - symbolizes the / to me. I then know whenever I look at this, that the network is a /26, and there are going to be 62 usable IP's here.

	Customer's zone file
	--------------------
	(db.205.216.216.0-26)
	$ORIGIN 216.216.205.in-addr.arpa.
	0-26		IN	SOA	foo.com	point-of-contact.foo.com (
				1999041201 ;serial
				3600 900 3600000 3600 )
			IN	NS	ns.foo.com.
			IN	NS	ns1.provider.com.
			IN	NS	ns2.provider.com.
			IN	NS	ns3.provider.com.
	$ORIGIN 0-26.216.216.205.in-addr.arpa.
	1		IN	PTR	router1.gw.foo.com.
	2		IN	PTR	george.foo.com.
	3		IN	PTR	tom.foo.com.
	...
	62		IN	PTR	mary.foo.com.
  

This is similar to the normal reverse file, and doesn't require much thinking. You *could* do it a bit different, and drop the $origin line, and just put @ on the SOA line, but I do it this way because its simpler for me, and I've been doing it like this for a long time.

	Customer's forward (domain) file
	--------------------------------
	(db.foo.com)
	@		IN	SOA	foo.com	point-of-contact.foo.com (
				1999041201 ;serial
				3600 900 3600000 3600 )
			IN      NS      ns.foo.com.
			IN      NS      ns1.provider.com.
			IN      NS      ns2.provider.com.
			IN      NS      ns3.provider.com.
	localhost	IN	A	127.0.0.1
	router1.gw	IN	A	205.216.216.1
	george		IN	A	205.216.216.2
	tom		IN	A	205.216.216.3
	...
	mary		IN	A	205.216.216.62
  

That's basically all there is to it folks. Relatively easy, and to get it all done just takes time, and cooperation from those that are in involved. If you are the provider, tell your customer's its for their benefit (and yours, since it gets them out of your hair) and that it makes things simpler. If you are the customer, tell your provider that you want to control your reverse for whatever reasons you may have, in addition to the fact that it allows you to customize host information at any time you wish. Questions? Comments? Did I leave something out? Feel free to e-mail me at if so.

  ---------------------------------------------------
  Copyright (c) 1999 by Mark Turpin ([email protected])
  This may be used for fair non-commercial purposes without the consent
  of the author provided this copyright notice accompanies any usage of
  the material herein. The instructions here are provided AS IS; no  
  responsibility whatsoever is taken for any damage caused by following
  them properly or otherwise.
  

Return to Issue #5

Contact: <>
Last modified: $Date: 1999/06/26 05:42:52 $
Copyright � 2023, The FreeBSD 'zine
All rights reserved.