라이브러리
프로그래밍언어, 각종코드, 관련동향, 논문 등의 저장소
Technology/DNSv6 (27)
DNS 관련 사이트 링크
  Comments,     Trackbacks
DNS Clinic 소개
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
DNS와 인터넷 응용 서비스
 

인터넷은 IP 주소를 사용하여 네트워크 통신을 합니다.
따라서 인터넷의 네트워크 통신이 가능하려면 IP 주소를 반드시 알고 있어야 합니다.
하지만 인터넷 사용자들은 IP 주소를 사용하여 통신하지 않습니다.
대신 도메인 네임(domain name)이라는 기억하기 쉬운 식별체계를 사용합니다.
도메인 네임을 IP 주소로 변환될 수 있도록 하는 것이 DNS 질의응답 절차입니다.

웹 사이트는www.nic.or.kr과 같은 도메인 네임을 입력하여 접속합니다.
사용자는 잘 느끼지 못하지만 짧은 시간내에www.nic.or.kr도메인 네임의 IP 주소 파악절차가 수행됩니다.
웹 브라우저 프로그램은 이 도메인 네임www.nic.or.kr에 대해 IP 주소를 DNS 서버에 질의합니다.
웹 브라우저가 IP 주소를 파악한 후에 비로소 해당 웹 서버 시스템으로 접근할 수 있게 됩니다.

전자메일은krdnsv6@nic.or.kr과 같은 전자메일 주소를 사용하여 메일을 발송합니다.
전자메일 프로그램은nic.or.kr도메인에 대해 메일서버 IP 주소를 DNS 서버에 질의합니다.
DNS 서버는nic.or.kr도메인의 메일서버 서버의 IP 주소정보를 응답합니다.
전자메일 프로그램은 메일서버의 IP 주소로 네트워크 접속을 개시합니다.

만일 DNS에 문제가 있다면?
대부분의 인터넷 응용 어플리케이션은 도메인 네임을 사용합니다.
인터넷 통신 프로그램들은 네트워크 접속에 필요한 상대 서버의 IP 주소를 파악하는 동작을 수시로 수행합니다.

만일 도메인 네임에 대한 IP 주소 파악에 실패한다면, 네트워크를 통한 통신은 원천적으로 불가능하게 됩니다.
상대방의 IP 주소를 알아야 네트워크 접속을 개시할 수 있습니다.
IP 주소를 모른다면 접속시도 자체를 할 수 없습니다.

이것이 DNS Clinic이 필요한 이유입니다.
DNS 서버와 도메인 설정에 오류가 있는 경우, 인터넷 서비스가 동작하지 않을 수 있습니다.

예를 들어,nic.or.kr도메인의 메일서버 지정은 아래와 같이 설정합니다.

 
사용자 삽입 이미지
사용자 삽입 이미지
 
사용자 삽입 이미지
$ORIGIN
사용자 삽입 이미지
nic.or.kr.
사용자 삽입 이미지
$TTL
사용자 삽입 이미지
1800
사용자 삽입 이미지
nic.or.kr.
사용자 삽입 이미지
8400
사용자 삽입 이미지
SOA
사용자 삽입 이미지
ns1.nic.or.kr. admin.nic.or.kr. (
사용자 삽입 이미지
2004060801 ; serial
사용자 삽입 이미지
7200
사용자 삽입 이미지
; refresh (2 hours)
사용자 삽입 이미지
3600
사용자 삽입 이미지
; retry (1 hour)
사용자 삽입 이미지
2419200
사용자 삽입 이미지
; expire (4 weeks)
사용자 삽입 이미지
600
사용자 삽입 이미지
; minimum (10 minutes)
사용자 삽입 이미지
)
사용자 삽입 이미지
MX
사용자 삽입 이미지
10 mail.nic.or.kr.
사용자 삽입 이미지
NS
사용자 삽입 이미지
ns1.nic.or.kr.
사용자 삽입 이미지
NS
사용자 삽입 이미지
ns2.nic.or.kr.
사용자 삽입 이미지
ns1.nic.or.kr.
사용자 삽입 이미지
A
사용자 삽입 이미지
210.222.111.100
사용자 삽입 이미지
ns2.nic.or.kr.
사용자 삽입 이미지
A
사용자 삽입 이미지
210.222.112.100

사용자 삽입 이미지
mail
사용자 삽입 이미지
A
사용자 삽입 이미지
210.222.111.101
 

이렇게 설정한 경우,krdnsv6@nic.or.kr로 발송된 전자메일은mail.nic.or.kr(210.222.111.101)서버로 송달됩니다.

그러나 만일 아래와 같이 설정했다고 가정한다면,

 
사용자 삽입 이미지
$ORIGIN .
사용자 삽입 이미지
$TTL
사용자 삽입 이미지
1800
사용자 삽입 이미지
nic.or.kr.
사용자 삽입 이미지
8400
사용자 삽입 이미지
SOA
사용자 삽입 이미지
ns1.nic.or.kr. admin.nic.or.kr. (
사용자 삽입 이미지
2004060801 ; serial
사용자 삽입 이미지
7200
사용자 삽입 이미지
; refresh (2 hours)
사용자 삽입 이미지
3600
사용자 삽입 이미지
; retry (1 hour)
사용자 삽입 이미지
2419200
사용자 삽입 이미지
; expire (4 weeks)
사용자 삽입 이미지
600
사용자 삽입 이미지
; minimum (10 minutes)
사용자 삽입 이미지
)
사용자 삽입 이미지
MX
사용자 삽입 이미지
10 mail.nic.or.kr.
사용자 삽입 이미지
NS
사용자 삽입 이미지
ns1.nic.or.kr.
사용자 삽입 이미지
NS
사용자 삽입 이미지
ns2.nic.or.kr.
사용자 삽입 이미지
ns1.nic.or.kr.
사용자 삽입 이미지
A
사용자 삽입 이미지
210.222.111.100
사용자 삽입 이미지
ns2.nic.or.kr.
사용자 삽입 이미지
A
사용자 삽입 이미지
210.222.112.100

사용자 삽입 이미지
mail
사용자 삽입 이미지
A
사용자 삽입 이미지
210.222.111.101
 

도메인 존 파일로 보기에는 별다른 차이가 없고 문제가 없어 보입니다.

그러나 이 경우,krdnsv6@nic.or.kr로 발송된 전자메일은mail.nic.or.kr(210.222.111.101)서버에 송달되지 못하고 모두 송달실패하게 됩니다.
전자메일 프로그램이 DNS 서버로nic.or.kr.도메인의 메일서버 IP 주소 질의에 대해 DNS 서버는 메일서버의 IP 주소정보를 응답하지 않기 때문입니다.

