IPv6 Configuration and Audit Requirements: Pitfalls of AAAA Records and Verification Methods

Among IPv6-related issues, the most critical point is not “failing to configure IPv6”, but “configuring it incorrectly”—where a domain has an AAAA record, but the server’s IPv6 connectivity is actually broken. In this scenario, clients that support IPv6 will fail to connect.

This article explains how to determine whether you need to configure IPv6, how to do it correctly, and how to verify it.

Clarifying a Common Misconception

The requirement for mobile app audits regarding IPv6 essentially mandates that the application must function correctly in a pure IPv6 network environment, typically achieved through carrier NAT64/DNS64 translation mechanisms. This does not require your server to be configured with IPv6.

Therefore:

The third row represents the real pitfall. Not configuring IPv6 causes no problems, but configuring it when it is unavailable will definitely cause issues.

Check Current Status

# ① Check if the domain has an AAAA record
dig +short example.com AAAA

# Compare with A record
dig +short example.com A

# ② Check if the server has an IPv6 address
ip -6 addr show
ifconfig | grep inet6

# ③ Test if IPv6 can reach the internet
ping6 -c 3 2001:4860:4860::8888     # or use ping -6

# ④ Verify external accessibility via IPv6
curl -6 -I https://example.com/ -m 10

Key Combination Judgment

Configuring AAAA Records

If you confirm that IPv6 should be enabled, the order is: first ensure server IPv6 is available, then add the AAAA record.

# ① Confirm the server has obtained an IPv6 address
ip -6 addr show scope global

# ② Confirm web services are listening on IPv6
ss -lntp6 | grep ':443'
# Nginx config must include listen [::]:443

# ③ Confirm firewall/security group allows IPv6 traffic
ip6tables -L -n | head

# ④ Verify externally before adding the AAAA record
curl -6 -I https://example.com/ -m 10

# Nginx listening on IPv6
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;    # IPv6
    server_name example.com;
    ...
}

# Security groups must also allow inbound IPv6 traffic (confirm in console)
# On cloud platforms, IPv4 and IPv6 security group rules are usually separate

Verification

# ① Check if resolution returns AAAA
dig +short example.com AAAA

# ② Access using IPv6 (critical verification)
curl -6 -I https://example.com/ -m 10 -v

# ③ Compare results between IPv4 and IPv6
curl -4 -I https://example.com/ -m 10 | head -3
curl -6 -I https://example.com/ -m 10 | head -3

# ④ Online detection (multiple providers offer IPv6 reachability checks)

Comparison in step ③ is the most valuable: The results returned by both protocols should be consistent. If IPv4 works normally but IPv6 times out, there is a configuration issue.

What to Confirm for App Audit Scenarios

If the goal is to meet the IPv6 requirements for app audits:

• Do not add AAAA records just to “look like” you support IPv6 unless availability is confirmed
• Do not hardcode IPv4 addresses in APIs (this is a common reason for audit failure)
• Do not use legacy APIs that only support IPv4

# Check code for hardcoded IP addresses
grep -rnE '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' 
  /var/www/html --include='*.php' | grep -v '127.0.0.1' | head

Hardcoding IPv4 addresses in interfaces is a high-frequency reason for audit failure, more common than simply lacking IPv6 on the server.

Decision Tree

IPv6 Related
├─ Does the domain have an AAAA record?
│  ├─ No → Usually no action needed (IPv4 is fine)
│  └─ Yes → Server IPv6 must be truly available, otherwise remove AAAA
├─ To enable IPv6
│  ├─ ① Server obtains IPv6 address
│  ├─ ② Web service listens on [::]:port
│  ├─ ③ Firewall and security group allow IPv6
│  ├─ ④ External verification via curl -6 passes
│  └─ ⑤ Then add AAAA record
├─ App Audit Scenario
│  ├─ Do not hardcode IPv4 addresses in interfaces ← Most common cause of failure
│  └─ Do not add unavailable AAAA records just for "support"
└─ Verification
   └─ Results from curl -4 and curl -6 should be consistent

Scenario Deduction: After Configuring IPv6, Some Users Suddenly Cannot Access

