IPv6 인터넷이 도입되더라도, 상당한 기간 동안은 IPv4 인터넷과 IPv6 인터넷이 공존하는
시기를 거치게 됩니다.

따라서 DNS 네임서버도 IPv4 only 네임서버와 IPv4/IPv6 듀얼스택 네임서버, 그리고
IPv6 only 네임서버 등이 공존하는 기간이 있게 됩니다.

NOTE:IPv4/IPv6 듀얼스택(dual stack)
IPv4/IPv6 듀얼스택이란 시스템 OS에 IPv4 스택과 IPv6 스택이 병존하는 시스템을 지칭
IPv4/IPv6 듀얼스택 시스템은 IPv4 프로토콜과 IPv6 프로토콜 모두를 처리할 수 있어
IPv4 인터넷 및 IPv6 인터넷 모두와 통신이 가능한 환경 제공

DNS 네임서버를 구성할 때, Master 네임서버와 Slave 네임서버로 구성하는데, 이 경우
상황에 따라 IPv4 주소와 IPv6 주소를 적절히 사용하여 구성하게 됩니다.

그러나 일부 DNS 네임서버만 IPv6 주소를 적용하여 구성하는 경우, 아래와 같은 조건을
만족해야 합니다.

Master 네임서버가 IPv4 only 네임서버인 경우

Master 네임서버가 IPv4 only 네임서버이고 Slave 네임서버에 IPv6 주소를 적용하는 경우,
아래와 같은 조합의 경우가 발생합니다.

Master 네임서버가 IPv4 only이고 Slave 네임서버가 IPv6 only인 경우,
Master 네임서버에서 Slave 네임서버로 도메인 존 전송(Zone Transfer)가 불가능하기 때문에
이 경우, 구성이 불가능합니다.

NOTE: Zone Transfer
Slave 네임서버에서는 도메인 존 파일(Zone File)을 관리하지 않음
따라서 Slave 네임서버는 Master 네임서버로부터 도메인 존 정보를 전송받아야 함
이때, Master 네임서버에서 도메인 존의 모든 정보를 Slave 네임서버로 전송하는 절차를
존 전송(Zone Transfer)라 함.
Zone Transfer는 TCP port 53을 사용하여 네트워크 상에서 전송

IPv4 인터넷에서는 IPv4 프로토콜만 사용되었으므로 존 전송(Zone Transfer)는
IPv4 프로토콜 기반으로만 가능했습니다.

그러나 이제 IPv6 인터넷이 도입되면서, 존 전송(Zone Transfer)는 IPv4 기반 혹은 IPv6 기반의
2가지 가능성이 발생하게 됩니다.

따라서 Master 네임서버와 Slave 네임서버를 IPv4와 IPv6를 일부 혼용하여 구성하는 경우,
상호 존 전송(Zone Transfer)이 가능한 구성인지를 먼저 점검해야 합니다.

Master 네임서버가 IPv4/IPv6 듀얼스택 네임서버인 경우

아래는 Master 네임서버가 IPv4/IPv6 듀얼스택 네임서버인 경우에 발생할 수 있는
구성방법의 조합입니다.

이와 같이 Master 네임서버가 IPv4/IPv6 듀얼스택인 경우, 존 전송(Zone Transfer) 상에서
문제가 발생하지 않습니다.

Master 네임서버가 IPv6 only 네임서버인 경우

Master 네임서버가 IPv6 only인 경우, 위와 같이 Master 네임서버가 IPv6 only이고
Slave 네임서버는 IPv4 only인 경우에 구성에 문제가 발생합니다.

위 구성 중에서 Master 네임서버와 Slave 네임서버 모두 IPv6 only로 구성하는 경우에는
상호 존 전송(Zone Transfer) 문제는 발생하지 않지만 리졸루션 문제의 발생 가능성을
고려해야 합니다.

IPv4 인터넷에 존재하는 리졸버(resolver), 곧 리커시브 네임서버들은 거의 대부분이
IPv4 only 시스템입니다.
이 IPv4 only 리커시브 네임서버는 오직 IPv4 패킷의 DNS 질의만 가능하므로 IPv6 only로만
전체 네임서버가 구성된 도메인에 대해서는 DNS 질의 자체를 수행할 수 없게 됩니다.

따라서 IPv6 only Master 네임서버와 Slave 네임서버를 구성하는 방안은 향후에
모든 인터넷이 완전히 순수한 IPv6 인터넷으로 전환 완료된 시점에 적용할 수 있는
방안입니다.

Windows용 BIND 패키지에는 BIND 네임서버 프로그램 외에 dig, nslookup, named-checkconf,
named-checkzone, nsupdate 등 DNS 진단 및 관리도구가 포함되어 있습니다. 이러한 유틸리티를 Windows PC에서 직접 사용할 수 있게 구성하면 DNS 관리에 도움이 됩니다.

구성 방법

Windows OS 환경의 PC에서는 DNS 서버를 설치할 필요가 없으므로
BIND DNS 설치 패키지를 다운로드 받고 특정 디렉토리에 압축을 풀기만 합니다.
그리고 나서 관련 유틸리티만 특정 디렉토리에 복사하여 PC 환경을 구성할 수 있습니다.

BIND DNS 유틸리티만 필요한 경우, 그리고 IPv6 DNS 관련 진단에 사용할 용도인 경우에는
BIND 9.2.3 이상의 버전을 사용하시길 권고합니다.
그 이유는 BIND DNS 패키지에 포함된 dig 유틸리티의 경우, BIND 9.2.3에서 IPv6 관련
기능보완이 이루어진 부분이 있기 때문입니다.

NOTE!: BIND 9.2.3의 dig 유틸리티 IPv6 관련 기능 보완 사항
IPv6 주소에 대한 리버스 질의(reverse query)에 대해 IP6.ARPA. 도메인으로 질의 구현. 이전 버전에서는 IP6.INT 도메인으로 질의, 현재 표준은 IP6.ARPA 도메인 사용으로 규정

예시: dig -n -x 2001:200:0:8002:203:47ff:fea5:3085

BIND DNS 유틸리티 프로그램 설치

