100.2.0.192.in-addr.arpa.

질의 도메인네임

QType

PTR

질의 타입 (리소스레코드 타입)

QClass

IN

질의 Class

※ 단, dig이 BIND DNS 9.2.3 버전 이상에 포함된 dig이어야 함.
     이전 버전은 ip6.int. 도메인에 대해 질의 수행.

DNSv6는 IPv6를 지원하는 DNS이다.

"DNSv6 네임서버"는 기존 IPv4 인터넷의 DNS와 구별하여 IPv6를 지원하는 DNS 네임서버를 지칭하기 위한 용어이다.

DNSv6 네임서버는 아래의 조건을 충족하는 네임서버이다.

위와 같이 하나의 도메인 네임이 IPv4 주소와 IPv6 주소를 동시에 가질 수 있게 된다.
도메인 네임은 IPv4 인터넷과 IPv6 인터넷 상에서 언제나 동일하게 유지된다.

IPv6 통신을 위해서 호스트의 통신방식에 변화가 필요하다.
어플리케이션에서는 IPv6 기반 통신방식을 구현해야 한다.

어플리케이션이 네트워크 통신을 위해 사용하는 소켓(socket) API(Application Program Interface)가 ‘확장’ 정의되었다. (RFC3493, 'Basic Socket Interface Extensions for IPv6')

이와 더불어 어플리케이션 프로그램이 도메인네임을 IP 주소로 변환하기 위해 호출하는 함수가 새롭게 정의되었다. (RFC3493)

"IPv6 어플리케이션"은 IPv6 확장 소켓(socket) API와 도메인네임 리졸루션 함수 getaddrinfo()를 사용하여 IPv4 및 IPv6 통신이 가능한 프로그램을 지칭한다. IPv6 통신전용 프로그램을 지칭하는 것은 아니다.

IPv6 어플리케이션 프로그램은 사용자가 입력한 도메인 네임에 대한 IPv4 주소와 IPv6 주소 모두를 파악한다. 이때 IP 주소 파악을 위한 표준 함수 getaddrinfo()를 호출한다. getaddrinfo() 함수는 DNS 질의를 통해 도메인 네임에 설정된 IP 주소를 파악한다. DNS 질의는 AAAA RR과 A RR에 대한 질의가 된다.

getaddrinof() 함수는 응답된 DNS 메시지를 분석하여 어플리케이션 프로그램으로 IPv4 주소와 IPv6 주소 목록을 리턴한다. IPv6 어플리케이션 프로그램은 IPv4 또는 IPv6 주소를 선택하여 소켓(socket) 함수를 호출, 접속을 개시한다.

1960년대 말 등장한 미국 ARPANET이 인터넷의 기원이다.
ARPAnet은 미국의 주요 연구기관을 연결한 광역 컴퓨터망으로써 미국 국방부의 ARPA(Advanced Research Project Agency)가 투자하여 개발하였다.

TCP/IP 프로토콜은 1980년대 초에 이르러 개발되었다.
IP는 'Inetnet Protocol'의 약자로서 산재한 컴퓨터 네트워크 간에 상호 연동을 하기 위한 프로토콜이다.
(※ TCP/IP는 하나의 통합 프로토콜 스택으로 개발되었으나 나중에 TCP와 IP로 분리되었다. 아직도 IP 프로토콜 군을 TCP/IP라 부르고 있는 것은 초기의 명칭에 연유한다.)
TCP/IP 프로토콜은 빠른 속도로 ARPANET에서 컴퓨터 네트워킹의 표준 프로토콜이 되었다.

이 당시만 해도 DNS는 존재하지 않았다.

버클리 대학의 BSD Unix에 TCP/IP 프로토콜이 탑재되면서 ARPANET에 연결된 호스트 수가 급격히 증가하기 시작했다. 당시 BSD Unix는 거의 무료로 대학에 배포되고 있었다.
ARPANET에 연결된 호스트들은 기관 내부의 LAN에 연결되었으며 이 LAN에는 상당한 수의 호스트가 설치되었다.

1974년 기준 ARPANET은 50Kbps의 X.25 백본 네트워크로 총 23개의 호스트만이 존재하고 있었다.
ARPANET에 연결된 호스트는 1981년에는 213개, 1983년에는 562개, 1984년에는 1024개, 1985년에는 1961개, 1986년 2308개, 1987년 28174개로 기하급수적인 증가세를 보였다.

