IPv6 DNS: AAAA 레코드, 듀얼 스택 해석 및 모범 사례

DNS는 IPv6 배포가 성공하거나 실패하는 곳입니다. IPv6 연결이 작동하기 전에 AAAA 레코드를 게시하면 사용자는 시간 초과를 기다립니다. 역방향 DNS를 건너뛰면 메일 서버가 트래픽을 거부합니다. 듀얼 스택 해석을 잘못 구성하면 네트워크를 더 빠르게 만드는 대신 느리게 만듭니다.

이 가이드는 DNS가 IPv6와 어떻게 작동하는지, 무엇이 손상되는지, 문제가 되기 전에 수정하는 방법을 다룹니다.

TL;DR - 빠른 요약

핵심 포인트:

AAAA 레코드는 A 레코드의 IPv6 동등물입니다(quad-A = 128비트 주소용 4개의 A)
Happy Eyeballs(RFC 8305)는 IPv6를 먼저 시도하지만 50-250ms 내에 IPv4로 폴백합니다
DNS64는 IPv6 전용 네트워크를 위해 A 레코드에서 AAAA 레코드를 합성하지만 DNSSEC을 중단합니다

바로가기: 기본 사항은 AAAA 레코드, 성능은 듀얼 스택 해석, 문제 해결은 일반적인 실수를 참조하세요.

AAAA 레코드: IPv6의 A 레코드 대응 #

AAAA 레코드("쿼드 A"로 발음)는 호스트 이름을 IPv6 주소에 매핑합니다. 이것은 A 레코드의 IPv6 동등물이지만 32비트 대신 128비트 주소를 보유합니다.

형식 및 구조 #

example.com.    3600    IN    AAAA    2001:db8::1

구조는 A 레코드와 일치합니다: 이름, TTL, 클래스, 유형 및 주소. 주소는 콜론과 16진수를 사용하는 표준 IPv6 표기법을 사용합니다.

각 그룹의 선행 0은 생략할 수 있으며 연속된 0 그룹은 ::로 축소됩니다. 이 두 가지 모두 유효하고 동일합니다:

example.com.    IN    AAAA    2001:0db8:0000:0000:0000:0000:0000:0001
example.com.    IN    AAAA    2001:db8::1

압축 형식을 사용하세요. 읽기 쉽고 입력 오류가 적습니다.

AAAA 레코드 쿼리 #

A 레코드를 쿼리하는 것과 같은 방식으로 AAAA 레코드를 쿼리하되 유형만 지정하면 됩니다.

dig 사용:

dig AAAA example.com
dig AAAA @2001:4860:4860::8888 example.com

nslookup 사용:

nslookup -type=AAAA example.com
nslookup -type=AAAA example.com 2001:4860:4860::8888

host 사용:

host -t AAAA example.com

DNS 조회 도구를 사용하여 A 및 AAAA 레코드를 동시에 쿼리하고 결과를 비교할 수도 있습니다.

AAAA vs A 레코드 #

둘 다 동일한 목적을 제공합니다(이름을 주소로 변환). 그러나 주요 방식에서 다릅니다:

기능	A 레코드	AAAA 레코드
주소 길이	32비트	128비트
주소 형식	점으로 구분된 10진수 (192.0.2.1)	콜론-16진수 (2001:db8::1)
레코드 유형	1	28
쿼리 크기	더 작음	더 큼 (UDP 단편화에 영향)
캐시 동작	독립적인 TTL	독립적인 TTL

A 및 AAAA 레코드는 완전히 독립적입니다. 서로 다른 TTL을 가질 수 있고, 서로 다른 서버를 가리키거나, 다른 것 없이 존재할 수 있습니다. 이 유연성은 유용하지만 잘못된 구성의 기회를 만듭니다.

게시하기 전에 테스트

서비스가 실제로 IPv6를 통해 도달할 수 있는 경우에만 AAAA 레코드를 게시하세요. 손상된 AAAA 레코드를 게시하면 클라이언트가 먼저 IPv6를 시도하고 IPv4로 폴백하기 전에 시간 초과를 기다릴 때 연결 지연이 발생합니다.

듀얼 스택 DNS 해석 #

대부분의 네트워크는 듀얼 스택으로 실행됩니다: IPv4와 IPv6가 동시에 작동합니다. 클라이언트가 호스트 이름을 조회하면 A 및 AAAA 레코드를 모두 받습니다. 그런 다음 운영 체제가 사용할 것을 결정합니다.