BIND DNS 패키지를 임시디렉토리에 압축을 풀어 저장한 후 아래의 파일들을 "C:Bind9"와 같은
별도 디렉토리에 복사합니다.

위의 경우는 네임서버 프로그램을 제외한 모든 점검 유틸리티 및 BIND DNS 관리용 도구,
설정파일 문법 체크 도구 등을 예시한 것입니다.
이외에 각 유틸리티 및 BIND DNS 네임서버의 매뉴얼 HTML 파일이 있으므로 필요한 파일을
복사합니다.

위 파일들이 저장된 디렉토리 "C:Bind9"를 아래와 같이 PC의 환경변수 PATH에
추가 설정합니다.

"내 컴퓨터"의 "속성" -> "고급" 탭 -> "환경변수" -> "시스템 변수" 중 PATH 변수를 선택하여
"편집"을 클릭 -> PATH 변수 값의 끝에 ";C:Bind9"를 추가 입력

이 작업은 PC의 어느 디렉토리에서나 BIND DNS 유틸리티를 실행할 수 있도록 하기 위함입니다.

BIND DNS 유틸리티용 기본 환경구성 파일(configuration file) 구성

Windows 환경에서 BIND DNS는 그 기본 환경구성 파일을 아래의 디렉토리에서 찾게 됩니다.
"C:WINNTSYSTEM32DRIVERSETC" (Windows NT, Windows 2000) "C:WINDOWSSYSTEM32DRIVERSETC" (Windows XP, Windows 2003)

따라서 이 디렉토리에 resolv.conf 파일을 작성하여 저장해야 dig과 같은 유틸리티가 기본적으로
동작할 수 있습니다.

resolv.conf 파일은 UNIX 호스트의 /etc/resolv.conf 파일과 형식이 동일하며, 아래와 같은
내용으로 기본적인 구성을 합니다.

환경구성 파일 : resolv.conf 파일
nameserver 192.0.2.10

192.0.2.10은 리커시브 네임서버의 IPv4 주소입니다.
Dig 유틸리티의 경우, DNS 질의 대상 네임서버가 지정되지 않았을 때, 디폴트로 지정된 네임서버
192.0.2.10으로 DNS 질의패킷을 송출합니다.

NOTE!: BIND DNS의 유틸리티들은 Windows OS의 인터페이스 구성에 포함되어 지정되는
네임서버 IP 설정을 사용하지 않고 resolv.conf 파일의 설정내용을 참조합니다.
Dig 등의 유틸리티를 사용함에 있어 이점을 주의하시기 바랍니다.

한계점

주의할 사항으로는 resolv.conf 파일에 IPv6 주소를 아래와 같이 입력하여 사용할 수는 없다는
점이 있습니다.
nameserver 2001:dc5:a::222

dig 등의 유틸리티가 Windows OS 환경에서는 아직 IPv6 주소로 IPv6 패킷의 DNS 질의를
송출하지는 못하는 상태에 있습니다.
그러나 Linux와 같은 환경에서는 resolv.conf 파일에 IPv6 주소로 네임서버를 지정하여
적용할 수 있습니다

예시: 아래와 같은 경우, UNIX 및 Linux 환경에서는 "2001:2b8:1::2"의 네임서버로
IPv6 패킷의 DNS 질의를 수행, Windows에서는 현재 불가.
dig @2001:dc5:a::222 www.examp.co.kr. a

BIND 네임서버 데몬 프로세스인 named는 디폴트 동작으로 /etc/named.conf 파일을
그 환경구성 파일로 사용합니다.

named.conf 파일의 설정 옵션은 상당히 많습니다.
여기서는 BIND 8버전과 BIND 9버전에 공통되는 가장 기본적인 설정 사항을 제시합니다.

Ref Docs:
BIND 8 과 BIND 9 매뉴얼은 배포 소스 패키지에 포함 또는ISC의 BIND 페이지에서 제공

named.conf 파일은 아래와 같은 내용의 기본적인 설정사항을 포함하여 구성합니다.

1번 구성: 네임서버(named)의 동작에 관련된 글로벌(global) 환경설정 내용

directory는 named가 도메인의 존 파일(zone file)을 저장할 디렉토리를 지정

pid-file은 named 프로세스의 프로세스 ID(PID)를 저장하는 파일을 지정

listen-on-v6는 IPv6 주소를 binding하여 IPv6 패킷의 DNS 질의를 처리하게 지정
위의 경우, 이에 대해 { any; }로 지정한 것은 모든 IPv6 주소에 대해 DNS 서비스를 제공함을
의미함. 이 listen-on-v6 옵션은 디폴트로 disable 상태이므로, IPv6 DNS를 구성하는 경우,
반드시 이 옵션을 지정해야 함

NOTE!: 현 시점을 기준, BIND 9의 경우, "listen-on-v6 { any; };"만 지정 가능
BIND 8의 경우, 네임서버 플랫폼의 특정 IPv6 주소만을 지정하여 설정 가능

allow-transfer는 이 네임서버에 설정된 도메인에 대해 존 전송(zone transfer) 요청을
할 수 있는 슬레이브 네임서버 또는 관리 호스트를 지정. 이 지정된 IP 주소 외의 호스트에서
존 전송 요청을 하는 경우, 이 요청에 대한 응답을 거부

위의 경우과 같은 구성은 네임서버가 리커시브 네임서버로도 동작하도록 구성한 것.
만일 네임서버의 리커시브 리졸루션 기능을 해제하려면 명시적으로"recursion no;"와 같이
추가 지정.

2번 구성: zone "localhost" 정의

zone "localhost"는 localhost에 대한 도메인 존을 정의. (설정 권고 사항)

localhost에 대한 DNS 질의가 발생하는 경우는
가. 단말 호스트의 /etc/hosts 파일에서 'localhost'에 대한 설정을 누락한 경우, 또는
나. UNIX 및 Linux 계열 호스트에서 /etc/nsswitch.conf 파일 설정 중 "host dns file ... "로
설정한 경우

