IPv6 rDNS

Tue Nov 2 17:24:56 UTC 2010

>> 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
>
>