Happy Eyeballs (RFC 8305)#

최신 운영 체제는 IPv4와 IPv6를 모두 시도하지만 작동할 때 IPv6를 선호하는 알고리즘인 Happy Eyeballs를 구현합니다. 알고리즘:

A 및 AAAA 레코드 모두에 대해 DNS 쿼리
먼저 IPv6 주소에 연결 시작
50-250ms 대기 (구현에 따라 다름)
IPv6가 아직 연결되지 않은 경우 병렬로 IPv4 연결 시작
먼저 완료되는 연결 사용

이 접근 방식은 성능과 안정성의 균형을 맞춥니다. IPv6가 우선되지만 손상된 IPv6는 연결을 오랫동안 지연시키지 않습니다.

해석 순서 #

클라이언트가 레코드를 쿼리하고 연결을 시도하는 순서는 OS 및 구성에 따라 다릅니다.

대부분의 Unix/Linux 시스템:

A 및 AAAA를 동시에 또는 AAAA를 먼저 쿼리
존재하는 경우 IPv6 주소 선호
/etc/gai.conf (getaddrinfo 구성)에 의해 제어됨

macOS:

두 레코드 유형을 병렬로 쿼리
Happy Eyeballs를 엄격하게 구현
사용 가능한 경우 IPv6를 강력하게 선호

Windows:

두 레코드 유형 쿼리
기본적으로 IPv6 선호 (레지스트리를 통해 구성 가능)
Windows 8부터 Happy Eyeballs 구현

브라우저:

Chrome 및 Firefox는 자체 Happy Eyeballs 구현
OS 동작에만 의존하지 않음
해석 결과를 공격적으로 캐시할 수 있음

IPv6가 승리하는 경우 (또는 패배하는 경우)#

IPv6는 일반적으로 다음과 같은 경우 경주에서 승리합니다:

IPv6 연결이 네이티브 (터널링되지 않음)
IPv6 라우팅이 추가 홉 없이 직접적
대상이 IPv6를 통해 잘 연결됨

IPv6는 다음과 같은 경우 패배합니다:

터널링됨 (6to4, Teredo)으로 인한 지연 추가
라우팅이 IPv4보다 긴 경로를 사용
서버가 IPv6를 통해 제대로 연결되지 않음
방화벽 또는 미들박스 문제로 연결 속도 저하

Facebook의 IPv6 성능

Facebook은 네이티브 IPv6 연결을 사용하는 사용자가 IPv4에 비해 10-15% 더 빠른 페이지 로드를 경험했다고 밝혔습니다. 성능 향상은 네트워크 홉 감소, carrier-grade NAT 없음 및 더 직접적인 라우팅에서 비롯되었습니다.

듀얼 스택 동작 테스트 #

IPv4 또는 IPv6를 강제하여 동작 테스트:

# IPv4 강제
curl -4 https://example.com
 
# IPv6 강제
curl -6 https://example.com
 
# OS가 선택하도록 허용
curl https://example.com

응답 시간 비교. IPv6가 상당히 느린 경우 AAAA 레코드를 널리 게시하기 전에 라우팅 또는 연결 문제를 조사하세요.

DNS64 및 NAT64 #

DNS64는 A 레코드에서 AAAA 레코드를 합성하여 IPv6 전용 네트워크가 IPv4 전용 서비스에 액세스할 수 있도록 합니다. IPv6와 IPv4 간에 패킷을 변환하는 NAT64와 쌍을 이룹니다.

DNS64 작동 방식 #

IPv6 전용 클라이언트가 호스트 이름을 쿼리할 때:

DNS64 서버가 쿼리 수신
AAAA 레코드 확인
AAAA가 존재하면 정상적으로 반환
A 레코드만 존재하면 특수 접두사를 사용하여 AAAA 레코드 합성
클라이언트가 합성된 IPv6 주소에 연결
NAT64 게이트웨이가 연결을 IPv4로 변환

잘 알려진 접두사: 64:ff9b::/96 #

가장 일반적인 DNS64 접두사는 RFC 6052에 정의된 64:ff9b::/96입니다. 주소의 마지막 32비트는 IPv4 주소를 포함합니다.

합성 예:

A 레코드:    192.0.2.1
접두사:      64:ff9b::/96
AAAA 레코드: 64:ff9b::192.0.2.1
             또는 64:ff9b::c000:201 (16진수로)

