so IPv6 rdns is a little different from IPv4 rdns. With IPv4 rdns, you split each IP address on byte boundries, reverse the octets, and append in-addr.arpa. all data is represented in decimal, and you don't pad zeros. for example, to get the ipv4 rdns of 188.8.131.52 you look for a ptr record named 184.108.40.206.in-addr.arpa.
IPv6 rdns is similar on the surface; instead of .in-addr.arpa. you append ip6.arpa, but you split the address in unexpected ways, too:
IPv6 addresses are written out in hex, two byte chunks seperated by colon charaters. IPv6 rdns writes out the full address in hex including padding out all zeros, and then splits it into 4 bit chunks (single hex characters) and reverses those.
so to get the rdns of, say, ns2.prgmr.com, IPv6 address: 2001:470:1:41:a800:ff:fe50:3143
you would look for a PTR record that looked like this:; 220.127.116.11.0.5.e.f.f.f.0.0.0.0.8.a.18.104.22.168.22.214.171.124.0.7.4.0.126.96.36.199.ip6.arpa.
note that you must pad out the zeros so that each two-byte chunk seperated by the ':' character is represented by four characters.
Of course, dig -x does this for us....
dig -x 2001:470:1:41:a800:ff:fe50:3143
; <<>> DiG 9.3.4-P1 <<>> -x 2001:470:1:41:a800:ff:fe50:3143
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20189
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
Coloma is my old i386-PAE box. dual xeons in a supermicro chassis. kinda, well, old.
There were three problems. First, I let the userland xen tools get out of sync with the kernel. (uncontrolled yum update is not a good thing) Second, on this old box I never tested the 'save domains on reboot' functionality (on the new servers, if I reboot the dom0, it does an 'xm save' on every running DomU, and an 'xm restore' upon reboot, meaning that rather than seeing a reboot, the DomU owner might notice that the DomU was unavailable for 5-10 minutes, but everything that was running on it before was still running- it would be like unplugging the ethernet cable for a while and plugging it back in) The third (and perhaps largest) problem was that I rebooted the server to deal with the first problem without scheduling it (would have *maybe* been acceptable (but not good) on the new servers, but on the old ones, this was a mistake.)
I'll schedule things better in the future.
Tahoe has problems, the worst of which are 32-on-64 problems, but it's also not mirrored, so I'm trying to move everything off of it. Tonight I moved the main webserver and the movable type server (which is called wiki.xen.prgmr.com, for historical reasons. our mediawiki server is book.xen.prgmr.com) I re-ip'd both, and both are running on both old and new servers until DNS finishes updating. I moved http to a brand new 64-bit image on boar at he.net- it should be much more reliable. I moved wiki to Coloma, a native i386-PAE box hosted at rippleweb in Sacramento.
Customers on tahoe are encouraged to move to new servers;