위 도메인 존 파일의 내용 중 아래의 메일서버 IP 주소 정보 설정은mail.nic.or.kr.이 아닌 mail.으로 해석되어 서비스에서 제외됩니다.

 
사용자 삽입 이미지
mail
사용자 삽입 이미지
A
사용자 삽입 이미지
210.222.111.101
 

NOTE: 오류의 원인 - 위와 같이 "$ORIGIN ."으로 지정된 존 영역에 "mail"로 호스트명을 표기한 경우, 도메인네임은 "mail."으로 해석되어 루트 도메인(".") 바로 하위에 "mail." 이라는 도메인네임을 지정한 것으로 네임서버는 해석하게 됩니다. 네임서버는 이 도메인 네임 "mail."을 존 영역을 벗어난 설정으로 판단하여 메모리에 RR 데이터의 loading 과정에서 에러 처리하고 반영하지 않게 됩니다.

이렇게 도메인 정보의 오류는 서비스의 불능상태를 유발할 수 있습니다.
많은 경우, 도메인 존 파일에서의 사소한 실수로 인해 이와 같은 서비스 장애가 발생하게 됩니다.

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
DNS Clinic 이란?
 

DNS Clinic은 도메인 정보가 정확하게 설정되어 있는지를 확인하고 분석하는 작업을 의미합니다.

DNS 서버와 도메인 존 정보의 오류를 분석하기 위한 도구들이 각 시스템별로 존재합니다.
일반에게 잘 알려져 있는 nslookup(name server lookup)이라는 유틸리티가 이에 속합니다.

KRDNSv6에서는 이러한 DNS 진단용 도구를 웹 기반으로 제공하기 위한 DNS Clinic 메뉴를 제공합니다.

DNS Clinic에서는 언제 어디서나 원하는 DNS 서버와 도메인에 대한 점검을 쉽게 할 수 있도록 웹 기반 점검도구를 제공하는 것을 목적으로 합니다.

새로운 DNS 질의 점검 도구인 dig(domain information groper)과 기타 도구를 웹 기반으로 제공할 계획입니다.

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
DNS Clinic Tools
 

KRDNSv6의 웹 기반 DNS 점검도구는 기본적으로 DNSv6를 지원합니다.

사용자 삽입 이미지
사용자 삽입 이미지
Dig (domain information groper)
사용자 삽입 이미지
- BIND DNS에 포함된 새로운 DNS lookup 유틸리티
사용자 삽입 이미지
- nslookup 보다 개선된 전문적인 점검 기능 제공
사용자 삽입 이미지
- KRDNSv6 웹기반 dig
사용자 삽입 이미지
http://www.krdnsv6.or.kr/clinic/dig.jsp
사용자 삽입 이미지
- KRDNSv6 웹기반 dig은 IPv6 기반 DNS 질의와 IPv6 주소에 대한 IP6.ARPA 도메인의 역질의 점검 가능

사용자 삽입 이미지
사용자 삽입 이미지
Zone Checker
사용자 삽입 이미지
- 도메인 존에 대한 자동 점검 및 분석 도구
사용자 삽입 이미지
- 존 설정 오류 및 기타 불안정 요소 자동 검출
사용자 삽입 이미지
- 8월 1일부터 제공 예정

이외에 유용한 웹 기반 점검 도구를 개발, DNS Clinic 메뉴에서 제공할 예정입니다.

  Comments,     Trackbacks
IPv6 패킷 기반 존 전송(Zone Transfer)은 어떻게 설정하나요?
Master 네임서버와 Slave 네임서버가 아래와 같이 구성된 경우에 존 전송(Zone Transfer)를
IPv6 주소를 사용하여 수행할 수 있습니다.
Master 네임서버Slave 네임서버비고
IPv4/IPv6IPv4/IPv6IPv4 zone transfer, IPv6 zone transfer
모두 가능
IPv4/IPv6IPv6 onlyIPv6 zone transfer만 가능
IPv6 onlyIPv4/IPv6IPv6 zone transfer만 가능
IPv6 onlyIPv6 onlyIPv6 zone transfer만 가능 
존 전송(zone transfer)에 대한 설정은 Slave 네임서버의 named.conf 파일에서 지정합니다.
IPv4 주소의 존 전송(zone transfer) 설정 방법
아래는 IPv4 환경에서의 기본적인 설정 사례입니다.
Slave 네임서버 "named.conf" 파일의 "examp.co.kr." 존 설정 부분
zone    "examp.co.kr" {          type slave;         masters { 192.0.2.10; }; };
type slave;는 "examp.co.kr." 도메인이 Slave 존(zone) 임을 표시합니다.
Slave 존인 경우, 존 파일(zone file)을 작성하지 않으며, Master 네임서버로부터 도메인 존
데이터를 전송받아 도메인의 DNS 서비스를 제공합니다.
masters { 192.0.2.10; };는 이 examp.co.kr. 도메인의 Master 네임서버 IP 주소를 지정하는
옵션입니다.
IPv6 주소의 존 전송(zone transfer) 설정
아래의 사례를 기준으로 설정방법을 설명합니다.
"examp.co.kr" 도메인 존(zone)
$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 2001:cd5:20a::c000:20ans2.examp.co.kr.         86400  IN  AAAA 2001:cd5:30a::c000:30a
사례의 "examp.co.kr." 도메인은 "ns1.examp.co.kr." 네임서버와 "ns2.examp.co.kr." 네임서버를
가지고 있습니다.
이 경우, Master 네임서버는 도메인의 SOA RR의 MNAME 필드에 지정된 "ns1.examp.co.kr."
입니다.
Ref Docs:RFC1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"
                  3.3.13. SOA RDATA format
Ref Docs:RFC2181 "Clarifications to the DNS Specification"
                  7.3. The SOA.MNAME field 
