I'm not sure there's consensus about whether forward and reverse ought
to match (how strong a "should" is that?).
that's pretty much of a "should" for IRC, and various anti-spam crap on SMTP, furthermore, the entries should be (to a certain extend) unique
(hosted-by.provider.com resolving to everything you have and/or the other way around (reverse) fucks things up
I know you can't populate
every potential record in a reverse zone, as in IPv4.
indeed.. ipv6 seems to call for some changes in the way dns servers handle things... no more files people.. preferably no more "zones" either.
(never liked the concept of zones anyway
if no database entry (cached in ram!) -> automatically generate one based on ip (like a84-22-96-1.cb3rob.net. on ipv4 if there is no more specific database entry for that ip present, such as www.customer.com))
(or just forget about reverse dns alltogether)
but then again, quite sure you already figured out bind and zone-based (files) dns have had their days anyway.
just write a few lines of c or perl that talk to a database and cache results in ram, if they can't find anything in ram with a recent enough timestamp and there is nothing in the database or the database isn't responding, just generate one based on the ip requested with your domain added (or in-addr.arpa. added, works too, if you don't want -your- domain in reverse dns (and therefore forward!) entries for customers, or its equivalent for ipv6
yes, you -can- actually make A records in in-addr.arpa and its ipv6 equivalent, so there is no need to use -your- domain for it, and you can still make unique -working- -valid- and resolving both ways entries for each ip, also on ipv6, and generate them on the fly (although that requires a move away from bind, don't think you want to load a zonefile with a few billion entries, although generating it would not be such an issue (loading and searching it would).
a84-22-97-10:~# nslookup 22.214.171.124
126.96.36.199.in-addr.arpa name = 188.8.131.52.in-addr.arpa.
a84-22-97-10:~# nslookup 184.108.40.206.in-addr.arpa