Print

[packetmail]

A basic question and I'll take my lashings in stride:

What is the solution for publishing RDNS for a IPv6 /64 which accommodates RFC 3041?  In the IPv4 world PTR for an IPv4 address was considered the norm, even for dynamically allocated clients, as well as RFC 1918.  PTR at times wasn't fancy, just an in-addr style formation.  Now that a /64 is ~18 quintillion addresses I'm pretty confident Bind will be quite angry at me for explicitly publishing PTR for all of my /64.

What is current convention; is no PTR for IPv6 RFC 3041 derived addresses considered the norm?  Any solutions to "wildcard" PTR for a /64?

Cheers

[cholzhauer]

I'm interested in hearing the answer to this one...at my place of employment, I've just disabled privacy extensions to get around this "problem"

All of my Windows clients automatically update their DNS records, but they never update the privacy extensions...I guess I just assumed this was by design.

[sput]

Hi there


Establish a rule to link IP addresses to host names.
Have an app do the translations on the fly.
This way you don't need a zone file. Just a 'calculator' that listens to port 53. You can use this for generating both AAAA and PTR 'records' on the fly.


Regards,
Rob

[jimb]

I know bind has directives such a $GENERATE, but I think they actually generate in-memory configuration, not answer dynamically.  Although I'm not sure of this.  Anyway, I'd hope BIND would have something like a catch-all for IPv6 PTR records.

[rm]

Check out http://member.wide.ad.jp/~fujiwara/v6rev.html

[jimb]

Check out http://member.wide.ad.jp/~fujiwara/v6rev.html

Something like that perl script would be so easy to throw into BIND.  Wonder why they haven't done it (if they actually haven't)?

[sput]

Hi there


Reserve an IP address for your Perl script.
Make sure bind doesn't listen on this address. Have the script listen only to this address.
Create a subdomain and subnet for on the fly generated addresses and hostnames in bind. With NS records pointing to a hostname pointing to the script's IP address.


Regards,
Rob

[jimb]

Yeh easy enough to delegate the PTR domain somewhere, but kind of annoying that it'd require a separate IPv4 and/or IPv6 just for the script.  Be nice if it were built into BIND.  I know there are other DNS servers out there that can have modules installed (powerDNS?), but they're behind on other things (DNSSec I believe).

[packetmail]

Thanks everyone for the replies.  I think we can all agree a Perl-powered Rube Goldberg machine to accommodate PTR for an IPv6 /64 is a little ridiculous.  Now, don't assume that I'm being snobbish towards the replies here, I do appreciate them, but I find it somewhat amazing that I'm not able to dig up RFCs that document how to handle this.  I thought PTR was important for IPv6 (as it is in IPv4).  I'm surprised Bind9 doesn't handle this natively.

Now some may say that with RFC 3041 PTR would defy it's usefulness but I'm sure we could do something like "1.6.5.5.0.1.2.7.a.b.d.0.a.3.8.d.8.b.d.0.8.b.d.0.8.b.d.0.1.0.0.2.ipv6.mydomain.net"

So this means two things.  Either we're missing some critical functionality with Bind9, I don't know how to do it correctly, or PTR really isn't that important at all.

At least it seems I'm not the only one in this boat   Again, Rob and Jim, thanks for your replies but I hope you see the point I'm trying to make.  A Perl-script exposed externally to handle PTR on the entire /64 is a little "hackish".

[jrocha]

Have you taken a look at PowerDNS? You can script its behavior with Lua.