Symptom: IPv6 support was added to the site along with corresponding DNS records.
Subsequently, some users reported intermittent slowness or inability to access, while internal operations testing showed everything working normally.

1. First, check if both record types return consistent results → Query both IPv4 and IPv6 records simultaneously,
   and discover that the IPv6 record points to an address that cannot provide the same service as IPv4.
2. Understand why only “some people” are affected →
   Networks supporting IPv6 will prioritize the IPv6 channel, while those with poor or no support still use IPv4.
   Different performance in these two network environments is the direct cause of this phenomenon.
3. Confirm if the server is actually listening on IPv6 → Only IPv4 was configured,
   causing the IPv6 record to resolve to an address on the MacBook that actually provides no service.
4. Complete the server-side listening configuration → Make the web service listen on addresses for both protocols.
5. Verify if the DNS record was added in the correct location →
   Some providers require adding records in specific consoles; adding them in the wrong place means they won’t take effect.
6. Verify separately on both network types → Do not just test on your own network;
   you must confirm normal access via both IPv6 and IPv4.

# Check if both records exist and point correctly
dig example.com A +short
dig example.com AAAA +short

# Check if the server is truly listening on IPv6
ss -lntp | grep -E 'tcp.*:::|[::]'

# Verify separately via both protocols
curl -sS -4 -o /dev/null -w 'IPv4: %{http_code}  %{remote_ip}n' https://example.com/
curl -sS -6 -o /dev/null -w 'IPv6: %{http_code}  %{remote_ip}n' https://example.com/

# Connectivity confirmation when unreachable
ping -6 -c 2 example.com 2>/dev/null

Root Cause: Only the DNS record was added, but the server did not provide services on the IPv6 address.
Networks prioritizing IPv6 resolve to this “present but non-service-providing” address, resulting in intermittent failures.

Two key points to remember:

• You must confirm the server is listening on IPv6 before adding the IPv6 record.
  Adding the record first, discovering it doesn’t work, and then troubleshooting leads to a period of actual unavailability.
• Verification must specify each protocol separately.
  Your local network often uses only one type; normal operation in a single environment does not represent the other.

8 Common Pitfalls

1. Add AAAA before verification: Reversing the order causes faults.
2. Believing that not configuring IPv6 prevents passing audits: The focus is on client availability in IPv6 networks.
3. Hardcoding IPv4 addresses in interfaces: A common reason for audit failure.
4. Nginx only listening on IPv4: Address exists, but service is not listening.
5. Security group only allowing IPv4: IPv6 rules are usually independent.
6. Only testing IPv4 and assuming everything is fine: Must use curl -6.
7. Entering incorrect addresses in AAAA records: Worse than having none.
8. Not removing records when IPv6 is unreachable: The problem persists.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar O&M services on Alibaba Cloud / Tencent Cloud / Huawei Cloud marketplaces (service providers include our store and peers, provided solely as reference for genuine feedback, not fictitious tickets from this site):

10***77 2022-09-19 5.0 Affordable price | Skilled technology | Patient and professional Received filing rectification notice, found this service just in time, handled quickly 10***49 2022-04-12 5.0 On-time delivery | Affordable price | Skilled technology Needed rectification, fast configuration, good

b****4 Rating: 5.0 points 2025-06-23 16:57 b****4 Rating: 5.0 points 2025-06-23 16:56 Jian****Wei Rating: 5.0 points 2021-01-20 15:03 Technology is awesome! Speed is very fast! It turned out to be Baidu global hijacking caused by a trojan!!!! 1 f****u Rating: 5.0 points 2021-01-02 20:43 Thanks for assisting in maintaining normal Yuncai operations. 1****1 Rating: 5.0 points 2020-11-20 10:03 Consistently good service 1****1 Rating: 5.0 points 2020-11-17 09:13 Thanks for the consistently good service. 1****1 Rating: 5.0 points 2020-09-25 15:42 Many thanks. 1****1 Rating: 5.0 points 2020-08-24 15:34 Many thanks to your company’s technical staff 1****1 Rating: 5.0 points 2020-07-24 09:49 Many thanks!