"ns1.examp.co.kr."은 도메인 존 파일에 A RR과 AAAA RR을 동시에 갖는 IPv4/IPv6 듀얼스택
네임서버로 지정되어 있습니다.
SOA RR의 MNAME 필드에 명시되지 않은 나머지 모든 네임서버는 Slave 네임서버입니다.
"ns2.examp.co.kr."는 Slave 네임서버로써 AAAA RR만 지정된 IPv6 only 네임서버입니다.
네임서버IP 주소비고
ns1.examp.co.kr.192.0.2.10
2001:dc5:20a::c000:20a
Master 네임서버 (IPv4/IPv6)
ns2.examp.co.kr.2001:dc5:30a::c000:30aSlave 네임서버 (IPv6 only)
아래는 IPv6 DNS Slave 네임서버(ns2.examp.co.kr.)에서 IPv6 주소를 사용한 존 전송을 지정하는
내용입니다.
Slave 네임서버 "named.conf" 파일의 "examp.co.kr." 존 설정 부분 (BIND 8/9 공통)
zone    "examp.co.kr." {          type slave;         masters { 2001:dc5:20a::c000:20a; }; };
이로써 examp.co.kr.의 Slave 네임서버는 "2001:dc5:20a::c000:20a"에 대해 존 전송요청을 하게
됩니다.
Master/Slave 네임서버에서의 존 전송(zone transfer) 요청가능 발신 IP 제한 설정
존 전송(zone transfer) 요청에 의해 지정된 도메인 존 내부의 모든 리소스레코드 데이터를
존 전송(zone transfer)를 요청한 네임서버로 일괄 전송합니다.
만일 임의의 호스트에 대해 존 전송(zone transfer) 요청을 허용하는 경우, 도메인 내용이 모두
외부에 노출될 수 있습니다.
존 전송(zone transfer)는 네임서버만 요청할 수 있는 것이 아니라 임의의 단말 호스트에서도
요청할 수 있기 때문입니다.
존 전송(zone transfer)는 아래와 같은 내용의 일반적인 DNS 질의 형태로 이루어집니다.
AXFR(transfer of an entire zone) 타입 DNS 질의
QNameexamp.co.kr.
QTypeAXFR
QClassIN
BIND DNS의 dig 유틸리티를 사용한 다음과 같은 명령은 AXFR DNS 질의를 발생합니다.
dig@ns1.examp.co.kr.examp.co.kr. AXFR
이렇게 외부에 도메인 존 내용이 모두 노출되는 것을 방지하기 위해 존 전송(zone transfer)
요청을 할 수 있는 호스트를 제한 설정합니다.
아래의 사례는 도메인 존 단위로 존 전송 요청 제한을 설정하는 경우를 보입니다.
Master 네임서버 "named.conf" 파일의 "examp.co.kr." 존 설정 부분
zone    "examp.co.kr." {          type master;        file "examp.co.kr.zone";        allow-transfer { 2001:dc5:30a::c000:30a; }; };
Slave 네임서버 "named.conf" 파일의 "examp.co.kr." 존 설정 부분
zone    "examp.co.kr." {          type slave;         masters { 2001:dc5:20a::c000:20a; };         transfer-source-v6 { 2001:dc5:30a::c000:30a; };         allow-transfer { none; };};
이 경우, 주의할 사항은 Slave 네임서버의 examp.co.kr. 존 설정 부분에transfer-source-v6
옵션을 사용한 점입니다.
transfer-source-v6옵션은 Slave 네임서버가 Master 네임서버로 존 전송(zone transfer)
요청시 자신의 IPv6 주소 중 "2001:dc5:30a::c000:30a"를 source IPv6 주소로 사용하도록
명시하는 용도로 사용됩니다.
이것은 Master 네임서버의allow-transfer { 2001:dc5:30a::c000:30a; };설정과 관련되어
있습니다.
IPv6 환경에서는 다양한 IPv6 주소가 인터페이스에 함께 설정될 수 있으므로 이와 같이
명시적으로 설정을 함으로써 Master 네임서버에 접근할 때 허용된 IPv6 주소를 source 주소로
고정적으로 사용하도록 제어 할 수 있습니다.
Slave 네임서버의 경우에 존 전송(zone transfer) 요청을 어떤 호스트에게도 허용하지 않는
설정을  allow-transfer { none; };을 사용하여 적용하고 있습니다.
 
  Comments,     Trackbacks
루프백 주소의 역변환 도메인 존 파일 내용은 어떻게 작성
IPv4 루프백 주소 127.0.0.1 에 대한 설정
IPv4에서는 루프백(loopback) 주소가 127.0.0.0/8 주소블럭에 속한 127.0.0.1입니다.
NOTE!: IPv4 루프백 주소
IPv4 프로토콜의 원래 정의에는 루프백 주소가 존재하지 않음
후에 BSD Unix에서 루프백 주소로 127.0.0.1을 사용하기 시작하면서 루프백 주소 개념 발생
127.0.0.0/8은 A Class 주소에 속하므로 당시 Class 개념에 따라 127.0.0.0/8 A Class가 전체
루프백 주소 블록으로 예약됨.

IPv4의 DNS 네임서버에서 IPv4 루프백 주소에 대한 역변환 도메인(reverse domain)을 기본적으로
설정합니다.
127.0.0.1 주소는 127.0.0.0/8 주소블럭 전체에 대한 역변환 도메인을 설정하고, 그 안에
127.0.0.1 주소에 대한 설정을 하는 방식을 사용합니다.
원칙적으로 127.0.0.0/8에 대한 역변환 도메인을 설정하는 것이 정확합니다.
이 경우, "127.in-addr.arpa." 도메인을 아래와 같이 설정합니다.
"named.conf" 파일의 "127.in-addr.arpa." 존 설정 부분
zone "127.in-addr.arpa" {          type master;         file "named.ipv4.local"; };
"127.in-addr.arpa." 도메인 존 파일
$ORIGIN 127.in-addr.arpa.$TTL 1D@       86400   IN  SOA localhost. adm.localhost. (                        2001061401 ; serial                        28800      ; refresh (8 hours)                        7200       ; retry (2 hours)                        604800     ; expire (1 week)                        86400      ; minimum (1 day)                        )                IN  NS  localhost.                           1.0.0           IN  PTR localhost.
그러나 127.0.0.0/8 주소블럭 중 실제로 사용되고 있는 주소는 127.0.0.1이 유일한 주소이므로
편의상 "0.0.127.in-addr.arpa." 도메인, 또는 "1.0.0.127.in-addr.arpa." 도메인을 설정하는 것이
일반적입니다.
아래는 "0.0.127.in-addr.arpa." 도메인으로 설정한 경우입니다.
"named.conf" 파일의 "0.0.127.in-addr.arpa." 존 설정 부분
zone "0.0.127.in-addr.arpa" {          type master;         file "named.ipv4.local"; };
"0.0.127.in-addr.arpa." 도메인 존 파일
$ORIGIN 0.0.127.in-addr.arpa.$TTL 1D@       86400   IN  SOA localhost. adm.localhost. (                        2001061401 ; serial                        28800      ; refresh (8 hours)                        7200       ; retry (2 hours)                        604800     ; expire (1 week)                        86400      ; minimum (1 day)                        )                IN  NS  localhost.1               IN  PTR localhost.
"1.0.0.127.in-addr.arpa."에 대한 도메인 네임을 "localhost."로 지정합니다.
IPv6 루프백 주소 ::1 에 대한 설정
IPv6 주소체계에서는 루프백(loopback) 주소를 IPv6 프로토콜 규격에서 명시적으로
정의하였습니다.
IPv6에서 루프백(loopback) 주소는 ::1/128입니다.
여기에서 '/128'은 주소 블록이 아닌 ::1(0000:0000:0000:0000:0000:0000:0000:0001) 주소
하나만을 루프백(loopback) 주소로 정의한 것을 의미합니다.
이에 따라 IPv6 루프백 주소 "::1"에 대한 역변환용 도메인은 "::1/128"로 정의한 규정에
적합하게 아래와 같이 설정하는 것이 바람직합니다.
"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."
"named.conf" 파일의 "0.0.127.in-addr.arpa." 존 설정 부분
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." {          type master;         file "named.ipv6.local"; };
"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." 도메인 존 파일
$ORIGIN 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.$TTL 1D@       86400   IN  SOA localhost. adm.localhost. (                        2001061401 ; serial                        28800      ; refresh (8 hours)                        7200       ; retry (2 hours)                        604800     ; expire (1 week)                        86400      ; minimum (1 day)                        )                IN  NS  localhost.                IN  PTR localhost.

