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