이와 같은 경우, 단말 호스트에서 localhost에 대한 IP 주소를 질의하는 DNS 패킷이
발생하며, 이 질의를 받은 리커시브 네임서버는 ROOT 네임서버로 질의를 하므로 인해
ROOT 네임서버로 불필요한  DNS 질의가 전달되게 됨

NOTE!:zone "localhost"에 대한 설정 권고는 1차적으로는 루트 네임서버에 대한
불필요한 DNS 질의를 방지하는 것이 목적이지만, 이를 설정하지 않은 경우 로컬 호스트들의
응용 어플리케이션에서 접속 지연이 발생할 수 있으므로 설정하는 것이 바람직함.
이는 많은 소프트웨어에서 "localhost"를 코드에 포함하여 사용하는 경우가 존재하기 때문임.

NOTE!: IPv6 단말 호스트가 등장하면서 localhost에 대한 질의는 A type 외에 AAAA type의
DNS 질의가 발생 가능.
이는 단말 호스트에 IPv6 루브백(loopback) 주소 ::1에 대해 localhost 지정이 누락될 경우가
증가할 것으로 보이기 때문임.
따라서 IPv6 환경에서는 localhost 존의 설정이 더욱 필요할 것으로 예상

type master는 zone "localhost"가 네임서버의 권한있는(authoritative) 존임을 지정

file "localhost"는  zone "localhost"의 정보가 "localhost" 파일에 저장되어 있음을 지정
이 경우 이 파일은 option에 의해 지정된 directory "/dns1"하위에 위치.

3번 구성: 루트(root) 네임서버의 hint 정의

zone "."는 네임서버의 필수적인 구성 항목. 루트(root) 네임서버의 IP 주소 정보를 지정.
DNS는 ROOT 도메인에서 트리(tree) 구조로 전세계 도메인 체계를 구성
네임서버는 도메인 네임의 리졸루션 등을 위해 최소한 루트 네임서버의 IP 주소를
미리 알고 있어야 함.
루트 네임서버 현황 정보제공 웹 사이트 :Root Server Technical Operations Assn
루트 네임서버 hint 파일 다운로드 :ftp://ftp.internic.net/domain/named.cache

type hint는 zone "." 지정이 루트 네임서버에 대한 hint 정보지정임을 표시

file "root.cache"는 루트 네임서버의 hint IP 주소가 존 파일 디렉토리의 root.cache 파일에
저장되어 있음을 지정

이 경우, root.cache 파일에 저장된 IP 주소는 네임서버가 초기 구동시 루트 네임서버 중
최소한 하나에 접근하여 현 시점의 모든 루트 네임서버 IP 주소를 파악하는데에 사용됨.
따라서 루트 네임서버 중 하나의 IP 주소가 변경되더라도 네임서버 동작에는 이상이 없음.

4번 구성: 루프백(loopback) IPv4 주소에 대한 역질의(reverse query)용 로컬 도메인

zone "0.0.127.in-addr.arpa"은 호스트의 IPv4 루프백(loopback) 주소 127.0.0.0/8에 대한
역변환 도메인 존을 정의

IPv4의 경우, 루프백 주소는 127.0.0.0/8 주소블럭에 포함된 127.0.0.1을 사용
127.0.0.0/8 주소블럭 자체는 인터넷 상에서 라우팅 될 수 없는 주소블럭으로 예약됨
따라서 루프백 주소용 역변환 도메인(reverse domain)의 정의에 127.0.0.0/8에 해당하는
"127.in-addr.arpa"로 도메인 존을 정의하는 것이 원칙적임.
편의상 "0.0.127.in-addr.arpa."로 도메인 정의 및 설정이 일반적

Ref RFC:RFC3330 Special-Use IPv4 Addresses
IPv4 주소 블록 중 특수한 용도로 사용하는 주소 정리

type master와file "named.ipv4.local"지정

5번 구성: 루프백(loopback) IPv6 주소에 대한 역질의(reverse query)용 로컬 도메인

 zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa."은
IPv6 루프백(loopback) 주소인 "::1/128"에 대한 역질의 도메인 정의

NOTE!: IPv4와 달리 IPv6에서는 IPv6 표준화 단계에서 호스트의 루프백 주소용으로
::1 주소를 정의. 이때, IPv6 주소 블록이 아닌 단독 주소인 "::1/128"로 정의함.
따라서 "::1" 주소에 대한 역변환 도메인을 정의하는 경우, 위와 같이 ::1/128에 대응하는
도메인을 사용하는 것이 올바른 설정임
만일zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa."와
같이 지정한다면, 이 설정은 ::/124 주소블럭 전체에 대한 지정이 되므로 ::2, ::3과 같은
루프백 주소가 아닌 IPv6 주소에 대해서는 향후 문제가 발생할 수 있음

Ref RFC:RFC3513 IPv6 Addressing Architecture

 type master와file "named.ipv6.local"지정

NOTE!: BIND DNS의 Winodws용 패키지는 아직 Windows 환경에서 IPv6 스택을 지원하지
않고 있습니다. 이는 AAAA RR등의 BIND DNS 자체의 IPv6 지원은 가능하지만 IPv6 패킷의
DNS 질의 응답을 처리할 수 없음을 의미합니다.
따라서 IPv6 패킷을 사용하는 DNS 질의 응답을 위한 IPv6 DNS로 구성을 생각한다면
현재로서는 Windows 2003서버 이상의 OS에서 Microsoft의 DNS 서버를 사용하여 구성할 수
있습니다.

설치용 패키지 다운로드

ISC(Internet Systems Consortium)사이트의 BIND DNS 페이지에서 Microsoft Windows용
설치 패키지를 다운로드 받을 수 있습니다.

패키지 명 : "Windows NT / Windows 2000 Binary Kit"

FTP 다운로드 사이트 :ftp://ftp.isc.org/isc/bind/contrib/

설치 방법

Windows용 BIND DNS 패키지는 이미 컴파일된 설치용 패키지로써
일반적인 Windows용 설치 패키지와 동일한 절차로 install 할 수 있습니다.

패키지의 설치 프로그램명 : "BINDInstall.exe"

Windows용 설치 프로그램은 디폴트로 "C:WINNTSystem32dns"에 설치됩니다.