NOTE!:"::2", "::3" 등은 루프백 주소에 포함되지 않음
IPv6의 루프백 주소는 "::1"에 한정 정의
"::2", "::3" 등등은 루프백 주소와 관련이 없음
따라서 "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"의 IPv6 주소블럭에 대한 설정이 되므로 "::2", "::3" 등의 주소까지
포괄하는 역변환 도메인을 설정하는 결과가 되어버림

"localhost." 도메인 존 설정

루프백 주소와 관련하여 "localhost." 존(zone)을 네임서버마다 기본적으로 설정하는 것이
필요합니다.

IPv4 환경에서 "localhost."는 아래와 같은 기본적인 내용으로 작성되고 있었습니다.

"named.conf" 파일의 "localhost." 존 설정 부분
zone    "localhost" {          type master;         file "localhost"; };
"localhost." 도메인 존 파일
$ORIGIN localhost.$TTL 1D@       86400   IN  SOA     localhost. adm.localhost. (                            2001061401 ; serial                            28800      ; refresh (8 hours)                            7200       ; retry (2 hours)                            604800     ; expire (1 week)                            86400      ; minimum (1 day)                            )                IN  NS      localhost.                IN  A       127.0.0.1

IPv6 환경에서는 "localhost." 도메인 존 파일을 아래와 같이 AAAA RR을 추가하여 작성합니다.

"localhost." 도메인 존 파일
$ORIGIN localhost.$TTL 1D@       86400   IN  SOA     localhost. adm.localhost. (                            2001061401 ; serial                            28800      ; refresh (8 hours)                            7200       ; retry (2 hours)                            604800     ; expire (1 week)                            86400      ; minimum (1 day)                            )                IN  NS      localhost.                IN  A       127.0.0.1                IN  AAAA    ::1

 

  Comments,     Trackbacks
"localhost." 존은 설정해야 하나요? DNSv6에서는 어떻게 설정하나요?
"localhost"는 모든 호스트에 존재하는 루프백 주소 또는 루프백 인터페이스 네임입니다.
"localhost"에 대응하는 IPv4 주소는 "127.0.0.1"입니다.
IPv6에서는 루프백 주소로 "::1"을 사용합니다.
IPv6가 도입되면서 자연히 "localhost" 네임도 IPv4 루프백 주소 "127.0.0.1"에 추가하여
IPv6 루프백 주소 "::1"을 동시에 가지게 됩니다.
모든 네임서버에는 이 루프백 주소에 해당하는 도메인 "localhost."을 설정할 것을 권고하고
있습니다.
정상적인 경우에 "localhost"의 해당 IP 주소를 파악하는 절차가 시스템 내부에서 처리되지만
일부의 경우, "localhost."의 A 타입 RR 또는 AAAA 타입 RR 정보를 요청하는 DNS 질의가
발생합니다.
"localhost." 도메인 존이 로컬 네임서버에 설정되어 있지 않은 경우, "localhost."에 대한
IP 주소 DNS 질의는 루트 네임서버로 집중됩니다.
이에 따라 "localhost."에 대한 도메인 존 설정을 모든 로컬 네임서버에 설정하기를 권고하고
있습니다.
"localhost." 도메인 존 설정
루프백 주소와 관련하여 "localhost." 존(zone)을 네임서버마다 기본적으로  설정하는 것이
필요합니다.
IPv4 환경에서 "localhost."는 아래와 같은 기본적인 내용으로 작성되고 있었습니다.
"named.conf" 파일의 "localhost." 존 설정 부분
zone    "localhost" {          type master;         file "localhost"; };
"localhost." 도메인 존 파일
$ORIGIN .$TTL 1Dlocalhost    86400   IN  SOA     localhost. adm.localhost. (                                 2001061401 ; serial                                 28800      ; refresh (8 hours)                                 7200       ; retry (2 hours)                                 604800     ; expire (1 week)                                 86400      ; minimum (1 day)                                 )                     IN  NS      localhost.                           IN  A       127.0.0.1
IPv6 환경에서는 "localhost." 도메인 존 파일을 아래와 같이 AAAA RR을 추가하여 작성합니다.
"localhost." 도메인 존 파일
$ORIGIN .$TTL 1Dlocalhost    86400   IN  SOA     localhost. adm.localhost. (                                 2001061401 ; serial                                 28800      ; refresh (8 hours)                                 7200       ; retry (2 hours)                                 604800     ; expire (1 week)                                 86400      ; minimum (1 day)                                 )                     IN  NS      localhost.                           IN  A       127.0.0.1                     IN  AAAA    ::1
 
  Comments,     Trackbacks
IPv6 DNS에서 존 파일(Zone File) 내용은 어떤 것이 달라지나요?
DNSv6의 도메인 존 파일(Zone File)은 아래와 같은 사항들이 추가 됩니다.

항목

비고

AAAA RR 추가

AAAA RR에 대한 지정

IP6.ARPA 도메인 존 추가설정

IPv6 주소에 대한 역변환 도메인(reverse domain) 지정