이렇듯 TCP/IP를 기반으로 형성된 지역 및 광역 네트워크를 인터넷(Internet)이라 부르게 되었다.

TCP/IP 표준 프로토콜의 등장과 BSD Unix의 TCP/IP 지원으로 인한 호스트 증가는 새로운 문제를 낳게 되었다.
그것은 바로 기하급수적으로 증가하는 호스트의 네임을 어떻게 구성, 관리할 것인가의 문제였다.

초기 ARPANET 환경에서는 각 호스트의 주소를 모두 외울 수 있었다. 호스트 수가 증가함에 따라 니모닉(mnemonic)을 호스트별로 부여하여 쉽게 기억할 수 있게 하였다. 니모닉 네임(mnemonic name)과 네트워크 주소의 매핑 테이블이 사용되었다. 호스트마다 설정하는 호스트 네임(host name)은 여기서부터 유래하였다.

1981년 ARPANET의 호스트들은 213개에 달하고 있었다.

이 시기에 각 호스트들은 HOSTS.TXT 파일에 ARPANET의 모든 호스트 네임과 네트워크 주소 테이블 정보를 갖고 있었다.

이 HOSTS.TXT 파일은 각 호스트에서 지정된 SRI NIC의 FTP 서버(SRI-NIC)에서 주기적으로 다운받아 업데이트를 하는 방식으로 관리되었다. Unix 계열 호스트에서 볼 수 있는 /etc/hosts 파일은 이 HOSTS.TXT에서 연유한 것이다. (RFC 952, "DOD INTERNET HOST TABLE SPECIFICATION")

호스트 수가 급격히 증가하면서 HOSTS.TXT 파일로 모든 호스트 정보를 관리하는 것은 점차 불가능하게 되었다.

HOSTS.TXT 기반 체계의 가장 큰 문제점은 확장성이 부족하다는 점이었다.

HOSTS.TXT 파일을 중심으로 한 관리체계는 ARPANET NIC(Network Information Center)에 의한 일관성 있는 관리가 가능했다.
그러나 호스트 수가 급증하면서 HOSTS.TXT의 다운로드 트래픽과 시스템 부하로 인한 HOSTS.TXT 업그레이드 절차에 문제가 발생하기 시작했다.
HOSTS.TXT 파일에 대한 로컬 호스트 내에서의 수정과 정보 변경에 의해 네임의 일관성 유지가 힘들었다.
급증한 호스트들 가운데 IP 주소를 변경하거나 새로운 호스트가 발생하여 모든 호스트의 HOSTS.TXT 정보를 동일하게 유지하는 것이 불가능하게 되었다.

DNS(Domain Name System)은 위와 같은 HOSTS.TXT 체계의 문제점을 극복하는 새로운 네임체계이다.

1984년 USC Information Sciences Institute의 Paul Mockapetris에 의해 DNS(Domain Name System)가 제시되었다. (RFC882 & RFC 883, 이후에 이 2개의 RFC는 각각 RFC1034 & RFC1035로 개정)

DNS(Domain Name System)의 가장 본질적인 특징은 ‘분산구조의 데이터베이스(distributed database)’이라는 점이다.

DNS는 계층적 구조를 갖는 분산구조 데이터베이스이다.

분산구조 데이터베이스라는 것은 각 도메인 네임 영역(Zone)별로 독자적으로 관리 유지한다는 것을 의미한다.
.KR 도메인 영역의 경우, 한국의 도메인 관리기관이 전적으로 관리한다. 또한 .KR 도메인을 등록받은 각 기업은 자신의 도메인 영역(Zone) 내의 정보를 독자적으로 관리한다.

DNS는 다음의 3가지 핵심요소로 구성된다.

도메인네임은 유일한 값을 갖는 키워드 역할을 하며, 리소스레코드는 이 키워드에 매핑된 정보를 유형별로 표현하는 역할을 한다.

[ 네임서버(Name Servers) ]
네임서버는 도메인 트리구조 정보와 리소스레코드 정보를 보유하고 있는 프로그램을 지칭한다. 흔히 알고 있는 DNS 서버 또는 네임서버를 지칭한다.

[ 리졸버(Resolvers) ]
클라이언트의 요청에 의해 네임서버로부터 정보를 검색, 조회하는 프로그램을 지칭한다.
이때 클라이언트란 TELNET, FTP와 같은 사용자 프로그램을 의미한다.

