July 2008 Archives

IPv6 RDNS setup

| | Comments (0)

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  you look for a ptr record named 

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

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


unplanned reboot of coloma

| | Comments (0)
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. 

IPv6 by accident.

| | Comments (7)
Yesterday I got a funny e-mail from a customer. He was asking for RDNS for his IPv6 address. The funny part is that I thought that I had not yet setup IPv6.

I currently claim to support only IPv4. I did ask for an IPv6 allocation, and about a week ago my provider got back to me with a netblock from he.net, but I've been busy, and I have yet to get around to actually playing with the stuff. Besides, we still have north of 900 days before we run out of IPv4 at the current burn rate.[1]

Now, I've read about this 'IPv6 stateless auto-configuration'[2] The idea is that IPv6 routers announce prefixes via ICMP6 once every 10 seconds, and then the client does some math to create the rest of the IP address using the mac address.

I ask my customer what the IPv6 address he has is, and if it actually works. Yup, the address is in my block, and yes, it works. He just needs an RDNS mapping.

Hopefully, my provider will get me the rdns delegation Tuesday or Wednesday.

Easy Peasy.


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;