IPv6는 어떻게 DNS를 알리게 됐나: RDNSS, DNSSL, RFC 5006·6106·8106

요약

SLAAC는 IPv6 호스트에 주소와 경로를 줄 수 있었지만, 이름을 목적지로 바꾸는 재귀 DNS 리졸버까지 제공하지는 않았다.
RDNSS가 Router Advertisement에서 리졸버를 찾게 했고, DNSSL은 검색 접미사를 더했다. 후속 RFC는 수명, 출처 우선순위, 지원 의무를 정리했다.

주소가 있어도 리졸버는 없다

IPv6 호스트에 유효한 주소와 프리픽스, 기본 라우터가 있어도 웹사이트에 도달하기 전에 막힐 수 있다. 웹사이트 이름을 어느 목적지로 연결할지 물어볼 재귀 리졸버가 없기 때문이다. 네트워크는 패킷을 어디로 보낼지 알려줬다. 이름을 어디에 물어볼지는 알려주지 않았다.

Neighbor Discovery와 Stateless Address Autoconfiguration은 첫 번째 문제를 풀었다. Router Advertisement가 링크 정보를 전달했고, SLAAC를 쓰면 호스트가 DHCPv6 주소 임대 없이 주소를 만들 수 있었다. DNS 설정은 별도 경로에 있었다. 2007년 RFC 5006은 DHCP가 IETF의 유일한 Standards Track DNS 설정 방식이라고 적었다. 무선 네트워크를 옮겨 다니는 노트북마다 리졸버를 손으로 바꾸는 방식은 번거로웠다.

RFC 5006은 대안을 내놓았지만 상태는 Experimental이었다. IPv6 Router Advertisement에 Recursive DNS Server 옵션, 즉 RDNSS를 넣을 수 있었다. 호스트는 링크 설정을 담은 같은 광고에서 재귀 리졸버 주소도 받았다. 별도의 프로토콜 교환은 필요하지 않았다. 다만 라우터는 여전히 관리자가 설정해야 했다. RFC가 라우터의 자체 DNS 서버 탐색까지 해결한 것은 아니었다.

라우터가 이름 정보도 알리기 시작했다

2010년 RFC 6106은 DNS 옵션을 Standards Track으로 올리고 DNSSL, DNS Search List를 추가했다. RDNSS는 하나 이상의 리졸버 주소를 전달했다. DNSSL은 애플리케이션이 요청한 불완전한 이름 뒤에 붙일 접미사를 제공했다. 하나의 Router Advertisement 흐름에서 프리픽스와 라우터, 리졸버, 검색 목록을 받을 수 있게 됐다.

DHCPv6가 사라진 것은 아니다. RFC 6106은 DHCPv6와 RA가 서로 다른 네트워크와 호스트 설정에서 함께 쓰일 수 있다고 설명했다. 뒤이은 RFC 8106은 여러 Router Advertisement나 DHCP에서 받은 DNS 정보를 호스트가 순서 있는 목록으로 관리하도록 했다. 사용자가 직접 고정한 DNS는 별도의 선택으로 남았다. 논점은 어느 하나가 모든 곳에서 이기느냐가 아니라, 어떤 출처가 어떤 순서로 적용되느냐였다.

패킷 손실이 타이머를 바꿨다

RDNSS와 DNSSL 항목에는 수명이 있다. 시간이 지나면 호스트가 정보를 지운다. 광고는 리졸버 설정을 영구 저장하는 명령이 아니라, 한시적으로 유효한 설정이다. RFC 6106은 Router Advertisement 사이의 최대 간격을 기준으로 수명을 제한했다. 2017년 RFC 8106은 기존의 하한인 최대 간격 두 배가 손실이 많은 링크에서 DNS 옵션을 만료시킬 수 있다고 짚었다. 새 기본값은 최대 간격의 세 배가 됐다.

패킷 도식에서는 작은 조정이지만 장애 기록에서는 큰 차이다. 주소와 경로가 살아 있어도 리졸버 항목은 사라질 수 있다. 호스트가 IP 주소에 직접 닿을 수 있는데도 애플리케이션은 네트워크가 끊긴 것처럼 보일 수 있다.

IPv6 기본 요구사항에 들어온 지원

메커니즘이 자리 잡으면서 요구 수준도 올라갔다. 2011년 RFC 6434는 구현체가 RA DNS 옵션을 SHOULD 지원해야 한다고 했다. 2019년 RFC 8504는 IPv6 노드가 이 옵션을 MUST 지원해야 한다고 정했다. 실험적 우회로가 필수 역량으로 바뀌었다. 주소 하나만으로는 실제 인터넷 이용에 충분하지 않았기 때문이다.

이 기능의 운영상 핵심은 출처 규칙이다. RFC 8106은 RA와 DHCP에서 온 정보를 순서 있는 목록으로 유지하도록 권고하며, 보통 DHCP 정보가 먼저 온다. SEND로 보호된 RA는 인증되지 않은 DHCP 출처보다 우선한다. 사용자가 정적으로 설정한 DNS가 광고된 정보보다 앞설 수도 있다.

이 RFC들은 설계와 요구사항의 변화를 보여준다. RDNSS를 쓰는 호스트의 공식 집계는 제공하지 않으므로 현재 보급 규모를 이 문서들만으로 셀 수는 없다.