BIND DNS의 환경구성 파일 named.conf는 "C:WINNTSystem32dns"에 위치하게 됩니다.
BIND DNS의 named 프로세스는 구동시, 디폴트로 이 디렉토리에서 named.conf 파일을
검색합니다.

NOTE!: "C:WINNTSystem32dns" 디렉토리는 Windows 서버 OS의 Microsoft DNS 서버가
사용하는 디렉토리입니다. Microsoft DNS 서버는 자신의 zone 파일을 이 디렉토리에 저장,
관리합니다. 이점 유의하시기 바랍니다.

만일 설치 과정에서 디폴트 디렉토리가 아닌, 다른 디렉토리로 "C:mydns"를 지정했다면
이 디렉토리를 기준으로 Unix의 /etc 디렉토리에 해당하는 디렉토리는 "C:mydnsetc"가
됩니다.

named.conf 파일 구성 방법

Windows용 BIND DNS의 환경구성 파일 named.conf 파일의 내용 구성은 Unix 및 Linux의 경우와
기본적으로 동일합니다.

BIND DNS 유틸리티 사용환경 구성

BIND DNS 패키지에는 네임서버 프로그램 외에 유용한 유틸리티가 포함되어 있습니다.
이에는 nslookup, dig, nsupdate 등의 진단 및 관리 도구가 포함됩니다.

Windows용 BIND DNS 패키지에도 이러한 유틸리티들이 포함되어 있습니다.
이 유틸리티들은 하나의 어플리케이션 프로그램이어서 호스트에 지정된 네임서버 정보를
필요로 합니다.

Unix의 경우에는 /etc/resolv.conf 파일이 호스트 시스템의 도메인네임 리졸루션을 위한
리커시브 네임서버 정보를 가지고 있으며, BIND DNS의 유틸리티들은 이 파일에서
지정된 네임서버 IP 주소를 파악하고 동작합니다.

Windows 환경에서는 Unix의 /etc/resolv.conf 파일에 해당하는 파일은 Windows 시스템
디렉토리 중 "C:WINNTSystem32driversetc"의 resolv.conf 파일이 됩니다.

BIND DNS의 설치 및 초기 구동에서 이 resolv.conf 파일이 자동으로 생성될 수 있지만
시스템에 따라서 생성이 되지 않은 경우, 수작업으로 생성, 내용을 작성합니다.

그 내용은 아래와 같이 Unix의 resolv.conf 형식과 동일합니다.
nameserver      192.0.2.100

NOTE!: BIND DNS의 유틸리티 들은 Windows의 IPv6 스택을 아직 지원하지 못하고 있습니다.
IPv6 패킷의 DNS 질의응답을 위한 진단기능은 Windows 환경에서 제공되지 않습니다.
따라서 resolv.conf 파일에도 nameserver 지정을 IPv6 주소로 설정할 수 없습니다.
Unix 또는 Linux 계열에서는 IPv6 스택을 지원하여 정상적으로 동작합니다.

ISC 사이트에서 Windows용 BIND DNS 패키지를 선택하여 다운로드하고, 압축을 풀어 저장한 후,
install 프로그램을 실행합니다.Install 프로그램 : BINDInstall.exeUnix 및 Linux 계열 플랫폼에 설치하는 경우

1. 이미 컴파일된 설치용 패키지를 원하는 경우

인터넷을 검색하여야 합니다.ISC에서는 컴파일된 설치 패키지를 제공하지는 않고, 소스 패키지를 제공하고 있기 때문입니다.컴파일 완료된 BIND DNS SW 설치 패키지는 각 시스템 별로 바이너리 설치 패키지를 제공하는 인터넷 사이트에서 제공되고 있습니다.예를 들어, Solaris의 경우에는http://www.sunfreeware.com/에서 제공하고 있습니다.
컴파일된 설치 패키지를 다운로드 하는 경우, 설치하려고 하는 시스템의 사양 및 OS 버전 등을 잘 확인해서 해당되는 설치 패키지를 다운로드 해야 합니다.설치 패키지를 시스템에 설치하는 절차는 시스템 플랫폼마다 상이합니다.예로써, Solaris의 경우 pkgadd 유틸리티를 사용하며, Linux의 경우에는 rpm 유틸리티로 설치합니다.2. BIND DNS 소스 패키지를 컴파일 하여 설치하는 경우소스 패키지를 다운로드 받아 컴파일 후 설치하려는 경우에는 컴파일에 필요한 컴파일러 및 관련 유틸리티가 먼저 시스템에 설치되어 있어야 합니다.
시스템에 C 컴파일러가 설치되어 있지 않은 경우, GNU의 GCC 컴파일러를 사용하는 것이 무난합니다.GCC 컴파일러는 시스템별 바이너리 설치 패키지를 찾아 설치하는 것이 간편합니다.

UNIX 및 Linux 계열 호스트에서의 BIND DNS 소스 패키지 컴파일 절차

컴파일러가 구비된 환경이라 가정하면, BIND DNS는 기본적으로 다음과 같은 절차로 컴파일 및 설치를 합니다.

BIND 8 버전 계열:

'make install'의 경우에는 root 권한으로 실행해야 합니다.시스템의 각 디렉토리에 파일을 복사 설치하는 과정이기 때문입니다.'make install' 절차는 아래와 같은 주요 디폴트 디렉토리에 BIND DNS 파일을 설치합니다.

BIND 9 버전 계열:

./configure는 시스템 환경을 자동으로 체크하여 컴파일 및 설치용 환경설정을 수행하는 과정입니다.'make install'의 경우에는 root 권한으로 실행해야 합니다.시스템의 각 디렉토리에 파일을 복사 설치하는 과정이기 때문입니다.'make install' 절차는 아래와 같은 주요 디폴트 디렉토리에 BIND DNS 파일을 설치합니다.

Unix 및 Linux 플랫폼 기반 네임서버의 안정적 구동을 위한 시스템 환경 구성

