Lab Objective
Configure DNS64 on a router to intercept DNS queries from IPv6-only clients, automatically synthesize an AAAA record embedding an IPv4-only destination's address using the NAT64 prefix, and verify a client can reach that destination by hostname alone without manually constructing any synthesized address.
Lab Purpose
The previous NAT64 lab required manually constructing the synthesized IPv6 address by hand — impractical for real applications that resolve hostnames rather than typing literal addresses. DNS64 automates this entirely: when an IPv6-only client queries a hostname that only has an IPv4 (A) record, DNS64 synthesizes a AAAA record using the NAT64 prefix, making the whole process transparent to the application.
Lab Topology
Same topology as the previous NAT64 lab,
with DNS64 added on R1
IPv4Server has only an A record:
ipv4server.lab -> 203.0.113.50
(no AAAA record exists for this name)Task 1: Verify the Server Has No AAAA Record
Confirm a direct AAAA query for ipv4server.lab returns nothing, since only an A record exists.
Task 2: Configure DNS64 on R1
Configure R1 to synthesize AAAA records using the same NAT64 prefix configured in the previous lab.
Task 3: Point the IPv6-Only Client to R1 for DNS
Configure IPv6Client to use R1 as its DNS64-capable resolver.
Task 4: Verify the Client Receives a Synthesized AAAA Record
Query the hostname from the client and confirm a AAAA record is returned, using the NAT64 prefix and embedding the server's actual IPv4 address.
Task 5: Verify the Client Connects Using the Hostname Alone
Confirm the client successfully reaches the server using ordinary hostname-based connection, with no manual address construction required.
Solution and Verification
DNSServer> dig AAAA ipv4server.lab
;; ANSWER SECTION:
(empty -- no AAAA record exists)
-- Confirmed: this name genuinely has only
-- an IPv4 A record, no native IPv6 recordR1(config)# dns64 serverR1(config)# dns64 prefix 64:ff9b::/96
-- Using the SAME prefix configured for
-- NAT64 in the previous lab is essential --
-- DNS64 synthesizes addresses that NAT64
-- must then actually translate, so a
-- mismatch here would produce synthesized
-- addresses NAT64 does not recognizeIPv6Client(config)# [DNS server set to R1's
IPv6 address, 2001:DB8:K:1::1]IPv6Client> dig AAAA ipv4server.lab
;; ANSWER SECTION:
ipv4server.lab. 300 IN AAAA 64:ff9b::cb00:7132
-- R1 synthesized this AAAA record on the
-- fly -- no AAAA record exists at the
-- authoritative server, this record exists
-- only because DNS64 constructed it upon
-- noticing the query came from an
-- IPv6-capable resolver path and only an
-- A record was foundIPv6Client> curl http://ipv4server.lab
-- Successfully connects, entirely by
-- hostname -- no manual address
-- construction, no literal IP typed
-- anywhere by the userR1# show nat64 translations
Proto IPv6 Source IPv6 Destination IPv4 Source IPv4 Destination
tcp 2001:DB8:K:1::10 64:ff9b::cb00:7132 203.0.113.1 203.0.113.50
-- Confirms the connection is genuinely
-- flowing through NAT64 translation,
-- exactly as in the previous lab, but this
-- time reached via ordinary hostname
-- resolution rather than a manually typed
-- synthesized addressKey Takeaway
DNS64 and NAT64 are designed as a matched pair sharing the identical prefix — DNS64 synthesizes the address, and NAT64 performs the actual translation for traffic sent to that synthesized address, with the shared prefix being the coordination point linking the two — deploying NAT64 alone, as in the previous lab, forces every application to somehow already know the correct synthesized address, while adding DNS64 makes the entire mechanism transparent to ordinary applications resolving hostnames as they normally would.