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