아래는 일반적인 도메인 존 파일(Zone File) 설정 예시입니다.
"examp.co.kr" 도메인
$ORIGIN  examp.co.kr.       @           3600 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)                        )            3600 IN NS      ns2.examp.co.kr.            3600 IN NS      ns1.examp.co.kr.            3600 IN MX      10 mail.examp.co.kr.            3600 IN MX      20 smtp.examp.co.kr.     ns1         3600 IN A       192.0.2.10ns1         3600 IN AAAA    2001:dc5:f2::10ns2         3600 IN A       192.0.3.10ns2         3600 IN AAAA    2001:dc5:f3::10    mail        3600 IN A       192.0.2.40mail        3600 IN AAAA    2001:dc5:f2::40smtp        3600 IN A       192.0.3.40smtp        3600 IN AAAA    2001:dc5:f3::40    www         600  IN A       192.0.2.100www         600  IN A       192.0.2.101www         600  IN A       192.0.2.102www         600  IN AAAA    2001:dc5:f2::100www         600  IN AAAA    2001:dc5:f2::101www         600  IN AAAA    2001:dc5:f2::102
위에서와 같이 일반 도메인의 존 파일에서 IPv6 관련하여 변경되는 부분은 AAAA RR에 대한
추가 설정 사항만 해당합니다.
위의 경우, examp.co.kr. 사이트는 2001:dc5::/32의 IPv6 주소 블록을 할당받았다고 가정할 때,
이 사이트의 네임서버는 APNIC으로부터 2001:dc5::/32에 대한 IPv6 주소 역변환 도메인을
위임받아 설정하게 됩니다.
아래는 이 경우 IPv6 주소의 역변환 도메인(reverse domain)의 예시입니다.
2001:dc5::/32의 역변환 도메인, "5.c.d.0.1.0.0.2.ip6.arpa."
$ORIGIN 5.c.d.0.1.0.0.2.ip6.arpa.       @               172800 IN SOA ns1.examp.co.kr. adm.examp.co.kr. (                              2004012201 ; serial                              7200       ; refresh (2 hours)                              1800       ; retry (30 minutes)                              604800     ; expire (1 week)                              172800     ; minimum (2 days)                              )                172800 IN NS ns1.examp.co.kr.                172800 IN NS ns2.examp.co.kr.    $ORIGIN 2.f.0.0.5.c.d.0.1.0.0.2.ip6.arpa.    0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 3600 IN PTR ns1.examp.co.kr.0.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 3600 IN PTR mail.examp.co.kr.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 3600 IN PTR www.examp.co.kr.1.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 3600 IN PTR www.examp.co.kr.2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 3600 IN PTR www.examp.co.kr.    $ORIGIN 3.f.0.0.5.c.d.0.1.0.0.2.ip6.arpa.    0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 3600 IN PTR ns2.examp.co.kr.0.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 3600 IN PTR smtp.examp.co.kr.
 
  Comments,     Trackbacks
Master와 Slave 네임서버로 구성할 때, 모두 IPv6 주소로 구성해야 하나요
모든 네임서버를 IPv6 주소로 구성해야 한다는 제한은 없습니다.
일부 네임서버만 IPv6 주소로 구성할 수도 있습니다.
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 네임서버Slave 네임서버비고
IPv4 onlyIPv4/IPv6구성에 문제없음
IPv4 onlyIPv6 only구성 불가
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 네임서버Slave 네임서버비고
IPv4/IPv6IPv4/IPv6구성에 문제없음
IPv4/IPv6IPv4 only구성에 문제없음
IPv4/IPv6IPv6 only구성에 문제없음

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

Master 네임서버가 IPv6 only 네임서버인 경우
Master 네임서버Slave 네임서버비고
IPv6 onlyIPv4/IPv6구성에 문제없음
IPv6 onlyIPv4 only구성 불가
IPv6 onlyIPv6 only구성에 문제없음
IPv4 리졸버의 리졸루션 불능

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 인터넷으로 전환 완료된 시점에 적용할 수 있는
방안입니다.

 

  Comments,     Trackbacks
Windows PC에서 BIND DNS의 dig과 같은 유틸리티를 사용하는 방법
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

; <<>> DiG 9.2.3 <<>> -n -x 2001:200:0:8002:203:47ff:fea5:3085
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0  

;; QUESTION SECTION:
;5.8.0.3.5.a.e.f.f.f.7.4.3.0.2.0.2.0.0.8.0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa. IN PTR  

;; ANSWER SECTION:
5.8.0.3.5.a.e.f.f.f.7.4.3.0.2.0.2.0.0.8.0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa. 86400 IN PTR orange.kame.net.

;; AUTHORITY SECTION:
2.0.0.8.0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa. 86400 IN NS orange.kame.net.
2.0.0.8.0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa. 86400 IN NS paradise.kame.net.  

;; Query time: 701 msec
;; SERVER: 202.31.190.222#53( 202.31.190.222)
;; WHEN: Sat Jun 19 18:33:31 2004
;; MSG SIZE  rcvd: 156


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

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

파일구분파일리스트
실행 파일host.exe
dig.exe
nslookup.exe
nsupdate.exe
dnssec-signkey.exe
dnssec-signzone.exe
dnssec-keygen.exe
dnssec-makekeyset.exe
named-checkconf.exe
named-checkzone.exe
rndc.exe
rndc-confgen.exe
DLL 파일libisc.dll
msvcr70.dl
llibdns.dll
libeay32.dll
libisccc.dll
libisccfg.dll
liblwres.dll
mfc70.dll
bindevt.dll


 

위의 경우는 네임서버 프로그램을 제외한 모든 점검 유틸리티 및 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

  Comments,     Trackbacks
DNSv6 구성에서 BIND DNS의 named.conf 파일은 어떻게 작성해야 하나요?
BIND 네임서버의 환경구성 파일(configuration file)은 named.conf 파일입니다.
BIND 네임서버 데몬 프로세스인 named는 디폴트 동작으로 /etc/named.conf 파일을
그 환경구성 파일로 사용합니다.
named.conf 파일의 설정 옵션은 상당히 많습니다.
여기서는 BIND 8버전과 BIND 9버전에 공통되는 가장 기본적인 설정 사항을 제시합니다.
Ref Docs:
BIND 8 과 BIND 9 매뉴얼은 배포 소스 패키지에 포함 또는ISC의 BIND 페이지에서 제공
named.conf 파일은 아래와 같은 내용의 기본적인 설정사항을 포함하여 구성합니다.
no.named.conf 내용
1options {
            directory "/dns1";
            pid-file "/var/adm/named.pid";
            listen-on-v6 { any; }
            allow-transfer {
                    192.0.2.1;
                    192.0.2.100; };
};
2zone "localhost" {
        type master;
        file "localhost";
};
3zone "." {
        type hint;
        file "root.cache";
};
4zone "0.0.127.in-addr.arpa" {
        type master;
        file "named.ipv4.local";
};
5zone "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." {
        type master;
        file "named.ipv6.local";
};

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 masterfile "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 masterfile "named.ipv6.local"지정
  Comments,     Trackbacks