일부 네트워크는 2001:db8::/96 또는 사용자 정의 범위와 같은 다른 접두사를 사용합니다. 접두사는 DNS64와 NAT64 모두에서 일관되게 구성되어야 합니다.

DNS64/NAT64가 필요한 경우 #

DNS64는 다음에 필수적입니다:

IPv6 전용 모바일 네트워크 (T-Mobile, AT&T에서 일반적)
레거시 IPv4 서비스에 액세스하는 IPv6 전용 데이터 센터
IPv6 전용 클라이언트 동작 테스트

다음의 경우 DNS64가 필요하지 않습니다:

네트워크가 듀얼 스택인 경우
액세스하는 모든 서비스가 네이티브 IPv6를 가진 경우
모든 백엔드 서비스에서 IPv6를 의무화할 수 있는 경우

제한 사항 및 문제점 #

DNS64는 여러 가지를 손상시킵니다:

DNSSEC 검증 실패 - 합성된 AAAA 레코드가 서명된 영역과 일치하지 않습니다. DNS64 서버는 DNSSEC 서명을 제거하여 보안을 줄여야 합니다.

IP 주소를 포함하는 애플리케이션 손상 - 애플리케이션이 JSON, XML 또는 기타 데이터 형식에서 IPv4 주소를 받으면 DNS64가 변환하지 않습니다. 앱은 IPv6 전용 스택에서 IPv4 주소에 연결하려고 시도하고 실패합니다.

로드 밸런서 및 CDN 혼란 - DNS64는 모든 클라이언트가 NAT64 게이트웨이의 주소에서 온 것처럼 보이게 합니다. 지리적 위치, 속도 제한 및 클라이언트 식별이 손상됩니다.

추천 및 리디렉션 실패 - DNS 응답이 추가 섹션에 IPv4 주소를 포함하는 경우 (NS 글루 레코드처럼) 클라이언트가 도달할 수 없습니다.

DNS64 없이 테스트

IPv6에서 네이티브로 작동하도록 서비스를 설계하세요. DNS64/NAT64는 영구 솔루션이 아닌 전환 도구입니다. 지연 시간, 복잡성을 추가하고 엣지 케이스를 손상시킵니다.

역방향 DNS (PTR 레코드)#

역방향 DNS는 IPv6 주소를 호스트 이름으로 다시 매핑합니다. 연결에는 필수가 아니지만 메일 서버에는 필요하며 로깅 및 보안 도구에 유용합니다.

ip6.arpa 영역 #

IPv6 역방향 DNS는 ip6.arpa 도메인을 사용합니다. 주소의 각 니블 (4비트 또는 16진수 한 자리)은 역순으로 작성된 도메인 이름의 레이블이 됩니다.

주소를 PTR 형식으로 변환 #

전체 압축되지 않은 IPv6 주소를 가져와 니블별로 역순으로 작성하고 ip6.arpa를 추가합니다.

예: 2001:db8::1

1단계: 전체 형식으로 확장:

2001:0db8:0000:0000:0000:0000:0000:0001

2단계: 모든 니블 작성:

2 0 0 1 0 d b 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

3단계: 순서 역전:

1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 b d 0 1 0 0 2

4단계: 점으로 구분하고 ip6.arpa 추가:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

이것이 PTR 레코드 이름입니다. 호스트 이름을 가리킵니다.

역방향 DNS 쿼리 #

자동 변환으로 dig 사용:

dig -x 2001:db8::1

PTR 레코드 직접 쿼리:

dig PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

host 사용:

host 2001:db8::1

역방향 DNS 위임 #

역방향 DNS 영역은 ISP 또는 RIR에 의해 위임됩니다. /48이 있는 경우 /48 상당의 역방향 DNS 공간을 제어합니다. 대부분의 제공업체는 웹 인터페이스를 통해 관리하거나 역방향 영역에 대해 자체 DNS 서버를 실행할 수 있도록 합니다.

더 작은 할당 (/64 같은)의 경우 일부 ISP가 개별 PTR 레코드를 처리합니다. 주소와 호스트 이름으로 연락하세요.

메일 서버용 역방향 DNS

메일 서버는 스팸을 줄이기 위해 역방향 DNS를 확인합니다. 메일 서버의 IPv6 주소에 PTR 레코드가 없거나 정방향 조회와 일치하지 않으면 많은 메일 시스템이 메시지를 거부하거나 스팸으로 점수를 매깁니다.