이로써 BIND DNS 네임서버 소스의 컴파일과 설치 과정이 완료되었습니다.이후의 과정은 각 시스템 별로 네임서버가 안정적으로 구동될 수 있는 시스템 환경을 구성하는 작업이 이어집니다.이 과정은 각 시스템 플랫폼별로 상이하므로 각 시스템 환경에 맞는 절차를 수행해야 합니다.여기에서는 일반 Unix 및 Linux 플랫폼에 공통적인 사항만 간략히 제시합니다.

이 중에서 BIND 9는 새로운 아키텍쳐로 설계된 BIND DNS SW로써, 초기 버전부터 IPv6를
지원하고 있습니다.

향후 BIND DNS의 지속적인 배포 버전으로, ISC에서는 가능한 한 BIND 9 버전으로의
업그레이드를 권고하고 있습니다.BIND 8은 가장 널리 적용, 사용하고 있는 BIND DNS 버전입니다.
현재의 IPv4 인터넷 환경에서 널리 적용되어 있는 버전이라고 볼 수 있습니다.

현재 .KR 도메인 네임서버와 같은 기간 인프라 성격의 DNS 네임서버들의 대부분이 BIND 8을
사용하여 운영되고 있습니다.

그러나 향후에는 점차 BIND 9버전으로 전환될 것으로 예상되고 있습니다.

새로이 IPv6 DNS 네임서버를 구축하는 경우, BIND 8 또는 BIND 9 버전 중 최신 버전을 사용하는
것이 바람직합니다.

BIND 8 버전과 BIND 9 버전을 비교할 때, IPv6 지원 기능에는 커다란 차이점은 없습니다.
다만 DNS 기능이 지속적으로 확장되고 있어서, 이 확장 기능을 구현한 정도에 따른 차이점들이
존재합니다.

그리고 중요한 차이점으로는 BIND 9 버전이 새로운 아키텍쳐 모델로 설계, 개발됨으로써
BIND 8에 비해 보다 향상된 시스템 구조를 지니고 있다는 점을 지적할 수 있습니다.

도메인 네임서버의 IPv6 주소 설정 및 위임 설정

DNS는 분산구조형 데이터베이스입니다.

분산구조형 데이터베이스라는 것은 특정한 한 기관에서 모든 도메인 정보를 관리하지 않고
전세계에 걸쳐 분산되어 분산관리되고 있는 체계를 지칭합니다.

도메인 등록을 함으로써 그 도메인 네임 영역(zone)에 대해서는 등록자가 데이터 설정,
수정, 삭제 권한을 전적으로 가지는 것은 DNS가 분산구조형 데이터베이스이기에 그렇습니다.

도메인 위임설정은 분산구조형 데이터베이스 구조에서 특정한 도메인네임에 대한 정보를
가진 네임서버가 인터넷의 어느 주소로 존재하는지를 알려주는 정보를 지정합니다.

일반적인 도메인 위임설정은 아래의 예시와 같이 설정됩니다.

$ORIGIN co.kr. examp                    86400  IN  NS  ns1.examp.co.kr.examp                    86400  IN  NS  ns2.examp.co.kr. ns1.examp.co.kr.         86400  IN  A    192.0.2.10ns2.examp.co.kr.         86400  IN  A    192.0.3.10

$ORIGIN examp.co.kr. @         600 IN SOA ns1.examp.co.kr. adm.examp.co.kr. (                    2004061102 ; serial                    3600 ; refresh (1 hour)                    1800 ; retry (30 minutes)                    1209600 ; expire (2 weeks)                    86400 ; minimum (1 day)                    )         86400 IN  NS  ns1.examp.co.kr.         86400 IN  NS  ns2.examp.co.kr. ns1     86400 IN  A   192.0.2.10 ns2     86400 IN  A   192.0.3.10

이것은 IPv4의 경우입니다.

IPv6의 경우에는 아래와 같은 형식으로 위임이 설정됩니다.

$ORIGIN co.kr. examp                    86400  IN  NS  ns1.examp.co.kr.examp                    86400  IN  NS  ns2.examp.co.kr. ns1.examp.co.kr.         86400  IN  A    192.0.2.10ns1.examp.co.kr.         86400  IN  AAAA 2002:cd5:20a::c000:20ans2.examp.co.kr.         86400  IN  A    192.0.3.10ns2.examp.co.kr.         86400  IN  AAAA 2001:cd5:30a::c000:30a

$ORIGIN examp.co.kr.@         600 IN SOA ns1.examp.co.kr. adm.examp.co.kr. (                    2004061102 ; serial                    3600 ; refresh (1 hour)                    1800 ; retry (30 minutes)                    1209600 ; expire (2 weeks)                    86400 ; minimum (1 day)                    )         86400 IN  NS  ns1.examp.co.kr.         86400 IN  NS  ns2.examp.co.kr. ns1.examp.co.kr.         86400  IN  A    192.0.2.10ns1.examp.co.kr.         86400  IN  AAAA 2002:cd5:20a::c000:20ans2.examp.co.kr.         86400  IN  A    192.0.3.10ns2.examp.co.kr.         86400  IN  AAAA 2001:cd5:30a::c000:30a

이에서 보듯이 IPv6 환경에서는 네임서버의 도메인네임 'ns1.examp.co.kr.'은
A RR과 AAAA RR을 동시에 가질 수 있으므로 위와 같이 AAAA RR에 대한 위임설정이
추가 설정되어야 합니다.

상위 도메인인 "co.kr." 도메인 존에서의 "ns1.examp.co.kr."에 대한 AAAA RR 설정부분을
글루 레코드(glue record)라고 합니다.

글루 레코드(glue record)는 해당 도메인 존의 네임서버가 어느 IP 주소로 접근할 수 있는지
그 IP 주소를 알려주는 역할을 합니다.
리졸버(resolver)는 이 글루 레코드를 참조하여 "examp.co.kr." 도메인이 설정되어 있는
네임서버의 IPv4 주소와 IPv6 주소를 사용하여 접근합니다.

NOTE!: 루트 도메인 네임서버와 .KR 도메인 네임서버에서의 IPv6 주소 위임
루트 도메인 네임서버에서는 아직 IPv6 주소의 네임서버로 AAAA RR의 글루 레코드
위임설정을 제공하지 않고 있습니다. 이것은 현실적으로 문제가 있어서 그렇습니다.
.KR 도메인 네임서버에서는 2004년 하위 .KR 도메인에 대한 IPv6 위임설정을 개시할
예정입니다.

