How do I get reverse DNS for my IP addresses delegated to my own DNS server? [KB1187]

Reverse DNS is controlled by whoever "owns" the IP address.
The owner can choose to sub-delegate reverse DNS for a range of IP range to someone else, who in turn can sub-delegate parts of that range further, etc.

IANA ultimately "owns" all Internet IP addresses.
IANA delegates these IP addresses to 5 regional registires; AfriNIC (Africa), APNIC (Asia/Pacific), ARIN (North America), LACNIC (Latin America), and RIPE (Europe, Middle East, Central Asia).
And these registries delegate their IP addresses to backbones providers and ISPs, who delegate to end-users.

So as an end-user, if you want control of reverse DNS for your IP addresses, you need to contact whoever provides you with these IP addresses, and ask them to do a reverse DNS sub-delegation to your DNS servers.

For example if your IP range is 1.2.3.0 to 1.2.3.255, then the reverse DNS sub-delegation is typically done using a DNS zone name "3.2.1.in-addr.arpa".
If you have less than a class C (256 IP addresses), then the reverse DNS sub-delegation uses a slightly different format called "Classless IN-ADDR.ARPA delegation". The exact zone name format used for this vary for each ISP, so it is very important that you setup your reverse zone on your DNS server with the zone name provided by the ISP.
For more on this, please see RFC2317

If you only have one or a few IP addresses, most ISPs will not do reverse DNS sub-delegation for this at all.
However in most cases, they will point reverse DNS for your IP addresses to whatever domain name that you want, at least if you are a business customer.

REFERENCES:
For more information, please see the following knowledge base articles:

Comments:

	12 Oct 2008 22:33 GMT - by Loye Young: For "Classless IN-ADDR.ARPA delgation, RFC2317 doesn't work for all DNS software because suggests using characters that are not parsed the same way for all operating systems. There is a better way. The following instructions will use an example delegated range of 192.0.1.120/29, which covers IP addresses 192.0.1.120 through 192.0.1.127. The delegated IN-ADDR.ARPA domain is associated with the domain example.com. Instructions to the ISP who is delegating the zone-- 1. Create, for the network address of the delegated zone, two NS records that point to the delegate nameserver. 120.1.0.192.in-addr.arpa. IN NS ns1.example.com. 120.1.0.192.in-addr.arpa. IN NS ns2.example.com. 2. Create CNAME records for each address in the zone other than the network address. 121.1.0.192.in-addr.arpa. IN CNAME 121.120.1.0.192.in-addr.arpa. 122.1.0.192.in-addr.arpa. IN CNAME 122.120.1.0.192.in-addr.arpa. 123.1.0.192.in-addr.arpa. IN CNAME 123.120.1.0.192.in-addr.arpa. 124.1.0.192.in-addr.arpa. IN CNAME 124.120.1.0.192.in-addr.arpa. 125.1.0.192.in-addr.arpa. IN CNAME 125.120.1.0.192.in-addr.arpa. 126.1.0.192.in-addr.arpa. IN CNAME 126.120.1.0.192.in-addr.arpa. 127.1.0.192.in-addr.arpa. IN CNAME 127.120.1.0.192.in-addr.arpa. Instructions to the delegate-- 1. On both Create SOA record for the delegated zone. 120.1.0.192.in-addr.arpa. 7200 SOA ns1.example.net. soacontact.example.net 1234567 14400 7200 950400 7200 2. Create A records for each address in the zone. 120.120.1.0.192.in-addr.arpa. IN A 192.0.1.120 121.120.1.0.192.in-addr.arpa. IN A 192.0.1.121 122.120.1.0.192.in-addr.arpa. IN A 192.0.1.122 123.120.1.0.192.in-addr.arpa. IN A 192.0.1.123 124.120.1.0.192.in-addr.arpa. IN A 192.0.1.124 125.120.1.0.192.in-addr.arpa. IN A 192.0.1.125 126.120.1.0.192.in-addr.arpa. IN A 192.0.1.126 127.120.1.0.192.in-addr.arpa. IN A 192.0.1.127 3. Create PTR records for each address in the zone. 121.120.1.0.192.in-addr.arpa. IN PTR alpha.example.com. 122.120.1.0.192.in-addr.arpa. IN PTR beta.example.com. 123.120.1.0.192.in-addr.arpa. IN PTR gamma.example.com. 124.120.1.0.192.in-addr.arpa. IN PTR delta.example.com. 125.120.1.0.192.in-addr.arpa. IN PTR omicron.example.com. 126.120.1.0.192.in-addr.arpa. IN PTR epsilon.example.com. 127.120.1.0.192.in-addr.arpa. IN PTR omega.example.com. 4. Set up RP (responsible party) for the zone. 120.201.145.207.in-addr.arpa. RP dnsadmin@mail.example.com. 5. Set up MX records for the zone. 120.201.145.207.in-addr.arpa. MX mail.example.com. (Of course, you will need to configure your mail server to accept mail for the 120.201.145.207.in-addr.arpa zone.)
	13 Oct 2008 12:20 GMT - by Jesper - JH Software: Thanks for your feedback Loye. I am not familiar with any operating systems that parse RFC2317 style format differently - do you have any examples? What you describe works fine of course - just like many other naming schemes would too. But generally I would recommend that users stick with the RFC2317 format (x/x.x.x.x.in-addr.arpa) unless this specifically causes problems. It is just easier when everybody uses the same format.
	13 Oct 2008 21:55 GMT - by Loye Young: >It is just easier when everybody uses the same format. Of course, this is the problem. Not everyone does. Instead, RFC2317 causes confusion and generates errors. In general, anything other than dots and numbers will generate errors in a variety of situations. >operating systems that parse RFC2317 style format differently The '/' character is a directory separator in HTTP and *nix systems. While in theory good coding practice can work around it, in practice good coding practice is not fully implemented. The use of hyphens and slashes complicates zones for a benefit that approximates zero. For an example, go on the web and look for an online reverse DNS query tool. Type in a network address using a hyphen in the IP address and most sites will respond with an error that the IP address is not valid. The procedure I have described is easier because it "just works". As I said before, my experience is that anything other than dot and numbers causes problems.
	13 Oct 2008 22:03 GMT - by Loye Young: ERRATA . 1. In the above example, "example.net" should be changed to "example.com" throughout. (See delegate instructions, step 1.) . 2. The name "120.201.145.207.in-addr.arpa." should be changed to "120.1.0.192.in-addr.arpa." (See delegate instructions, steps 4 and 5.) . 3. Delegate instructions, step 1, should read: "On each delegate nameserver specified above, create an SOA record for the delegated zone."
	18 Aug 2009 16:43 GMT - by Jon: You ought to go ahead and edit the document with your changes and add it as a followup post.
	23 Jun 2010 11:44 GMT - by Dharmesh Shah: What if the customer (end User) had a /17 from APNIC ? In that event, 1) WIll he need to create a REverse zone 17/x.x.x.x.in-addr.arpa. ? 2) Will he need to populate 256x128=32768 PTR records ? 3) Will he need to create 256x128=32768 CNAME records ?
	23 Jun 2010 16:43 GMT - by Loye Young: >What if the customer (end User) had a /17 from APNIC ? Essentially, you are talking about half a Class B zone. The "best way" would be to create NS records to delegate the various Class C zones. See http://www.simpledns.com/kb.aspx?kbid=1240. Theoretically, it would be possible to create a flat /17 zone with no subzones, but practically, that's not the way you would manage the network hardware. You may need to create PTR and CNAME records for the portions of the network not delegated, but even then, I suspect that you would end up breaking up the network into smaller chunks. Happy Trails,