요약

  • DNS 교환을 담는 IP 버전은 요청되는 레코드의 주소 패밀리를 결정하지 않습니다. AAAA 질의가 IPv4를 통해 전달될 수 있고, A 질의가 IPv6를 통해 전달될 수 있습니다.
  • RFC 3596은 새로운 128비트 AAAA 레코드를 DNS의 기존 응답 규칙 갱신과 함께 도입하면서, DNS의 이름 공간과 전송 경로를 개념적으로 분리된 상태로 유지했습니다.

하나의 질문, 서로 다른 두 계층

리졸버가 IPv4 패킷 안에 DNS 질문을 담아 보내는 상황을 생각해 봅시다. “이 이름에 연결된 AAAA 레코드는 무엇인가?” 패킷의 IPv4 헤더는 그 메시지가 어떻게 전달되는지를 기술합니다. 질문의 타입은 IPv6 주소 데이터를 요청합니다. 여기에 모순은 없습니다. RFC 3596은 레코드를 질의하는 데 사용되는 IP 버전이 레코드의 프로토콜 버전과 독립적이라고 명시적으로 밝히고 있으며, RFC 4472는 이후 그 운영상의 함의를 다시 진술합니다. 즉, AAAA는 IPv4를 통해 질의할 수 있고, A는 IPv6를 통해 질의할 수 있습니다.

이 문장은 쉽게 지나치기 쉽습니다. 서로 다른 두 의미의 “IPv4”와 “IPv6”가 나란히 놓여 있기 때문입니다. 하나는 네트워크 계층의 봉투를 가리키고, 다른 하나는 DNS 리소스 레코드에 담긴 데이터를 가리킵니다. 이 둘을 하나의 스위치로 취급하면 DNS 응답이 질문이 전달된 경로에 의존하게 되는데, 그 경로는 해당 이름에 어떤 주소 데이터가 속하는지에 대해 아무것도 말해 주지 않습니다.

이 분리는 반대 방향으로도 작동합니다. IPv6 전송은 DNS 질문이 AAAA를 요구하도록 강제하지 않습니다. 리졸버는 IPv6 전송을 통해 A를 요청할 수도 있습니다. DNS 서버는 자신에게 도달한 패킷의 패밀리만으로 요청자가 응답의 주소 패밀리를 사용할 수 있다고 추론해서는 안 됩니다. 사양이 정의하는 것은 이 독립성이지, 응용 프로그램 연결의 최종 도달 가능성이나 성공이 아닙니다.

도로를 바꾸는 것이 아니라 레코드를 확장한 것

이전의 DNS 모델에서는 32비트 IPv4 주소를 담는 A 레코드가 있었습니다. RFC 1886은 128비트 IPv6 주소를 저장하는 대응 방식으로 AAAA를 도입했고, 역방향 조회 지원도 함께 갖췄습니다. RFC 3152는 별도로 역방향 트리를IP6.INT에서IP6.ARPA로 옮겼습니다. RFC 3596은 IPv6 관련 DNS 변경 사항을 통합하고 기존의 IPv4 지원을 유지했으며, 정방향 레코드를 명확히 했습니다. 타입 28의 AAAA 레코드는 하나의 IPv6 주소를 담습니다.

이것은 DNS 메시지를 위한 새로운 전송 프로토콜이 아니라 DNS 내부 데이터 모델에 대한 확장이었습니다. 질문과 응답은 여전히 기존의 DNS 교환 절차를 사용합니다. 그 교환을 운반하는 네트워크는 요청된 레코드가 A인지 AAAA인지와 무관하게 IPv4 또는 IPv6일 수 있습니다. DNS의 전 세계 공유 이름 공간은 레코드가 이제 두 패밀리를 담을 수 있게 되었다는 이유만으로 “IPv4 DNS”와 “IPv6 DNS”로 갈라질 필요가 없었습니다.