어플리케이션의 IP 주소 리졸루션 일반적 절차

응용 어플리케이션 프로그램에서는 사용자가 입력한 도메인네임을 우선 IP 주소로 변환하는
절차를 거쳐야 합니다.

인터넷 통신을 위해서는 시스템이 제공하는 Socket API를 사용해야 하는데,
Socket API는 도메인네임을 인식할 수 없기 때문입니다.

그래서 먼저 도메인네임 -> IP 주소로 변환하는 절차를 먼저 수행하여 IP 주소를 파악한 후,
Socket API로 IP 주소를 사용한 접속 절차를 개시할 수 있습니다.

IPv4 DNS 환경에서 IP 주소 변환을 위한 함수 gethostbyname()

IPv4 인터넷 환경에서는 이 도메인네임 -> IP 주소 변환을 위해 gethostbyname()을
호출합니다.

struct hostent *gethostbyname(const char *);

gethostbyname()은 도메인네임을 인자로 하여 호출하면 IPv4 주소를 hostent 구조체로
반환합니다.

IPv6 DNS 환경에서 IP 주소 변환을 위한 함수 getaddrinfo()

IPv6에서는 이 함수외에 새로운 함수를 새로 정의하였습니다.

getaddrinfo() 함수는 IPv6 환경에서 도메인네임에 대한 IPv4 주소와 IPv6 주소를 파악하여
반환하는 기능을 제공합니다.

int getaddrinfo(const char *nodename, const char *servname,                const struct addrinfo *hints, struct addrinfo **res);

getaddrinfo() 함수는 지정된 도메인네임을 인자로 받아, AAAA 타입과 A 타입 DNS 질의를
모두 수행한 후에 도메인네임에 설정된 모든 IPv4 주소, IPv6 주소 목록을 어플리케이션으로
반환하는 기능을 기본적으로 제공합니다.

NOTE!: 도메인네임에 대해 한번의 DNS 질의로 IPv4 주소와 IPv6 주소 모두 응답받지는 못함
DNS는 도메인네임에 대한 별도의 리소스레코드로 속성정보(attribute information)을 표시
ftp.examp.co.kr. 180 IN A 192.0.2.200
ftp.examp.cp.kr. 180 IN AAAA 2001:cd5:f::200
위와 같이 설정된 경우 ftp.examp.co.kr 도메인네임에 대한 IP 주소는 A 타입 DNS 질의와
AAAA 타입 DNS 질의의 2번의 DNS 질의를 통해서만 모두 파악 가능

어플리케이션은 getaddrinfo() 함수를 호출하면서, 모든 형태의 IP 주소, IPv4 주소 only, 또는
IPv6 주소 only 등으로 원하는 형태의 주소 타입을 지정하여 호출할 수 있습니다.

Ref Docs:RFC3493 "Basic Socket Interface Extensions for IPv6", 6. Library Functions
RFC3493은 POSIX의 IPv6 지원을 위해 확장된 Socket API에 대한 정보를 제공
Socket API과 함께 어플리케이션이 도메인네임의 IP 주소 변환 관련 라이브러리 함수에
대한 정보도 제공.

현재 출시되고 있는 IPv6 시스템 OS 또는 개발용 라이브러리에서는 이 함수를 구현하고
있으며, IPv6 어플리케이션은 이 함수와 IPv6 지원 Socket 함수를 사용하여 개발된
통신 프로그램입니다.

NOTE!: getaddrinfo()와 같은 IPv6 지원 함수는 IPv4와 IPv6 모두에 적용
IPv6 지원 함수는 IPv6만을 위한 것이 아니라 IPv4와 IPv6 까지 지원 확장된 함수를 의미
IPv6 지원 Socket의 경우도 PF_INET6를 사용, IPv6를 추가 지원
IPv6 어플리케이션은 IPv4와 IPv6 통신 모두 가능한 어플리케이션을 의미함

NOTE!: getaddrinfo() 함수가 무조건 처음부터 DNS 질의를 하는 것은 아님
getaddrinfo() 함수가 DNS 질의를 수행하는 것은 사실이지만 무조건 처음부터 DNS 질의를
하는 것은 아님
Unix 및 Linux 계열 호스트 환경에서는 /etc/nsswitch.conf 파일의 설정 내용에 따라 동작
/etc/nsswitch.conf 파일의 내용 중 "host"에 대한 설정내용이 동작에 영향을 끼침
host   dns files
위와 같이 지정된 경우, 먼저 DNS 질의를 하고 그 응답이 실패한 경우, 호스트 내부의
/etc/hosts와 같은 파일에 설정된매핑정보를 검색
host files dns
위와 같이 지정된 경우, 먼저 호스트 내부의 /etc/hosts와 같은 파일에 설정된
매핑정보를 검색하고, 여기에서 실패한 경우에 DNS 질의 수행 

IPv6 지원 확장 : DNS 네임서버 SW의 IPv6 스택(stack) 지원

DNSv6 네임서버 SW는 앞서 언급한 IPv6 확장을 위한 리소스레코드 및 IP6.ARPA 도메인 처리
기능이 구현된 상태이어야 합니다.

그리고 이에 더불어 IPv6 스택(stack)을 지원할 수 있어야 진정한 DNSv6 네임서버라 할 수
있습니다.

IPv6 스택(stack)이란 시스템 OS에 구현된 IPv6 프로토콜 스택을 지칭합니다.
IPv6는 일반 호스트 환경에서 HW에 구현되는 것이 아니라 OS에 SW 모듈로 구현됩니다.

IPv6 스택을 지원하는 DNS 네임서버는 IPv6 패킷으로 요청되는 DNS 질의를 처리할 수
있습니다.
따라서 IPv6 only 단말 호스트의 경우, IPv4 패킷 기반이 아닌 IPv6 패킷 기반으로 DNS 질의를
할 수 있도록 지원할 수 있습니다.