Windows OS가 설치된 PC나 서버에도 BIND DNS를 설치할 수 있나요?
설치할 수 있습니다.
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 스택을 지원하여 정상적으로 동작합니다.
 
  Comments,     Trackbacks
IPv6를 지원하는 BIND DNS SW를 어디서 얻을 수 있나요?
BIND DNS SW는 ISC(Internet Systems Consortium)에서 배포하고 있습니다.

웹 접속을 통한 다운로드 경우


ISC 사이트 :http://www.isc.org


ISC 홈 페이지 > SOFTWARE > BIND 메뉴를 선택하면 BIND 버전별 SW 배포 페이지로 링크된 항목을
찾을 수 있습니다.

FTP로 직접 접속 후 다운로드 경우


ISC의 아래 FTP 사이트는 각 버전별로 DNS SW를 제공합니다.
OS비고
ISC FTP 사이트ftp://ftp.isc.org/isc/
BIND 8ftp://ftp.isc.org/isc/bind/
BIND 9ftp://ftp.isc.org/isc/bind9/
Windows 용 설치 패키지ftp://ftp.isc.org/isc/bind/contrib/
 
  Comments,     Trackbacks
BIND DNS SW를 다운받았는데 컴파일은 어떻게 하고, 설치는 어떻게 하나요?
BIND DNS를 설치할 플랫폼이 무엇인가에 따라 구분할 수 있습니다.



Microsoft Windows 계열 플랫폼에 설치하는 경우
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 버전 계열:
1make depend
2make all
3make install
'make install'의 경우에는 root 권한으로 실행해야 합니다.시스템의 각 디렉토리에 파일을 복사 설치하는 과정이기 때문입니다.'make install' 절차는 아래와 같은 주요 디폴트 디렉토리에 BIND DNS 파일을 설치합니다.
디렉토리설치 파일
/usr/local/bindig, nslookup, nsupdate 등 점검 도구
/usr/local/sbinDNS 네임서버 데몬인 named이외 네임서버 관리 도구들
/usr/local/libLibrary 파일들
/usr/local/man매뉴얼 페이지 파일들
BIND 9 버전 계열:
1./configure
2make
3make install
./configure는 시스템 환경을 자동으로 체크하여 컴파일 및 설치용 환경설정을 수행하는 과정입니다.'make install'의 경우에는 root 권한으로 실행해야 합니다.시스템의 각 디렉토리에 파일을 복사 설치하는 과정이기 때문입니다.'make install' 절차는 아래와 같은 주요 디폴트 디렉토리에 BIND DNS 파일을 설치합니다.
디렉토리설치 파일
/usr/local/bindig, nslookup, nsupdate 등 점검 도구
/usr/local/sbinDNS 네임서버 데몬인 named이외 네임서버 관리 도구들
/usr/local/libLibrary 파일들
/usr/local/man매뉴얼 페이지 파일들
Unix 및 Linux 플랫폼 기반 네임서버의 안정적 구동을 위한 시스템 환경 구성
이로써 BIND DNS 네임서버 소스의 컴파일과 설치 과정이 완료되었습니다.이후의 과정은 각 시스템 별로 네임서버가 안정적으로 구동될 수 있는 시스템 환경을 구성하는 작업이 이어집니다.이 과정은 각 시스템 플랫폼별로 상이하므로 각 시스템 환경에 맞는 절차를 수행해야 합니다.여기에서는 일반 Unix 및 Linux 플랫폼에 공통적인 사항만 간략히 제시합니다.
작업사항요약
부팅 스크립트 설정시스템 부팅시, 네임서버의 자동실행 설정
시스템 부팅 절차 스크립트에서 네임서버 구동 설정
주로 /etc/init.d에 스크립트 작성,
/etc/rc3.d 디렉토리에 스크립트의 심볼릭 링크 설정
디폴트 네임서버 설정 제거OS에 함께 포함되어 설치된 BIND 네임서버가 존재
부팅 스크립트에서 삭제
현재 구동되고 있는 DNS 프로세스의 중단
/etc/named.confBIND DNS 네임서버의 디폴트 configuration 파일 점검
파일 부재시 파일 생성
DNS zone 파일 디렉토리 설정DNS 네임서버의 도메인 존(zone) 파일 저장 디렉토리
특정 디렉토리 선정 및 디렉토리 생성
해당 디렉토리의 접근 권한 조정 (보안 관련)
디폴트 디렉토리는 /var/named 
 
  Comments,     Trackbacks
BIND DNS는 버전이 여러 개 있는데, IPv6를 지원하는 버전은 어느 것이죠?
현재 BIND DNS는 크게 2가지 버전 군으로 제공되고 있습니다.
버전 군IPv6 지원 버전비고
BIND 8BIND 8.4.0 이상최근 버전 : BIND 8.4.4
BIND 9BIND 9.0.0 이상최근 버전 : BIND 9.2.3
※ BIND 4 버전은 현재 개발과 공식적 배포가 중단된 상태
이 중에서 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에 비해 보다 향상된 시스템 구조를 지니고 있다는 점을 지적할 수 있습니다.
  Comments,     Trackbacks
DNSv6 네임서버용 SW에는 어떤 것이 있나요?

IPv6를 지원하는 DNS 서버 SW는 현 시점을 기준하여 아래와 같은 SW가 있는 것으로 파악되고 있습니다.
 
DNS SW배포처 또는 제작사비고
BIND DNSISCUNIX, Linux, Windows 계열 OS 지원
BIND 버전 9계열은 모두 IPv6를 지원
BIND 버전 8의 경우, 8.4.0 이상
Microsoft's
DNS server
MicrosoftWindows 2003 서버의 DNS가 IPv6 지원
Microsoft Windows OS에 포함
※ ISC (Internet Systems Consortium) :http://www.isc.org※ DNSv6 서버 SW 기준: 아래의 조건을 모두 충족하는 DNS 서버를 기준함
1. DNS 네임서버로서 IPv6 패킷을 사용한 DNS 질의의 처리여부와 AAAA RR(리소스레코드) 등
IPv6를 위한 DNS 확장 기능의 구현
2. IPv6 패킷의 DNS 질의 및 응답 처리 구현 (IPv6 인터페이스 및 네트워크 환경 지원)
기타 DNS SW
IPv4 환경을 지원하는 DNS SW는 위의 BIND DNS 및 Microsoft 사의 DNS 서버 외에 존재합니다.그러나 많이 사용되지는 않고 있으며, 주로 사용되는 것은 위의 BIND DNS와 Microsoft 사의 DNS 서버입니다.
특히 BIND의 경우는 Unix 계열 호스트 및 Linux, Windows 계열 호스트 모두를 지원하는 Freeware SW로서 가장 광범위하게 사용되고 있습니다.
Microsoft의 DNS 서버는 Microsoft의 Windows OS에 기본 서버 기능으로 포함되어 있으며, 주로 서버용 OS에 포함되어 있습니다.
  Comments,     Trackbacks
