When you start deploying IPv6 services for outside users, you will need to add AAAA record for those hosts in your DNS and set up proper delegation for ip6.arpa to handle PTR records. Before you do this, it is a good idea to make sure that you have reasonable IPv6 connectivity so that IPv6 users won't be diverted to high-latency indirect paths when they start using the AAAA records. Also, to help users on your network, set up the IPv6 services described in First Steps for ISPs. It wouldn't hurt to do an audit of customers who are using other tunnel broker servers and contact them, pointing out that you have a local tunnel broker service. If you don't do this, it is likely that the new AAAA records for your service will cause some of your users to experience much higher latency because they get their IPv6 packets from a distant tunnel broker. It will appear that your network is suffering from strange latency problems since the server with the AAAA record is on your network.
One way to avoid such issues and allow testing without disrupting production services is to set up special domain names. Initially, you can add a name which only returns an AAAA record. This assures that connectivity is IPv6 and does not require change to the existing host name. (Note: You may have to configure your service to recognize the new name, e.g. add a ServerAlias directive to an Apache virtual host.) To switch to production IPv6 use, add an AAAA record to the primary host name. Adding another name that only returns an A record will provide a way to test with IPv4 only.
Substitute www with whatever hostname you are using. The above form is what is in general use around the internet and what some people will try in cases where a DNS name has both an AAAA and A records and one of them does not work.
Reverse DNS works via PTR records in your zones. For IPv4, the bits are reversed, such that a PTR record for 192.168.0.0 would look like 0.0.168.192 IN PTR your.hostname.. The same is true for IPv6, except that you must seperate each character with a .. This means that a PTR record for 2008:64:128::ee:1 would look like 220.127.116.11.e.e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.18.104.22.168.0.0.8.0.0.2 IN PTR your.hostname. or a PTR record for the loopback address of ::1 would look like 22.214.171.124.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR localhost.. Note that zeroes must be expanded, there is no way to replicate a :: in ip6.arpa DNS records.
There are questions about scalability of reverse DNS in IPv6. In IPv4, large ISPs simply prepopulate reverse zones with records for every possible address. In IPv6, that would be impossible. A variety of options are available, including generating queries on the fly, dynamic DNS, and simply not responding.
Note that this section only discusses the ip6.arpa method of reverse DNS. Formerly, the ip6.int method existed as well, however the IETF has been pushing towards standardization around the ip6.arpa method, which is what is in widest use in modern systems today.
Phase It In
It is best to phase in the use of IPv6 records in your DNS so that you can deal with the various issues that arise step by step. The first phase is to pick one server which is not mission critical and add AAAA records (and ip6.arpa PTRS) for it. Wait a while and sort out issues that arise. Monitor IPv6 traffic to that host to be sure that it is actually getting some. Without IPv6 traffic there won't be any problems and you need to find the problems in order to solve them.
Second phase is to take a mission critical service and add IPv6 access using special hostnames. If this is a clustered service you will need to make sure that your load-balancer can handle IPv6 or else divert the IPv6 traffic before it gets to the load balancer. You probably only want to try this on a single box since the only people who access it will be people who follow up your announcement. You need to announce the IPv6 url in a forum that users of this service will read. Again, monitor the IPv6 traffic because you haven't sorted out all the issues until you see a significant traffic load.
By this time you will be gaining enough experience with IPv6 to design your own way forward. There are too many variables for a one-size fits all recommendation.
How Do Others See You?
Make sure to check Global IPv6 Deployment Progress Report to see if there are any discrepancies in IPv6 access to your nameserver versus IPv4 access. Since most network usage begins with a DNS query, if there are performance issues in reaching your nameserver, your hosting customers will not be happy.
Make sure your registrar has IPv6 Glue support
Recursive DNS servers that support IPv6
- Recursive access to the public
- DNS OARC
- bind.odvr.dns-oarc.net: 2001:4f8:3:2bc:1::64:20
- Hurricane Electric
- ordns.he.net: 2001:470:20::2 (globally anycasted in 11 countries)
- f.6to4-servers.net: 2001:4F8:0:2::14
- x.ns.ntt.net: 2001:418:3ff::53
- y.ns.ntt.net: 2001:418:3ff::1:53
- Verizon Business
- cache00.ns.uu.net: 2600:803:5:1::10
- Recursive access configured or meant for their own users
- Recursive access unknown
Chris Hills of Chaz6 maintains a list of recursive DNS servers, including IPv6 ones, in this text file.
While there are a plethora of DNSBLs for IPv4 addresses, they are only a few for IPv6.
One of the specific challenges of a DNSBL for IPv6 is the large address space and whether /128's or /64's should be the smallest entry.
Somewhat the opposite of the above, IPv6-capable email servers are registered.