Supporting IPv6 in the existing DNS infrastructure is actually quite easy and can be done without destroying backwards compatibility of existing IPv4 clients to request DNS information about other IPv4 hosts. IPv4 clients will of course be unable to retrieve the IPv6 information. Additionally, the necessary modifications to existing DNS servers are relatively minor.
In essence, the only new functionality that needs to be added to a name server is the ability for it to store the associated IPv6 addressed of a name entry, and also the ability to do the reverse query. Since older IPv4 clients will not be able to arbitrarily be able to distinguish the unknown IPv6 addresses, a new resource record (RR) will need to be created to separate them.
To allow IPv6 hosts to be entered into the DNS tables and communicated between servers, a new "AAAA" resource record (RR) must be introduced to replace the "A" record where IPv6 information is available. The "AAAA" records function in a manner similar to tradition "A" records in that they provide hostname to IP-address mappings, except that they contain full IPv6-compliant addresses. Because a new RR is needed for the implementation to be done, it is possible to have an IPv4 and an IPv6 address associated with a name record without problems.
In this manner, existing IPv4 clients can continue to request address information for a host by asking for any associated "A" records on a host and an IPv4-compliant address will be returned if it exists.
If a person write an IPv6 application that needs to resolve a name address to an IP address, the name service functions that it invokes will query the name server for the availability of an "AAAA" record for that host. If such a record was found by the name server, then the application can use that IPv6 address immediately. If no "AAAA" record was found, but a "CNAME" record was found for that name, then the application can make a second request to determine if an "AAAA" or a "CNAME" record for the target of the original "CNAME" was available. When neither of these two record are found, the application can look for the presence of a standard IPv4 "A" record and convert to an IPv6 form by prepending the appropriate number of leading zeros.
It is also desirable to be able to perform reverse lookups by IP address to determine the associated hostname of a machine. In IPv4 this is accomplished by each authoritive DNS server setting up an "in-addr.arpa" domain that contains a mapping of all host ip addresses back to their hostnames, with the components of the IP address listed in reverse order to make the grouping of the subdomains correspond with the subnetting of the IP addresses. (ie: the IP address 127.0.0.1 might be listed in a domain file under the subdomain "0.0.127-in-addr.arpa" under a host address of "1 IN PTR localhost.domain.com"
To allow IPv6 hosts to be reverse looked up by IP address, a new "IP6.INT" domain needs to be introduced. An IPv6 address is represented as a name in the IP6.INT domain by a sequence of nibbles separated by dots with the suffix ".IP6.INT". The sequence of nibbles is encoded in reverse order, i.e. the low-order nibble is encoded first, followed by the next low-order nibble and so on. Each nibble is represented by a hexadecimal digit. For example, the inverse lookup domain name corresponding to the address 4321:0:1:2:3:4:567:89ab would be b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT
All existing query types that perform type A additional section processing, i.e. name server (NS), mail exchange (MX) and mailbox (MB) query types, must be redefined to perform both type A and type AAAA additional section processing. These new definitions mean that a name server must add any relevant IPv4 addresses and any relevant IPv6 addresses available locally to the additional section of a response when processing any one of the above queries.
The net implementation of IPv6 in DNS is thus something that is very clean. The DNS server source had to be modified to support only one new RR type. IPv6 compliant applications simply need to be linked with a DNS socket library that knows to try for AAAA records first and then A records. Both of these issues are minor since servers/applications would have to be upgraded to support IPv6 anyways.
The main RFC's that document the issues of IPv6 and the DNS integration issues are RFC 1884 - IP Version 6 Addressing Architecture and RFC 1886 - DNS Extensions to support IP version 6.