DNSv6 네임서버 시스템은 어떤 HW 시스템을 사용해야 하나요?
 

DNSv6 네임서버는 IPv6를 지원하기 위해 구성하므로, 설치하는 플랫폼이 IPv6를 지원해야 할 것입니다.
IPv6는 HW 차원에서 지원하는 것이 아니라 OS 차원에서 지원합니다.IPv6를 지원하는 플랫폼이라고 할 때, HW가 IPv6를 지원하도록 설계된 특수한 서버 장비등을 연상할 수 있습니다.
그러나 IPv6를 지원하기 위한 IPv6 프로토콜 스택(stack)은 OS에 포함되는 SW 요소입니다.따라서 IPv6 지원 여부는 플랫폼에 설치되는 OS가 IPv6를 지원하는 OS 여부에 의해 결정됩니다.
현재 많이 사용되고 있는 OS를 중심으로 보면, 현 시점을 기준으로 아래와 같은 OS들이 IPv6 지원을 하고 있는 것으로 알려져 있습니다.
 
OS비고
Linux Kernel 2.2.x 이상IPv6 enable 옵션으로 컴파일된 kernel이 IPv6 지원
근래 출시되는 최근 Linux 버전은 모두 IPv6 지원
Solaris 5.8 이상Solaris 5.8 이상에서 IPv6 지원
HP-UX 11iHP-UX 11i 버전에서 IPv6 지원
Windows XP/ 2003 서버Windows XP 이상, Windows 2003 서버에서 IPv6 지원
Windows 2000에서는 IPv6 지원 서비스 팩 설치 필요
이외에 언급되지 않은 OS들에서도 IPv6 지원이 가능합니다. 해당 OS의 제품 사양서에서 IPv6 지원 여부를 확인하시면 됩니다. IPv6 지원여부는 OS에 따라 결정되므로, 기존 호스트의 OS를 변경 설치함으로써 IPv6 지원 플랫폼을 구성할 수 있습니다


 
  Comments,     Trackbacks
DNSv6에서의 도메인 위임설정은 달라지나요?
도메인 네임서버의 IPv6 주소 설정 및 위임 설정
DNS는 분산구조형 데이터베이스입니다.
분산구조형 데이터베이스라는 것은 특정한 한 기관에서 모든 도메인 정보를 관리하지 않고
전세계에 걸쳐 분산되어 분산관리되고 있는 체계를 지칭합니다.
도메인 등록을 함으로써 그 도메인 네임 영역(zone)에 대해서는 등록자가 데이터 설정,
수정, 삭제 권한을 전적으로 가지는 것은 DNS가 분산구조형 데이터베이스이기에 그렇습니다.
도메인 위임설정은 분산구조형 데이터베이스 구조에서 특정한 도메인네임에 대한 정보를
가진 네임서버가 인터넷의 어느 주소로 존재하는지를 알려주는 정보를 지정합니다.
일반적인 도메인 위임설정은 아래의 예시와 같이 설정됩니다.
도메인 존(zone)의 "examp.co.kr."에 대한 위임설정
$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
"examp.co.kr" 도메인 존(zone)
$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의 경우에는 아래와 같은 형식으로 위임이 설정됩니다.
"co.kr" 도메인 존(zone)의 "examp.co.kr."에 대한 위임설정
$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
"examp.co.kr" 도메인 존(zone)
$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 위임설정을 개시할
예정입니다.

 
  Comments,     Trackbacks
IPv6 어플리케이션은 어떻게 IP 주소를 파악하게 되나요?
어플리케이션의 IP 주소 리졸루션 일반적 절차
응용 어플리케이션 프로그램에서는 사용자가 입력한 도메인네임을 우선 IP 주소로 변환하는
절차를 거쳐야 합니다.
인터넷 통신을 위해서는 시스템이 제공하는 Socket API를 사용해야 하는데,
Socket API는 도메인네임을 인식할 수 없기 때문입니다.
그래서 먼저 도메인네임 -> IP 주소로 변환하는 절차를 먼저 수행하여 IP 주소를 파악한 후,
Socket API로 IP 주소를 사용한 접속 절차를 개시할 수 있습니다.
IPv4 DNS 환경에서 IP 주소 변환을 위한 함수 gethostbyname()
IPv4 인터넷 환경에서는 이 도메인네임 -> IP 주소 변환을 위해 gethostbyname()을
호출합니다.
gethostbyname() 함수
struct hostent *gethostbyname(const char *);
gethostbyname()은 도메인네임을 인자로 하여 호출하면 IPv4 주소를 hostent 구조체로
반환합니다.
IPv6 DNS 환경에서 IP 주소 변환을 위한 함수 getaddrinfo()
IPv6에서는 이 함수외에 새로운 함수를 새로 정의하였습니다.
getaddrinfo() 함수는 IPv6 환경에서 도메인네임에 대한 IPv4 주소와 IPv6 주소를 파악하여
반환하는 기능을 제공합니다.
getaddrinfo() 함수
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 질의 수행 
 
  Comments,     Trackbacks
IPv6 어플리케이션은 IPv4와 IPv6 주소 중에서 어느 것으로 접속을 하나요?