IPv6의 일반적인 DNS 실수 #

작동하는 IPv6 없이 AAAA 게시 #

이것이 1번 실수입니다. 서버에서 IPv6를 활성화하고 AAAA 레코드를 만들고 작동한다고 가정합니다. 그러나 방화벽이 IPv6를 차단하거나 라우팅이 손상되었거나 서버가 실제로 IPv6에서 수신 대기하지 않으면 클라이언트가 시간 초과됩니다.

증상: 특히 IPv6를 선호하는 모바일 네트워크에서 느린 웹 사이트 로드.

수정: AAAA 레코드를 게시하기 전에 여러 외부 IPv6 네트워크에서 연결을 테스트하세요. Ping 도구를 사용하여 도달 가능성을 확인하세요.

역방향 DNS 잊기 #

정방향 DNS는 잘 작동하지만 역방향 DNS를 건너뜁니다. 이로 인해 메일 전달이 중단되고 로그 분석이 혼란스러워지며 비전문적으로 보입니다.

증상: 메일 거부, "역방향 DNS 조회 실패" 오류.

수정: 모든 서버 주소에 대한 PTR 레코드 설정. 여러 위치에서 dig -x로 확인하세요.

A와 AAAA 간 TTL 불일치 #

A 레코드는 3600초 TTL이지만 AAAA는 300입니다. DNS를 업데이트하면 클라이언트가 몇 시간 동안 일관성 없는 결과를 얻습니다.

증상: 일부 클라이언트는 이전 주소로 해석하고 다른 클라이언트는 새 주소로 해석합니다. 문제 해결이 어렵습니다.

수정: A 및 AAAA 레코드의 TTL을 일치시키세요. 동일해야 합니다. 변경하기 전에 둘 다 낮추고 나중에 다시 올리세요.

IPv6를 통한 DNS 차단 방화벽 #

DNS 서버에 IPv6 주소와 AAAA 레코드가 있지만 방화벽이 IPv6를 통한 UDP 및 TCP 포트 53을 차단합니다. 클라이언트가 쿼리할 수 없습니다.

증상: IPv6 전용 클라이언트 또는 네트워크에서 DNS 쿼리 실패.

수정: IPv4 및 IPv6 모두에 대해 UDP 및 TCP 포트 53 허용. IPv6 전용 호스트에서 테스트하세요. DNS over TCP는 선택 사항이 아닌 필수임을 기억하세요.

불완전한 듀얼 스택 구성 #

웹 사이트에 대해 AAAA 레코드를 구성하지만 CDN, 메일 서버 또는 API 엔드포인트에 대해서는 구성하지 않습니다. 사용자가 혼합 결과를 얻습니다.

증상: 메인 사이트는 IPv6를 통해 작동하지만 포함된 콘텐츠, API 호출 또는 메일이 IPv4로 폴백하여 성능 이점을 잃습니다.

수정: 프론트 엔드뿐만 아니라 체인의 모든 서비스에 대해 IPv6 활성화. IPv6 전용 클라이언트에서 전체 워크플로 테스트.

구성의 하드코딩된 IPv4 주소 #

DNS는 잘 해석되지만 애플리케이션 구성 파일에 하드코딩된 IPv4 주소가 포함되어 있습니다. IPv6 전용 클라이언트가 연결을 시도할 때 서비스가 중단됩니다.

증상: IPv6 전용 네트워크에서 연결 오류로 애플리케이션 실패.

수정: 구성 파일에서 IP 주소가 아닌 호스트 이름 사용. DNS가 적절한 주소 패밀리로 해석하도록 하세요.

모범 사례 #

게시하기 전에 철저히 테스트 #

프로덕션 DNS에 AAAA 레코드를 추가하기 전에:

서비스가 IPv6에서 수신 대기하는지 확인: netstat -an | grep :80 (또는 포트)
외부 IPv6 주소에서 테스트: curl -6 https://[2001:db8::1]/
방화벽 규칙이 IPv6 트래픽을 허용하는지 확인
traceroute6로 라우팅이 올바른지 확인
여러 IPv6 네트워크 (모바일, 광대역, 데이터 센터)에서 테스트

OS에 IPv6 주소가 있다고 해서 작동한다고 가정하지 마세요.

A 및 AAAA 레코드의 TTL 일치 #

동일한 TTL 설정. 이렇게 하면 캐시 동작이 일관되고 DNS 업데이트가 단순해집니다.

