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 84.22.99.1 Server: 84.22.96.10 Address: 84.22.96.10#53 1.99.22.84.in-addr.arpa name = 1.99.22.84.in-addr.arpa. a84-22-97-10:~# nslookup 1.99.22.84.in-addr.arpa Server: 84.22.96.10 Address: 84.22.96.10#53 Name: 1.99.22.84.in-addr.arpa Address: 84.22.99.1 a84-22-97-10:~# On Tue, 2 Nov 2010, David Freedman wrote:
Lee Howard wrote:
Since there's a thread here, I'll mention rDNS for residential users.
I'm not sure there's consensus about whether forward and reverse ought to match (how strong a "should" is that?). I know you can't populate every potential record in a reverse zone, as in IPv4. You can generate records on the fly, or just not provide PTRs.
I've described options in draft-howard-isp-ip6rdns-04 but I'm not sure enough people care whether it's published as an RFC. Discuss on IETF's dnsop list. https://www.ietf.org/mailman/listinfo/dnsop
Presuming that signed wildcarding in ip6.arpa is achieveable under DNSSEC (use of the LABELS field), would be interested in anybody other than IRC operators who feel they still require forward and reverse DNS to match,
I feel this preferable than either not providing PTRs or dynamically creating them on query (which would be cool but another headache DoS vector to manage well)
Thoughts?
--
David Freedman Group Network Engineering Claranet Group