도메인네임이 IPv4 주소(A RR)와 IPv6 주소(AAAA RR)를 모두 갖고 있는 경우
IPv4 인터넷에서는 도메인 네임이 갖는 IP 주소는 IPv4 주소 한 종류 뿐이었습니다.
그러나 이제 IPv6 인터넷이 도입되면서, 하나의 도메인네임이 IPv4 주소와 IPv6 주소 모두를
갖는 경우가 발생하게 됩니다.
예를 들어 아래와 같은 경우,
"examp.co.kr" 도메인 설정 내용
ftp.examp.co.kr.  1800  IN  A    192.0.2.200ftp.examp.co.kr.  1800  IN  AAAA 2001:dc5:f::200
단말 호스트의 IPv6 어플리케이션은 getaddrinfo() 함수 호출의 결과로ftp.examp.co.kr.
도메인네임에 대해 "192.0.2.200" IPv4 주소와 "2001:dc5:f::200"의 2개 주소를 얻게 됩니다.
이 경우, 어플리케이션은 "이 2개의 주소 중 어느 주소를 선택하여 접속을 시도해야 하는가?"
하는 문제가 발생하게 됩니다.
물론 이것은 원칙적으로 어플리케이션을 작성하는 개발자의 선택에 따라 결정될 것입니다.
어플리케이션이 getaddrinfo() 함수로부터 얻은 IP 주소 중 하나를 다시 Socket API에 인자로
전달함으로써 통신이 개시될 수 있기 때문입니다.
이 동작은 프로그래머가 정하여 프로그램 코드를 작성할 수 있습니다.
디폴트 IP 주소 선택 알고리듬 (Default Address Selection)
IETF RFC3484 문서는 이 문제를 다루고 있습니다.
Ref Docs:RFC3484 "Default Address Selection for Internet Protocol version 6 (IPv6)"
일반적으로 어플리케이션은 도메인네임의 IP 주소 변환 함수 gethostbyname() 이나
getaddrinfo()가 리턴하는 IP 주소 목록에서 첫 번째 IP 주소를 선택하여 이 IP 주소로
Socket을 열고 통신을 개시합니다.
이러한 일반 사항을 기반으로 RFC3484는 getaddrinfo() 함수가 도메인네임의 IPv4 주소와
IPv6 주소를 함께 파악한 경우, 일정한 디폴트 알고리듬을 적용하여 어플리케이션으로
리턴하는 IP 주소 목록을 정렬(sort)하여 반환하는 동작을 정의합니다.
getaddrinfo() 함수는 일정한 규칙으로 IP 주소 목록을 반환하여 어플리케이션이
접속 시도하는 IP 주소를 일정하게 제어하는 역할을 하게 됩니다.
접속대상 주소 선택 알고리듬에 사용되는 디폴트 정책 테이블(default poliy table)은
아래와 같습니다.

Prefix

Precedence

Label

비고

::1/128

50

0

IPv6 LoopBack 주소

::/0

40

1

이외의 모든 IPv6 주소

2002::/16

30

2

6to4 IPv6 주소

::/96

20

3

IPv4-compatible IPv6 주소

::ffff:0:0/96

10

4

IPv4-mapped IPv6 주소
IPv4 주소를 의미
Source:RFC3484 "Default Address Selection for Internet Protocol version 6 (IPv6)"
2.1. Policy Table
이 주소 선택 알고리듬의 개략적인 내용은 아래와 같이 정리할 수 있습니다.
1. IPv4 주소와 IPv6 주소가 함께 리스트에 있는 경우, IPv6 주소가 디폴트로 리스트 중
첫 번째 IP 주소로 리턴됩니다.
IPv4 주소(::ffff:0:0/96) 보다 IPv6 주소(::1/128, ::/0, 2002::/16, ::/96)들이
Precedence에서 모두 우선순위가 높습니다.
이에 따라 IPv6 어플리케이션이 getaddrinfo() 함수로부터 반환받는 IP 주소 리스트에
IPv4와 IPv6가 혼재하는 경우, 디폴트 동작으로 그 첫 번째 IP 주소는
IPv6 주소가 됩니다.
결과적으로 IPv6 어플리케이션은 IPv4와 IPv6 주소 모두 가진 도메인네임에 대해서는
IPv6를 먼저 접속 시도 주소로 선택하는 동작을 하게 됩니다.
2. IPv6 주소가 다수 존재하는 경우, IPv6 루프백(loopback) 주소, 일반적인 IPv6 주소,
6to4 IPv6 주소, IPv4-compatible IPv6 주소의 순으로 정렬(sort)하여 리턴합니다.
IPv6 주소 "2001:dc5:f::200"와 IPv6 주소 "2002:c000:02c8::c000:02c8"가 도메인네임에
함께 지정되어 있는 경우, APNIC을 통해 할당된 native IPv6 주소 "2001:dc5:f::200"가
6to4 tunnelling 방식의 자동생성된 6to4 IPv6 주소 "2002:c000:02c8::c000:02c8"보다
우선하게 됩니다.
곧 어플리케이션은 native IPv6 주소와 6to4 IPv6 주소가 있는 경우, native IPv6 주소로
먼저 접속시도하게 됩니다.
NOTE!: DNS의 IPv6 주소 설정오류가 야기하는 어플리케이션의 접속 시간 지연 문제
일반적으로 어플리케이션은 getaddrinfo() 등의 함수로부터 리턴받은 IP 주소 목록 중
첫 번째 IP 주소로 접속을 시도한 후 접속에 실패하면 다음의 IP 주소를 사용하여 접속을
시도합니다.
따라서 IPv4와 IPv6 주소가 하나씩 있는 경우, IPv6 주소로 먼저 접속을 시도하고, 이에
실패하게 되면, IPv4 주소로 접속을 시도합니다.
만일 DNS의 특정 도메인네임에 존재하지 않는 IPv6 주소가 설정되어 있는 경우,
어플리케이션에서는 접속시도와 그 timeout에 따르는 시간지연이 발생한 후 IPv4 주소로
접속이 성공함으로써, 사용자는 접속이 느린 현상을 경험하게 됩니다.
위에서 정리된 디폴트 주소 선택 알고리듬 내용은 개략적인 것으로 이외에 시스템 환경조건에
의한 주소 선택 및 정렬 알고리듬을 RFC3484 문서에서 정의하고 있습니다.
주의할 점은 RFC3484에서 정의한 주소선택 알고리듬은 디폴트 알고리듬일 뿐이며
어플리케이션에서 별도의 선택 알고리듬을 사용하여 특정한 주소 선택을 하거나,
디폴트 주소 선택 정책 테이블의 내용을 변경하는 경우, 선택 방식이 변경될 수 있다는
사실입니다.
Windows 2003 서버의 경우, 아래와 같이 default policy table 내용을 볼 수 있으며,
이 테이블에서 각 필드 값을 변경하여 getaddrinfo() 함수의 정렬 순서를 변경할 수
있습니다.
C:>netsh interface ipv6 show prefixpolicyQuerying active state... Precedence  Label  Prefix----------  -----  --------------------------------        10      4  ::ffff:0:0/96        20      3  ::/96        30      2  2002::/16        40      1  ::/0        50      0  ::1/128
 
  Comments,     Trackbacks
IPv6 프로토콜 스택을 지원하는 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에서는 향후 이를 지원할 계획을 가지고 있습니다.
 
  Comments,     Trackbacks
IPv6 프로토콜을 지원하는 리졸버(resolver)?
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의 버전별 구현 기능항목을 검토하여 파악할 수 있습니다.  
 
  Comments,     Trackbacks