현재 널리 사용되고 있는 네임서버 SW로는 ISC(Internet Systems Consortium)에서 배포하는
BIND DNS와 Microsoft 사에서 Windows 서버 OS 군에 포함하여 판매하고 있는 DNS 서버가
있다고 할 수 있습니다.

BIND DNS 중에서는 BIND DNS 8.4.0 이상, BIND DNS 9버전이 Unix 및 Linux 계열 호스트에서
IPv6 스택(stack)을 지원하는 DNSv6 네임서버로 구성할 수 있습니다.

Microsoft의 DNS 서버의 경우에는, Windows 2003 서버 OS에 포함된 DNS 서버가
Windows 환경의 IPv6 스택을 지원하는 DNSv6 네임서버로 동작합니다.

NOTE!: BIND DNS의 경우, Windows 계열 호스트에 설치할 수 있으나 IPv6 스택지원 않음
BIND DNS는 Windows용 바이너리 설치 패키지를 배포하고 있습니다.
그러나 Windows의 IPv6 스택(stack)은 아직 지원하지 못하고 있습니다.
ISC에서는 향후 이를 지원할 계획을 가지고 있습니다.

IPv6 지원 확장 : DNS 리졸버 SW의 IPv6 스택(stack) 지원

DNS 리졸버(resolver)는 2가지로 구분됩니다.

원래 IETF RFC 문서에서의 리졸버(resolver)는 루트 네임서버로부터 시작하여
전체 도메인 트리를 검색할 수 있는 리졸루션(resolution) 전체 루틴을 가진 SW를
지칭하는 용어입니다.

Ref Docs:RFC1034 "DOMAIN NAMES - CONCEPTS AND FACILITIES", 5. RESOLVERS

DNS 네임서버에는 기본적으로 이 리졸버(resolver) 전 루틴이 완전하게 구현되어 있습니다.
네임서버의 루트 네임서버 IP 주소 정보를 갖는 root.hint와 같은 파일은 리졸버가
루트 네임서버를 파악할 수 있도록 하기 위한 것입니다.

리졸버 SW 루틴 역시 IPv6 스택을 지원해야 합니다.

만일 리졸버 SW 루틴이 IPv6 스택을 지원하지 못하는 경우, IPv6 주소로만 구성된
DNS 네임서버에 대해 접근이 불가능하여, 도메인네임 리졸루션을 충분히 수행할 수
없기 때문입니다.

단말 호스트인 경우, 이 전체 리졸버(resolver) 루틴을 구현하는 것은 경제적으로
문제가 있습니다.

단말 호스트의 경우에는 리졸버 루틴을 간략화하여 구현한 스터브 리졸버(stub resolver)를
적용합니다.

스터브 리졸버는 리졸루션이 필요한 경우, 지정된 리커시브 네임서버의 IP 주소로 DNS 질의
요청만 합니다.
이때, 요청을 받은 리커시브 네임서버가 단말 호스트의 스터브 리졸버를 대신하여
전체 인터넷 네임서버를 조회합니다.
리커시브 네임서버는 요청된 질의의 응답 정보를 단말 호스트의 스터브 리졸버로 응답합니다.

Local Hosts                     |  Foreign                                                   |    +---------+                                    |    |         | responses                          |    | Stub    |<--------------------+              |    | Resolver|                     |              |    |         |----------------+    |              |    +---------+ recursive      |    |              |                queries        |    |              |                               V    |              |    +---------+ recursive     +----------+         |  +--------+    |         | queries       |          |queries  |  |        |    | Stub    |-------------->| Recursive|---------|->|Foreign |    | Resolver|               | Server   |         |  |  Name  |    |         |<--------------|          |<--------|--| Server |    +---------+ responses     |          |responses|  |        |                              +----------+         |  +--------+                              |  Central |         |                              |   cache  |         |                              +----------+         |

Source:RFC1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
2.2. Common configurations 

스터브 리졸버의 경우, IPv4만을 지원해도 큰 문제는 발생하지 않습니다.
이 경우 지정된 리커시브 네임서버가 IPv4/IPv6를 모두 지원한다는 조건을 만족해야 합니다.

만일 IPv6 지원이 불가능한 IPv4 only 리커시브 네임서버인 경우, 스터브 리졸버는
IPv6 주소로만 설정된 DNS 네임서버의 도메인 정보에 대해서는 리졸루션을 할 수 없는 상황이
발생하게 됩니다.

IPv4 스택 기반의 단말 호스트 스터브 리졸버인 경우, 가능한 한 IPv4/IPv6 듀얼 스택
리커시브 네임서버를 단말 호스트에서 네임서버로 지정하는 것이 IPv4/IPv6 인터넷 환경에서는
바람직한 설정이라 할 수 있습니다.

IPv6 스택을 지원하는 스터브 리졸버 여부는 호스트 시스템 OS에 따라 다릅니다.
이에 대한 정보는 OS의 버전별 구현 기능항목을 검토하여 파악할 수 있습니다.  

IPv6 지원 확장 : AAAA 리소스레코드(Resource Record)

IPv4 주소를 위한 리소스레코드(Resource Record)는A RR입니다.

A RR : hostAddress RR(Resource Record)

IPv6 주소의 경우, 128bit로 표현되는 주소로써 IPv4 주소와는 다른 형식을 가지고 있습니다.
IPv6 주소를 위한 리소스레코드(Resource Record)는AAAA RR로 신규 정의되었습니다.

AAAA RR : IPv6 Address RR(Resource Record)

AAAA RR은 "Quad-A RR"이라고 읽습니다.
이런 명칭이 부여된 것은 IPv6 주소는 128bit의 주소 공간을 사용하고 이는 IPv4 주소(32bit)에
비해 4배 큰 것이므로 A를 4번 사용한 명칭인 'AAAA'를 부여한 것으로 알려져 있습니다.

아래는 IETF RFC 문서의 A RR과 AAAA RR 포맷의 예시입니다.

Ref Docs:
A RR :RFC1035 "Domain Names - Implementation and Specification"
AAAA RR :RFC3596 "DNS Extensions to Support IP Version 6"