설계 논의에는 실제 대안이 있었습니다. A6 레코드는 주소의 일부를 표현하고 그 조각들을 DNS를 통해 연결함으로써, 프리픽스 변경 시 일부 갱신을 줄이는 방법을 제시할 수 있었습니다. 그러나 그 유연성은 연쇄 조회와 의존성을 수반했습니다. RFC 3363은 AAAA를 표준 트랙에 유지하고 A6와 비트 레이블을 실험적(Experimental)으로 이동시키는 표준 결정을 기록했으며, RFC 3364는 그 트레이드오프를 정리했습니다. 따라서 RFC 3596은 리넘버링이나 배포에 대한 만능 해답이 아니라, 검색하기 단순한 완전한 주소 레코드를 선택한 것입니다.

응답 규칙도 중요했다

RFC 3596이 한 일은 레코드 타입을 지정한 것만이 아닙니다. NS, SRV, MX 질문에 대한 추가 섹션(additional section) 처리를 갱신하여, 로컬에서 이용 가능한 관련 A 및 AAAA 주소를 포함할 수 있도록 했습니다. AAAA 질의 자체는 추가 섹션 처리를 유발하지 않습니다. 이 구분은 직접 요청된 RR과 다른 응답에서 보조 데이터로 제공되는 주소가 별개의 응답 동작이기 때문에 중요합니다.

그러나 “서버가 포함할 수 있다”는 것이 “응답이 모든 주소의 존재를 증명한다”는 뜻은 아닙니다. 사양은 프로토콜 동작을 기술할 뿐입니다. 로컬 데이터는 없을 수 있고, 캐시는 불완전할 수 있으며, 레코드는 테스트 패킷이 아닙니다. RFC 4472는 전송 패밀리만을 근거로 응답 데이터를 선택하거나 필터링하는 것을 경고합니다. DNS 서버에 도달하는 데 사용된 패밀리는 클라이언트가 필요로 하는 레코드의 패밀리와 종종 일치하지 않기 때문입니다. 그 근거로 한 패밀리를 억제하면, 같은 이름이 질의를 전달한 네트워크 경로에 따라 서로 다른 사실을 담고 있는 것처럼 보일 수 있습니다.

이 구분은 DNS가 응답한 뒤에도 유지됩니다. AAAA 응답은 DNS가 어떤 이름에 대해 IPv6 주소 데이터를 돌려주었다는 증거일 뿐입니다. 이 리졸버로부터 IPv6 경로가 존재한다거나, 해당 주소에서 서비스가 대기 중이거나, 방화벽이 세션을 허용하거나, DNSSEC가 데이터를 검증했거나, 응용 프로그램이 연결에 성공했다는 것을 증명하지 않습니다. 마찬가지로, 그 응답을 IPv4로 받았다는 사실은 이후 서비스 연결이 IPv4와 IPv6 중 어느 것을 사용할지에 대해 아무것도 말해 주지 않습니다.

공존을 읽을 수 있게 만든 경계

RFC 3596의 역사적 기여는 흔히 “DNS가 AAAA를 얻었다”로 요약됩니다. 그러나 인터넷이 또 하나의 주소 패밀리를 추가하는 과정에서 이 표준은 중요한 불변성도 지켜냈습니다. 질의를 운반하는 봉투와 응답에 담긴 주소 패밀리는 서로 독립적인 차원이라는 것입니다. 덕분에 리졸버와 서버는 전환기 동안 IPv4 전송으로 IPv6 데이터를 검색할 수 있고, IPv6 전송으로도 여전히 IPv4 데이터를 검색할 수 있는 공통의 이름 공간을 갖게 되었으며, 어느 쪽 경로나 응답도 서비스를 보장한다는 주장은 하지 않았습니다.

표준은 메커니즘과 의도된 분리를 확립합니다. 그러나 구현체들이 얼마나 이를 따랐는지, 특정 리졸버가 올바르게 동작했는지, 어떤 이름의 A와 AAAA 레코드가 동시에 유용했는지는 확립하지 않습니다. 그런 질문에는 각각 구현, 설정, 측정, 도달 가능성에 대한 증거가 따로 필요합니다.

출처:RFC 1034;RFC 1035;RFC 1886;RFC 3152;RFC 3363;RFC 3364;RFC 3596;RFC 3597;RFC 4472.