Hands-On Lab: Configuring DNS64 Alongside NAT64

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 record

R1(config)# dns64 server

R1(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 recognize

IPv6Client(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 found

IPv6Client> curl http://ipv4server.lab

-- Successfully connects, entirely by
-- hostname -- no manual address
-- construction, no literal IP typed
-- anywhere by the user

R1# 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 address

Key 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.