도메인네임 공간(Domain Name Space)과 리소스레코드(Resource Record)가 도메인 데이터베이스 구조체계를 의미한다면, 네임서버(Name Servers)와 리졸버(Resolver)는 이 데이터베이스 시스템 구현방식을 의미한다고 할 수 있다.

[ 스터브 리졸버(Stub Resolvers) ]
단말 호스트의 경우, 리졸버(Resolver) 전체기능을 구현하는 것은 비경제적이다.
그래서 캐슁(caching) 기능이 있는 리졸버(Resolver) 서버를 두고, 단말 호스트는 단순한 DNS 질의요청만 수행하도록 구현한다.
이때, 단말 호스트에 구현된 단순화된 리졸버(Resolver) 루틴을 스터브 리졸버(Stub Resolver)라 한다.

PC나 호스트에 기본적으로 내재된 리졸버(Resolver)는 스터브 리졸버(Resolver)의 기능을 수행한다.

[ DNS 프로토콜 ]
DNS 프로토콜은 네임서버(Nname Servers)와 리졸버(Resolver)간 DNS 질의응답을 위한 프로토콜이다.
리졸버(Resolver)와 클라이언트(Client, 사용자 프로그램)간에는 프로토콜이 필요하지 않다.

DNS 프로토콜 규정은 RFC1034와 RFC1035를 참조.
RFC1034, "DOMAIN NAMES - CONCEPTS AND FACILITIES"
RFC1035, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

IPv6 지원 DNS를 위한 IPv4/IPv6 듀얼스택 기반의 범국가적 시범 서비스 망

IPv6 응용 서비스의 시범적 도입을 지원하기 위한 IPv6 시험전용 시범용 도메인인 TEST.KR 도메인 제공 서비스

TEST.KR 도메인 및 DNSv6 기술정보 제공

KRDNSv6 시범망은 국내 IPv6 기반 DNS 환경으로 안정적 전환을 위해 2004년 시범적용 단계 추진

IPv6 인터넷을 위한, IPv4/IPv6 기반 국가 기간 DNS 네트워크

KRDNSv6는 IPv6 인터넷의 도래에 대비하여 현재의 IPv4 인터넷 및 차세대 IPv6 인터넷에서 인터넷 응용 서비스가 안정적이고 원활하게 동작할 수 있도록 확장 구성한 IPv6 지원 .KR 도메인 DNS서비스를 지칭한다.

KRDNSv6 시범망 구현은 (재)한국인터넷정보센터(이하 KRNIC)에서 정통부의 "인터넷주소자원관리기반사업"의 일환으로 구축

IPv4/IPv6 기반 국가 기간 DNS 네트워크를 시범적으로 구성한 시범망

국내 IPv6 도입과정에서 .KR 도메인 네임서버의 안정적인 IPv6 DNS 체계 전환을 지원하고, IPv6 인터넷 관리자 및 사용자에 대해 DNSv6 기술 자료 및 운영 가이드를 산출 제공함으로써 IPv6의 원활한 도입을 촉진하며, IPv6 응용 서비스와 DNSv6 간 발생가능 문제점을 사전에 도출, IPv6 인터넷의 본격적인 도입을 준비하기 위한 지원활동 수행

정부에서 추진하고 있는 ‘IT389 전략‘ 중 3대 인프라 요소 중 하나인 IPv6 기반 환경 조기 구축의 일환으로 추진

IPv6 인프라는 BcN(광대역 통합망), 홈 네트워크, 텔레매틱스 등 차세대 정보통신 환경 및 서비스의 기반 토대. 정부는 BcN(광대역 통합망), 휴대 인터넷, 홈 네트워크 등 신규 사업에 IPv6를 적용하고, RFID 및 3G 이동통신 사업과도 연계 추진 예정

정부는 2004년 IPv6 시범망 확대 구축, 2005년부터 IPv6 상용서비스 개시, 2010년 이후에는 All-IPv6 기반 서비스 제공을 계획하여 추진

KRDNSv6 시범망은 IPv6 기반 인프라 구축을 위한 7대 과제 중 “IPv6 주소자원 관리 및 IPv6 DNS 서비스 도입”의 일환으로 추진

IPv6 도입에 적극적인 국가들은 IPv6 인터넷을 위한 IPv6 DNS 체계의 재정비를 선도적 추진
한국은 일본, 프랑스 등에 이어 IPv6 DNS 체계를 선도적으로 전환 재구성 추진 중