AAAA RR은 A RR보다 12 bytes를 더 사용합니다.
따라서 네트워크 상의 DNS 응답 메시지에서 AAAA RR이 포함됨으로써 DNS 메시지 길이가
전반적으로 길어지게 됩니다.
이는 루트 네임서버의 경우, 문제를 발생시키는 요인이 되므로 루트 네임서버의 IPv6 적용에 있어
장애요인으로 작용하고 있습니다.

NOTE!: 리소스레코드(Resource Record)는 바이너리 형태의 포맷을 가짐
존 파일(Zone File)은 바이너리 형태의 리소스레코드 정보를 쉽게 표현할 수 있도록
텍스트 기반의 양식을 정의한 것임. 네임서버는 존 파일(Zone File)을 읽으면서 구문에 따라
해석을 하여 바이너리 형태의 리소스레코드를 메모리 데이터베이스에 추가함.
따라서 A RR과 AAAA RR은 메모리 상에서, 그리고 패킷 상에서 바이너리 IP 주소로 표현됨.
(Ref Docs:RFC1035 "Domain Names - Implementation and Specification")

위의 예시에 대한 존 파일(Zone File)에서의 표현은 아래와 같습니다.

IPv6 지원 확장 : IP6.ARPA 도메인

IPv4 주소를 사용하여 이 IPv4 주소를 갖는 호스트의 도메인 네임을 조회할 수 있습니다.

DNS에 해당 IPv4 주소에 대한 도메인네임 정보를 질의함으로써 정보를 조회할 수 있습니다.
이때 사용하는 도메인이 "in-addr.arpa" 도메인입니다.

예를 들어 "192.0.2.100" 주소에 대해 그 도메인네임을 파악하려는 경우,
아래와 같이 DNS 질의를 수행합니다.

위와 같이 IPv4 주소를 역변환 배열하고(192.0.2.100 -> 100.2.0.192), 그 뒤에 "in-addr.arpa."를
덛붙여 DNS 질의를 하는 방식을 사용합니다.

IPv6의 경우에도 이와 동일한 메커니즘이 필요합니다.

IPv6의 경우에는 IPv4의 "in-addr.arpa."에 해당하는 도메인을 "ip6.arpa."로 정하였습니다.

IPv6 주소 "2001:cd5:f::c000:264"에 대한 도메인네임을 역변환하기 위해
아래와 같은 방식을 통해 "ip6.arpa."에 속하는 도메인네임을 생성하여 DNS 질의를 합니다.

1. "2001:cd5:f::c000:264" -> "2001:0cd5:000f:0000:0000:0000:c000:0264"
압축 표현된 IPv6 주소를 원래 미압축 상태의 전체 IPv6 주소 표현으로 전환하고

2. -> "2.0.0.1.0.c.d.5.0.0.0.f.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.0.2.6.4"
각 4bit의 16진수(nibble)를 점(.)으로 구분 표시

3. -> "4.6.2.0.0.0.0.c.0.0.0.0.0.0.0.0.0.0.0.0.f.0.0.0.5.d.c.0.1.0.0.2"
전체 순서를 역전하여 표기

4. -> "4.6.2.0.0.0.0.c.0.0.0.0.0.0.0.0.0.0.0.0.f.0.0.0.5.d.c.0.1.0.0.2.ip6.arpa."
끝에 "ip6.arpa." 도메인 추가

위와 같은 복잡한 과정을 수작업으로 준비하여 DNS 질의를 하는 것은 불가능합니다.

IPv6 주소에 대한 역변환 질의(reverse query)는 주로 어플리케이션에 의해 자동적으로
발생합니다. e-메일 서버와 같은 경우, 접속하는 대상 호스트의 IPv6 주소를 대상으로
DNS 역변환 질의를 위와 같이 수행합니다.

IPv6 주소에 대한 도메인네임 역변환 질의(reverse query)를 점검하려는 경우, 다음과 같이
BIND DNS의 유틸리티인 dig을 사용할 수 있습니다.

-n옵션은nibble 형식이라는 것을 표시하는 것이며,
-x옵션은 뒤의 문자열이 IP 주소이며, 이 IP 주소에 대한 도메인네임 역변환 질의 수행을 지시

NOTE: nslookup을 사용하여 IPv6 주소 역변환 질의(reverse query)를 하는 방법
nslookup -n -x  2001:cd5:f::c000:264
단, 이 경우에도 nslookup이 BIND DNS 9.2.3 버전이상에 포함된 nslookup 사용 필요

DNSv6는 IPv6를 지원하는 DNS를 의미합니다.

그러나 IPv6를 지원하는 DNS가 따로 존재하여 현재의 DNS를 대체하는 것은 아닙니다.
현 DNS가 IPv6 인터넷도 지원할 수 있도록 확장 재구성하는 것을 의미합니다.

IPv6를 지원하기 위해 DNS 체계와 관련된 확장 요소들이 아래와 같이 존재합니다.

DNS는 독립된 어플리케이션이 아니라 다른 인터넷 응용 어플리케이션을 지원하는 특수한
기반 인프라 성격의 어플리케이션입니다.

DNSv6를 구성하는 것은 단지 DNS 네임서버 등에 국한된 것은 아닙니다.
DNS의 확장은 DNS 네임서버와 단말 호스트의 리졸루션(resolution) 환경을 포괄하며,
더 나아가 단말 호스트의 스터브 리졸버(stub resolver)와 응용 어플리케이션간의
도메인 네임 리졸루션(resolution)을 위한 API(Application Programming Interface)에 변경이
발생하게 됩니다.

아래는 DNSv6와 관련된 API 확장 요소입니다.

DNSv6는 IPv6를 지원하는 DNS로 정의할 수 있습니다.

DNS(Domain Name System)는 단순히 네임서버 시스템만을 지칭하는 것이 아니라 도메인네임,
네임서버, 그리고 단말 호스트의 리졸버(resolver) 루틴을 포괄하는 도메인네임 시스템 체계를
지칭합니다.

따라서 DNSv6는 IPv6 인터넷의 도메인네임 체계, DNS 네임서버, 단말 호스트의
IPv6 리졸루션 환경을 포괄하여 IPv6 지원 체계를 안정적으로 구현하는 것을 포함하고
있습니다.