I am starting to experiment with IPv6-only networks and require the use of a DNS64 service to be used in conjunction with NAT64.  Luckily, BIND 9.8.x offers this capability.  However, I don’t want my DNS server to reply with a quad-A record for every query now that I have enabled DNS64, since this DNS server is used by non-v6 clients, as well as dual-stack clients that I do not want to send them searching for 64:ff9b::/96. :S  I therefore added a secondary IPv6 address on the DNS server for my v6-only clients to use specifically for DNS64, and put it in its own view.  In the config below, the BIND DNS64 service will utilize 2001:db8::64 🙂

acl rfc1918 { 10/8; 192.168/16; 172.16/12; };

options {
        listen-on port 53 {
                192.168.1.1;
                127.0.0.1;
        };
        listen-on-v6 port 53 {
                2001:db8::10/64;
                2001:db8::64/64;
                ::1;
        };

view "external" {
match-destinations { 2001:db8::10; ::1; 192.168.1.1; 127.0.0.1; };

[...]

}; //end view external

view "dns64" {
    match-destinations { 2001:db8::64; };
    dns64       64:ff9b::/96 {
        clients { any; };
        mapped { !rfc1918; any; };
        exclude { 64:ff9b::/96; ::ffff:0000:0000/96; };
        suffix ::;
}; //end view dns64

};

the corresponding digs show the difference between

dig @2001:db8::64 +short -t AAAA www.cnn.com
www.cnn.com.vgtf.net.
cnn-atl.gslb.vgtf.net.
64:ff9b::9da6:e21a
64:ff9b::9da6:e219

dig @2001:2b8::10 +short -t AAAA www.cnn.com
www.cnn.com.vgtf.net.

Looks like I am ready to start working on learning how to use TAYGA