example.com.    3600    IN    A       192.0.2.1
example.com.    3600    IN    AAAA    2001:db8::1

주소를 변경해야 하는 경우 변경 전 24-48시간 전에 TTL을 낮추고 업데이트를 수행한 다음 다시 올리세요.

역방향 DNS 구성 #

모든 공개적으로 라우팅 가능한 IPv6 주소에 대한 PTR 레코드 설정. 메일 서버에 필요하며 다른 모든 것에 도움이 됩니다.

ISP 또는 RIR과 협력하여 역방향 영역을 위임하세요. PTR 레코드를 정방향 DNS와 동기화하여 일치하도록 유지하세요.

두 프로토콜 모두 모니터링 #

A 및 AAAA 레코드에 대한 DNS 쿼리 볼륨, 응답 시간 및 오류율을 개별적으로 추적하세요. IPv4 및 IPv6 전송을 통한 해석을 모니터링하세요.

다음에 대한 경고 설정:

A 쿼리가 성공할 때 AAAA 쿼리 실패
IPv4와 IPv6 간 응답 시간 차이
IPv6 쿼리 볼륨 급격한 감소

별도 모니터링은 사용자가 불평하기 전에 문제를 포착합니다.

IPv6 지원 DNS 서버 사용 #

DNS 서버는 IPv4 및 IPv6를 통해 쿼리에 응답해야 합니다. 네트워크가 아직 완전히 듀얼 스택이 아니더라도 두 주소 패밀리를 모두 구성하세요.

IPv6 전용 클라이언트에서 테스트하세요. 놀랍게도 많은 DNS 서버에 AAAA 레코드가 있지만 실제로 IPv6를 통한 쿼리를 수락하지 않습니다.

DNSSEC 신중하게 구현 #

DNSSEC는 IPv6와 함께 작동하지만 DNS64는 이를 손상시킵니다. 네트워크에서 DNS64를 사용하는 경우 합성된 레코드에서 DNSSEC를 검증할 수 없습니다.

프로덕션 배포의 경우 네이티브 듀얼 스택을 위해 설계하고 가능한 경우 DNS64를 피하세요.

자주 묻는 질문 #

듀얼 스택 서비스에 A 및 AAAA 레코드가 모두 필요합니까?

예. 듀얼 스택 서비스에 대해 두 레코드 유형을 모두 게시하세요. IPv6를 지원하는 클라이언트는 AAAA를 사용하고 IPv4 전용 클라이언트는 A를 사용합니다. 서비스가 실제로 IPv6를 통해 작동하지 않으면 AAAA를 게시하지 마세요. 손상된 AAAA 레코드는 시간 초과 지연을 유발합니다.

IPv4와 IPv6에 다른 서버를 사용할 수 있습니까?

예. A 및 AAAA 레코드는 독립적이며 다른 서버를 가리킬 수 있습니다. 이것은 점진적인 IPv6 배포 또는 프로토콜별로 트래픽을 다르게 라우팅하려는 경우에 유용합니다. 두 서버 모두 동일한 콘텐츠와 기능을 제공하는지 확인하세요.

모바일에서는 느리지만 WiFi에서는 빠른 이유는 무엇입니까?

모바일 네트워크는 종종 IPv6를 선호하거나 요구합니다. AAAA 레코드가 존재하지만 IPv6 연결이 손상되었거나 느린 경우 모바일 사용자는 시간 초과를 기다리거나 높은 대기 시간을 경험합니다. 여러 모바일 통신사에서 IPv6를 통해 사이트를 테스트하세요. IPv6가 제대로 작동하지 않으면 AAAA 레코드를 제거하세요.

모든 것에 역방향 DNS가 필요합니까?

역방향 DNS는 메일 서버에 필수이며 모든 공개 대면 서버에 강력히 권장됩니다. 클라이언트 주소 또는 내부 서버에는 필요하지 않지만 문제 해결, 로깅 및 보안 분석에 도움이 됩니다.

DNS64가 작동하는지 테스트하는 방법은 무엇입니까?

IPv6 전용 클라이언트에서 IPv4 전용 호스트 이름을 쿼리하세요. DNS64가 작동하면 구성된 접두사 (일반적으로 64:ff9b::/96)로 합성된 AAAA 레코드를 받습니다. DNS64 테스트를 위해 설계된 IPv4 전용 도메인인 dig AAAA ipv4only.arpa를 테스트로 사용하세요.