Steven over blog

Network Working Group
Request for Comments: 1912
Obsoletes: 1537
Category: Informational

D. Barr
The Pennsylvania State University
February 1996

DNS의 운영과 구성에 대한 일반적 오류들

관련 사항: 이 문서는 인터넷 사회에 대한 정보를 제공한다. 이 문서는 어떤 종류의 인터넷 표준에 대한 것이 아니며 배포에 제한이 없다.
요약: 이 문서는 도메인 네임 시스템의 운영과 이들 DNS의 데이터에서 자주 발견되 는 오류에 대하여 설명한다. 이 문서는 DNS의 일반적인 운영과 구성에 대한 설명과 같은 현재의 인터넷 요구사항에 대하여 요약하려는 것이다. 또한 이 문 서에는 [RFC 1537]에서 나타난 쟁점들에 대하여 요약하거나 확장하려 한다.
1. 소개: 네임서버의 운영은 일반적인 작업이 아니다. 여기에는 잘못 될 수 있는 많는 것들이 존재하고 서버를 셋업하고 어떤 자료들을 DNS에 넣어야 하는지에 대 한 많은 판단이 필요하다. 이 문서는 네임서버를 운영하는 중에 생기는 이들 DNS 자료에 대한 일반적인 실수와 함정에 대하여 논의한다. 또한 이와 관련 된 서버나 resolver들의 버그, 그리고 인터넷상의 DNS의 운영에 대한 정책적 인 사안에 대해서도 논의한다.
2. DNS의 자료: 이 절에서는 네임서버가 메모리에 적재하는 존 데이타 파일에서 발견되는 네 임서버의 DNS 자료의 문제에 대해 논의한다.
2.1 불일치, 누락 혹은 잘못된 자료: 인터넷에서 접근 가능한 모든 호스트들은 이름을 가져야 한다. 이것의 중요성 은 점점 명백해지고 있다. 인터넷 상에서 가능한 모든 서비스들은 DNS에 정 확히 등록되지 않으면 사용될 수 없다. PTR과 A 레코드를 일치시킨다. 모든 IP 주소에 대해서 in-addr.arpa 도메인에 일치되는 PTR 레코드가 있어야 한 다. 만약 호스트가 multi-homed인 경우 (즉 둘 이상의 IP 주소를 가지는 경우) 모든 IP 주소가 대응되는 PTR 레코드를 가져야 한다. PTR 레코드와 A 레코드가 일치하지 않으면 이것은 DNS에 등록되지 않은 것 으로 간주된다. 또한 PTR 레코드는 CNAME에 의해 지정된 별명이 아닌 적법 한 A 레코드를 가리켜야 한다. 이를 위해 이 검사를 자동으로 수행해 주는 소 프트웨어나 생성된 일관된 데이터베이스로부터 DNS 자료를 생성 해 주는 소 프트웨어를 사용할 것을 권장한다.; DNS의 도메인 이름들은 점으로 분리되는 "label"들로 구성되어 있다. DNS의 도메인 이름에 사용가능한 글자들에 대한 규칙은 매우 자유롭다. 그러나 도메 인 이름이 호스트의 이름으로 사용되면 이는 호스트 이름에 대한 제한에 따라 야 한다. 또한 도메인 이름이 메일에 사용되면 메일 주소의 이름에 대한 규칙 을 따라야 한다.; 호스트 이름에 사용이 가능한 글자들은 아스키 문자와 숫자 그리고 '-' 문자이 다. 라벨들이 전부 숫자이어서는 안되지만 숫자가 맨 앞에 오는 경우는 괜챦 다. (예, 3com.com). 라벨들은 반드시 숫자나 문자로 시작하여야 한다. [RFC 1035]와 [RFC 1123]을 참조하라. (초기에는 라벨들이 반드시 문자로 시작하도 록 [RFC 1035]에서 제한되었다. 그러나 [RFC 1123]에서 이 제한이 완화되었으 나 어떤 호스트들은 아직도 문제를 가지고 있다). 어떤 호스트들은 이 인터넷 호스트 이름에 대한 규칙에 위배된다 (411.com, 1776.com). 밑줄을 사용하는 것은 [RFC 1033]에서 허용되었지만 [RFC 1033]은 표준을 정의한 것이 아니며 정보일 뿐이다. 어떤 TCP/IP 구현상에는 호스트 이름에 밑줄을 사용하는 것을 거부하는 것이 있다. [RFC 1035]의 이런 규칙들은 이들은 문제들을 최소화 하 기 위한 사람들에 의한 자발적인 것이라는 것에 유의하여야 한다. 인터넷의 호 스트 이름에 대한 규칙은 SMTP에 사용되는 호스트와 주소에도 같이 적용되 는 것에 주의해야 한다.; 도메인 이름이 메일에 사용된다면 이는 반드시 [RFC 822]의 메일에 대한 규칙 에 따라야 한다. 이것은 위에 설명된 규칙보다 자유롭다. 메일에 대한 라벨은 특수 문자, 제어문자, 그리고 공백을 제외한 모든 아스키 문자가 될 수 있다. 특수문자는 주소의 해석을 위한 특정 문자들이다. 이 문자들은 "()<>@,;:\".[]" 이다. ('!' 문자는 [RFC 822]에 없으나 이것도 역시 [RFC 976]의 UUCP 메일 에 상충되므로 사용되어서는 안된다) 그러나 인터넷 상의 메일에 사용되는 거 의 모든 이름들이 호스트 이름으로도 역시 사용되고 있으며 이 표준에 의한 이름은 찾아보기는 어렵지만 메일 소프트웨어는 그들을 받아들일 수 있도록 충분히 자유롭게 만들어져야 한다.; 또한 inet_ntoa() 시스템 호출의 문법에 맞는 주소를 사용하지 않도록 주의하 여야 한다. 예를 들어 0xe는 적법한 이름이지만 "telnet 0xe"를 수행한다고 가 정하면 이것은 IP 주소 0.0.0.14를 접속하려고 시도할 것이다. 또한 inet_ntoa() 시스템 호출이 x400과 같은 이름을 IP 주소로 취급하는 것도 있다고 한다.; 어떤 운영체제는 자신의 이름 길이에 제한을 가지고 있는 것도 있다. DNS에 대한 논점은 아니지만 호스트 이름을 정하기 전에 운영체제의 호스트 이름에 대한 제한을 알아야 한다.; 많은 자원 레코드 (RR)들은 하나 이상의 변수를 필요로 한다. HINFO는 두개 의 변수를 가지며 RP도 마찬가지이다. 충분한 수의 변수를 제공하지 않는다면 서버는 누락된 필드에 대하여 잘못된 정보를 반환할 수 있다. 만일 자료에 공 백이 포함되면 그 스트링들은 인용 부호로 둘러 싸여야 한다.
2.2 SOA 레코드: 각 존의 SOA 레코드에 DNS를 관리하는 사람의 e-mail 주소를 반드시 넣어야 한다. (일반적으로 hostmaster라 함) 이때 e-mail 주소의 '@'는 '.'으로 바꾸어 주어야 한다. 이 주소에 '@'를 사용하면 안된다. 만일 이 주소의 로컬 부분에 이미 '.'이 포함되어 있다면 (John.Smith@widget.xx) 이것은 '\'를 사용하여야 한다. (즉 John\.Smith.widget.xx) 또한 일반적으로 사용되는 다른 방법은 특별 한 이름 'hostmaster'를 사용하고 메일 별명을 사용하여 적절한 사람에게 전달 하도록 하는 방법이다. 이 필드를 사용하여 존의 연락처를 자동적으로 생성하 는 소프트웨어가 존재한다. 이 필드가 부적절하게 되어 있으면 이 소프트웨어 는 잘못된 동작을 하게 될 것이다. 이 주소는 종종 DNS 데이터의 오류 레포 팅에 사용되므로 한 사람 혹은 여러 사람에게 전달 될 수 있어야 한다.; 어떤 BIND의 버전에는 십진수의 일련 번호를 사용할 수 있도록 되어 있지만 그렇게 하지 말아야 한다. 십진수의 일련 번호들은 내부적으로 32비트의 정수 로 변환된다. 일련번호 n.m의 식은 n*10^(3+int(0.9+log10(m))) + m이며 이 변 환과정에서 예기치 않았던 숫자로 해석될 수 있다. 예를 들어 십진수의 일련 번호를 주는 것은 수치적으로 더 큰 수로 증가하는 것으로 자동으로 생성할 수 있지만 나중에 위의 변환이 이루어 진 후 전에 사용되었던 것보다 더 작은 수로 나타날 수 있다. 십진수의 일련 번호는 최근의 BIND 버전에서는 공식적 으로 허용되지 않는다. 권고되는 방법은 YYYYMMDDnn이다 (YYYY=년도, MM=월, DD=날짜, nn= 버전 번호). 이 것은 4294년이 될 때까지 넘치지 않는 다.; SOA 레코드에 대한 타이머 값은 논리적 값을 선택한다 (존 파일에서 초로 표 현된다)
리프레시 :: 2차 서버가 존 파일의 일련번호가 증가되었는지 확인하기 위해 얼 마나 자주 주 서버를 조사 할 것인지를 지정한다. (즉 존의 데이터에 대한 새로운 복사본을 요청하기 위해 필요하다) 이 값은 2차 서버가 유효기간 이 지난 자료를 갱신하기 위한 시간을 지정한다. 이것은 밴드 폭의 사용에 영향을 미치지 않는 경우에는 짧은 값을 (20분 - 2시간)을 지정하고 인터 넷 연결 속도가 늦거나 요구에 의해 시작되는 경우에는 길게 (2시간 -12 시간) 지정한다. 최근의 BIND 버전에서는 (4.9.3) 이 값을 길게 설정할 수 있도록 (1일 혹은 더 긴 시간) 2차 서버들에게 자료가 변경되었는지 통보 할 수 있는 코드를 가지고 있다.
재시도 :: 만일 2차 서버들이 마지막 요청에서 주 서버를 접속할 수 없는 경우 다시 시도할 때까지 정해진 시간을 기다린다. 이 값은 2차 서버가 주 서버 에서 원거리의 네트워크에 있거나 주 서버가 자주 정지되는 경우가 아니 면 다른 값들처럼 중요하지는 않다. 이 값은 일반적으로 리프레시 주기에 비해 작은 값이다.
유효기간 :: 2차 서버가 주 서버를 접속하지 못할 경우 2차 서버가 얼마나 긴 기간 동안 그의 존 파일을 유효한 것으로 보는가에 대한 값이다. 이 값은 일반적인 서버의 정지 시간보다는 길어야 하고 새로운 존 파일을 얻기 전 에 데이타의 유효기간이 지나는 것을 방지하기 위해 반드시 다음에 설명 되는 최소값이나 재시도 주기보다는 길어야 한다. 존파일의 유효기간이 지 난 다음에 2차 서버가 주 서버를 연결하려고 시도하면 그 2차 서버는 해 당 존에 대한 네임 서비스를 제공하지 못한다. 2-4주가 권고되는 값이다.
최소값:: 자원의 레코드에 대한 TTL (유효한 기간)의 값이다. -- 즉 다른 네임 서버의 캐시에 데이터가 얼마나 오랫동안 남아 있을 것인가에 대한 값이 다. ([RFC-1035]에서는 이 값을 최소값이라 정의했다. 그러나 서버들은 이 것을 항상 기본값으로 구현한다.) 이것은 가장 중요한 타이머이다. 이 값 은 서버가 네임서버를 얼마나 자주 갱신할 것인지 만큼 큰 값을 지정한다. 만일 중요한 변경을 계획하고 있다면 이 값을 일시적으로 작은 값으로 변 경하는 것이 좋다. 그리고 변경 이전의 최소값이 지나도록 기다린 후 변경 하고 정확성을 검사한 후 이 값을 다시 되돌려 놓는다. 1-5일이 일반적인 값이다. 이 값이 각각의 자원 레코드에 대해 무효로 하는 경우가 있음에 주의해야 한다.; 위에서 볼 수 있는 것처럼 타이머의 값들은 광범위하게 변화된다. [RFC 1033] 과 같은 일반적인 문서들은 최소 TTL에 대하여 1일을 권장한다. 이것은 존 파일과 같이 자주 변경되는 파일 이외에는 너무 짧다고 생각된다. DNS가 안 정적으로 되면 이 값들을 3일 혹은 이상으로 할 것을 권고한다. 또한 자주 참 조되기는 하지만 잘 변경되지 않는 큰 값을 가진 어떤 RR의 TTL에 대해서도 큰값을 주는 것을 권고한다. (1-2주) 이에 대한 좋은 예는 메일 호스트에 대한 MX, A 그리고 PTR 레코드, 존에 대한 NS 레코드, 네임서버에 대한 A 레코 드 등이다.

2.3 글루 A 레코드: 글루 레코드는 네임서버에 "부트스트랩" 정보를 제공하기 위한 NS 레코드와 관련되어 있는 A 레코드이다.; 예를 들어 podunk.xx. in ns ns1.podunk.xx.
in ns ns2.podunk.xx.
ns1.podunk.xx. in a 1.2.3.4
ns2.podunk.xx. in a 1.2.3.5; 여기에서 A 레코드들을 "글루 레코드"라 부른다.; 글루 레코드들은 현재 존의 위탁된 서브 도메인에 위치한 네임서버들을 위해 존 파일들을 포워드(전달)해 주기 위하여만 필요하다. in-addr.arpa 존은 A 레 코드들을 가지지 않는다. ([RFC-1101]에 의한 서브넷 마스크를 사용하는 경우 제외) 네임서버가 multi-homed ( 즉 2개 이상의 IP 주소를 가짐)인 경우 각기 다른 TTL 값에 의한 캐시의 불일치를 방지하고 이 주소들을 네임서버에서 찾 지 못하지 않게 하기 위하여 이들의 모든 주소를 글루로 표시하여야 한다.; 어떤 사람들은 NS 레코드를 추가할 때마다 "확실히 하기 위하여" 글루 레코드 를 집어 넣는 나쁜 버릇을 가지고 있다. 존의 중복된 글루 레코드는 네임서버 가 새로운 IP 주소로 옮겨지거나 없어지는 것을 어렵게 한다. 즉 어떤 사람들 이 어떤 호스트들에 대하여 이전의 IP 주소를 가지는가를 확인하기 위해 많은 시간을 허비하게 될것이다. 이것은 어떤 사람이 글루 레코드를 변경하거나 삭 제하지 않았기 때문이다. 새로운 BIND의 버전에서는 지역 존 파일의 필요없는 글루 레코드를 무시하도록 되어 있다.; 이전의 BIND 버전 (4.8.3과 그 이전의 것들)은 이러한 여분의 글루 레코드들이 삽입되어 있는 경우 2차 서버들에게 이런 필요없는 글루 레코드를 전송시키는 문제를 발생시킨다. 만일 이 글루 레코드들 중 하나가 잘못되어 있으면 다른 네임서버로 이 오류가 전파된다. 만일 이 두 네임 서버들이 각각의 존에 대해 서로 다른 존의 2차 서버들이라면 다른 서버로 이 글루 레코드를 연속적으로 전달해 줄 수 있다. 이들 데이타를 제거하기 위한 단 한가지 방법은 이들을 죽 이고 저장된 백업 파일을 지운 후 재시동하는 것이다. 이들이 같은 버전으로 조합되어 있는 경우 더 쉽게 다른 네임서버의 잘못되어 있는 데이타에 감염될 수 있게 된다.
2.4 CNAME 레코드: CNAME 레코드는 다른 어떤 데이타와도 같이 존재하는 것이 허용되지 않는 다. 다시 말해 suzy.podunk.xx가 sue.podunk.xx의 별명인 경우 suzy.podunk.xx 에 대한 MX 레코드나 A 레코드, 혹은 TXT 레코드를 가질 수 없다는 것이다. 특히 CNAME과 NS 레코드를 다음과 같이 시도하지 않아야 한다.

podunk.xx. IN NS ns1
IN NS ns2
IN CNAME mary
mary IN A 1.2.3.4; 이것은 일반적인 방법으로 도메인 이름을 호스트 이름으로 지정하기 위하여 경험이 적은 관리자가 자주 시도하는 방법이다. 그러나 BIND와 같은 DNS 서 버들은 CNAME을 보고 그 이름에 대한 다른 자원들을 거부한다. CNAME과 함께 다른 레코드들이 허용되지 않기 때문에 NS 엔트리들은 무시된다. 그러므 로 도메인 podunk.xx의 모든 호스트들이 무시되게 된다.

도메인 이름이 호스트 이름으로도 사용되게 하려면 다음과 같이 하여야 한다.

podunk.xx. IN NS ns1
IN NS ns2
IN A 1.2.3.4
mary IN A 1.2.3.4; CNAME들에 집착하지 않는다. 그들을 나머지 호스트에 대해 사용한다. 그러 나 이들을 극복하기 위한 계획을 만들어야 한다. (그리고 사용자들에게 알려주 어야 한다) 그러나 CNAME들은 서버들의 일반적인 이름에 대하여 - ftp 서버 에 대해 ftp, 웹서버에 대하여 www, 고퍼 서버에 대하여 gopher, 뉴스 서버에 대하여 news등 - 유용하다. 호스트 이름을 지울 때 CNAME들을 같이 지우는 것을 잊지 말아야 한다. 이런 필요 없는 CNAME들은 자원들을 낭비한다.

CNAME들을 MX, CNAME, PTR, NS등의 다른 이름을 가리키는 RR들과의 조합으로 사용하지 않아야 한다. (CIDR 위탁을 구현하기 위한 PTR은 예외이 다) 예를 들어 다음과 같은 것은 안된다.

podunk.xx. IN MX mailhost
mailhost IN CNAME mary
mary IN A 1.2.3.4; [RFC 1034]의 3.6.2절은 이렇게 해서는 안된다고 한다. 그리고 [RFC 974]에서 는 MX 레코드들은 CNAME에서 정의된 별명을 가리키면 안된다고 기술되어 있다. 이렇게 MX 레코드에 CNAME을 사용하는 것은 데이터를 접근하는데 불 필요한 간접 접근이 필요하고 DNS resolver들과 서버들이 응답을 얻기 위해 더 많은 작업을 해야 한다. 만약에 이것이 꼭 필요하다면 이와 같은 것을 m4 와 같은 호스트 파일의 프리프로세서를 사용하여 같은 목적을 이룰 수 있다.

또한 CNAME이 CNAME을 가리키는 체인은 관리를 쉽게 할 수는 있지만 어 떤 resolver들은 이 루프를 검사하지 못하는 것도 있다. 그 결과 어떤 호스트 들에 대한 이름을 해석할 수 없을 수 있다.

CNAME 을 가리키는 NS 레코드는 좋지 않으며 현재의 BIND 서버들과 충돌 을 야기할 수 있다. 현재의 BIND의 버전들은 이런 레코드를 무시하지만 불충 분할 수도 있다. BIND에서는 DNS의 NS 레코드를 속이는 것을 방지하기 위 하여 약간의 보안 검사를 수행한다. 또한 오래된 BIND 서버들은 별명이 지정 된 네임서버의 주소를 얻기 위해 계속적으로 DNS 요청을 보내게 하는 무한 루프가 수행되게 하기도 한다.
2.5 MX 레코드: 호스트가 자기 자신을 가리키더라도 모든 호스트에 MX 레코드를 지정하는 것 이 좋다. 어떤 메일러들은 MX 레코드를 캐시하기도 하지만 메일을 보내기 전 에 항상 MX 레코드를 확인하는 것이 필요하다. 어떤 사이트에 MX가 없다면 MX에 대한 질의에 MX 호스트의 IP 주소가 포함되어 있기 때문에 모든 메일 들은 답을 얻기까지 또 한번의 resolver 질의를 하여야 한다. 인터넷의 SMTP 메일러들은 [RFC 1123]에 의한 MX 메카니즘을 지원하도록 되어있다.

호 스트가 e-mail을 송신하거나 수신하지 않도록 되어 있더라도 모든 호스트에 MX 레코드를 기입한다. 만약 이들 호스트들 중 하나가 보안문제에 관련되어 있다면 어떤 사용자들은 포스트마스터나 시스템 루트 (관리자)에게 그것이 "실 제" 호스트인지 아니면 메일을 받을 수 없는 개인용 컴퓨터인지 알아보기 위 하여 메일을 보낼 것이다. 만일 그것에 MX 레코드가 주어 졌다면 email은 실 제 사용자에게 재전송될 것이다. 그렇지 않으면 메일들은 메일큐에 메일러가 발송을 포기할 때까지 몇시간 혹은 며칠간 자리잡고 있게 될 것이다.

MX 레코드를 추가할 때마다 잊지 말아야 할 것은 목적지 메일러에 첫번째 호 스트를 "로컬" 호스트로 하여야 한다는 것이다. (예를 들어 sendmail인 경우 Cw 플래그) 만일 외부 호스트를 가리키는 MX 레코드를 추가하는 경우 (예를 들어 메일 라우팅을 백업하기 위한 용도로 사용) 해당 사이트에서 권한을 먼 저 얻어야 한다. 그렇지 않으면 그 사이트를 당황하게 하거나 다른 행동 (예를 들어 메일을 취소시킨다던가 상위 DNS 관리자나 네트웍 제공자 등 상위의 기 관에 그 문제에 대한 항의)을 취하게 될 것이다.
2.6 이 외의 자원 레코드들
2.6.1 WKS: [RFC 1123]은 WKS 레코드를 반대하였다. 이들은 LISP 머신의 내부적인 것 이외에는 유용한 기능들을 행하지 않는다. 그러므로 이들은 사용하지 않는다.
2.6.2 HINFO: HINFO 레코드에 대한 쟁점 중 보안 문제에 대한 논쟁이 있다. (사용하는 하 드웨어나 운영체제에 대해 알려줌으로서 이 기종들에 대하여 알려진 보안 허 점들을 공격하게 할 수 있다는 것이다.) 만일 이것을 사용한다면 반드시 그 시 스템의 보안 헛점에 대한 최근의 문제들을 알고 있어야 한다. 그럼에도 불구하 고 이들은 유용한 용도로 사용된다. HINFO가 하드웨어 타입과 운영체제의 2 개의 매개변수를 가진다는 것을 잊으면 안된다.

HINFO는 가끔 다른 정보를 알려 주는 것으로 오용되기도 한다. 이 레코드는 기계 자신에 대한 특별한 정보를 알려 주는 것을 의미한다. 만일 DNS 내의 호스트의 다른 정보를 기술하려면 TXT 레코드를 사용한다.
2.6.3 TXT: TXT 레코드는 특별한 정의가 없다. 여기에는 어떤 것이든지 들어갈 수 있다. 어떤 사용자들은 이것을 호스트에 대한 일반적인 설명을 위해 사용하기도 하 고 또는 그 시스템의 위치, 주된 사용자 또는 전화번호 같은 특정 정보를 넣기 위해 사용한다.
2.6.4 RP: RP 레코드는 비교적 새로운 것이다. 이것은 "책임자"의 email 주소, 그리고 더 많은 정보를 얻기 위한 TXT 레코드의 이름을 나타내기 위하여 사용된다. (2.2 절의 첫번째 문장 참조)[RFC 1183]을 참조한다.
2.7 와일드카드 레코드들: 와일드카드 MX들은 IP로 접속되지 않은 네트워크들에 대하여 특히 유용하다. 일반적인 실수의 하나는 존에 대한 와일드카드 MX가 그 존의 모든 호스트들 에 대해 적용될 것이 생각하는 것이다. 와일드카드 MX는 존에서 DNS에 나타 나지 않은 호스트들에 대한 이름들에만 적용된다. 예를 들어
podunk.xx. IN NS ns1
IN NS ns2
mary IN A 1.2.3.4
*.podunk.xx. IN MX 5 sue; Mary.podunk.xx에 대한 메일은 배달을 위하여 자신에게로 전송된다. jane.podunk.xx등과 같이 위의 목록에 없는 호스트들에 대한 메일만 MX로 보 내진다. 거의 모든 인터넷 사이트들에서 와일드카드 MX 레코드들은 유용하지 않다. 모든 호스트에 대해 명확하게 MX를 표시하여야 한다.; 와일드카드 MX들은 동작이 실패했을 경우 다른 동작을 해야 하기 때문에 좋 지 않다. 도메인 "widget.com"에 있는 어떤 사람이 "joe@larry"에게 메일을 보 내려고 시도하는 경우를 고려해 보자. 만일 larry가 실제 존재하지 않는면 그 메일은 즉시 bounce될 것이다. 그러나 도메인을 검색하는 중에 larry.widget.com이 주소로 얻어지며 와일드카드 MX에 의해 DNS의 적법한 주소라고 해석되게 된다. 또는 어떤 사용자가 주소의 호스트 이름 부분을 잘못 쳤을 경우 이 메일 메시지는 메일 호스트를 통해 라우트되어 "자신과 대화할 수 없다" 혹은 "구성 오류"와 같은 이상한 오류 메시지들을 만들어 내게 된다.; 와일드카드 MX들은 인터넷에 직접적으로 연결되지 않은 많은 수의 호스트들 이 있는 경우(예를 들어 firewall에 숨겨져 있는 경우)와 관리 혹은 정책적인 이유에서 모든 호스트들이 개별적인 MX 레코드들을 가질 수 없는 경우나 모 든 email 주소들이 하나 혹은 이상의 도메인 이름에 의해 감추어져야 할 경우 에 유용하다. 이런 경우 DNS를 내부 DNS와 외부 DNS의 두 부분으로 분리해 야 한다. 외부 DNS는 몇개의 호스트들과 명확한 MX 레코드들을 가지고 하나 혹은 이상의 내부 도메인들에 대한 와일드카드 MX들을 가져야 한다. 내부적 으로 DNS는 완전해야 하고 모든 명확한 MX 레코드들은 와일드카드를 사용 하면 안 된다.; CNAME들에 대한 와일드카드 또한 가능하며 이들은 사용자들을 당황하게 하 므로 깊게 생각하지 않고 사용하면 악몽이 될 가능성이 있다. 이것은 telnet/ftp에 대한 도메인 검색에서 알 수 없는 호스트들에 대한 시도를 어떤 한 주소로 인도한다. 이런 와일드카드의 하나인 CNAME (*.edu.com)은 인터 넷 전체에 걸친 서비스의 손실과 도메인 검색에 대한 예측치 않은 호스트로의 인도로 잠재적인 보안의 악몽이 나타날 수 있다. 이것에 대한 신속한 교정법과 이에 대한 문제점이 RFC에 문서화 되었다.
2.8 권한과 위탁에 대한 오류들 (NS 레코드들): 모든 도메인에 대해서 더 많으면 좋지만 그렇지 않응 경우 최소한 두개의 네 임 서버가 있어야 한다. 2차 서버는 외부에 있다. 만일 2차 서버가 기관의 제 어하에 있지 않으면 주기적으로 그들을 검사하고 현재의 존 자료를 그 호스트 에서 복사해 갈 수 있도록 하여야 한다. 이들 네임서버에 대한 호스트의 질의 는 항상 "authorative" 응답이어야 한다. 그렇지 않다면 이것을 불충분한 위탁 이라 한다. 불충분한 위탁은 네임서버가 어떤 존에 대하여 네임서비스를 제공 하는 권한을 위탁하였지만 그 존에 대해서 주 혹은 2차로 셋업되지 않아 네임 서비스를 제공하지 않는 경우에 존재한다.

"고전적인" 불충분한 위탁은 다음과 같은 예로 설명될 수 있다.

podunk.xx. IN NS ns1.podunk.xx.
IN NS ns0.widget.com.; "podunk.xx"가 새로 생성된 새 도메인이고 "ns1,podunk.xx"이 그 존에 대해서 네임 서비스를 제공하기 위해서 설정되었다고 하자. 이들은 아직 모든 것이 완 료되지 않았고 "ns0.widget.com"의 호스트 마스터가 2차로 설정되었다. 그러면 podunk.xx 도메인에 대한 정보가 없고 DNS도 그렇게 답할 것이다. 어떤 네임 서버가 사용되느냐에 따라 여러가지 일이 발생할 것이다. 최선의 경우 추가적 인 DNS 트래픽이 불충분한 위탁의 결과로 발생한다. 최악의 경우 호스트의 주소를 얻지 못하고 email이 반송될 것이다.; 또한 가끔 네임 서버가 다른 호스트로 옮겨지거나 2차 서버들의 목록에서 삭 제될 수 있다. 불행히도 NS 레코드의 캐싱으로 인하여 많은 사이트들이 그 호 스트의 네임서비스가 중단된 뒤에도 2차 서버로 생각할 것이다. 캐시가 오래 될 경우의 불충분한 위탁을 막기 위해서 이전의 네임서버에서 네임 서비스를 최소값들 중의 제일 큰 값에 리프레시 시간을 더한 만큼의 시간 동안 해당 존 과 부모 존의 서비스를 계속해서 제공하도록 한다. (2.2절을 참조하시오); 주 혹은 2차 서버가 삭제되거나 변경되는 경우 관련된 쪽에 대한 관리자의 조 절이 필요하다.(사이트 자체, 그의 부모, 2차 호스트). 주 서버가 이동되는 경우 에는 모든 2차 서버들의 named.boot 파일이 변경되어야 하고 서버들이 다시 로드되어야 한다. 2차 서버들이 이동하는 경우에는 주 서버와 그의 부모 레벨 이 변경되어야 한다.; "ns.uu.net"와 같이 대중적인 어떤 다른 사이트의 네임서버를 지정하는 경우에 도 역시 보고되어야 하고 그들의 네임서버로 동작할 수 있도록 NS 레코드에 추가 시켜야 한다. 이것은 이미 사용중인 네임서버로의 트래픽을 추가하기 때 문에 불충분한 위탁을 증가시킨다. 불충분한 위탁을 가진 사이트의 호스트마스 터를 접촉하여라. 다양한 도구들이 이들 불충분한 위탁을 검출하기 위하여 사 용될 수 있다. BIND 배포판에 있는 소프트웨어들의 목록을 참조하라.; 부모 도메인이 해당 도메인의 존 파일을 가지는지 확인한다. (자신의 in-addr.arpa 파일도 잊으면 안된다) 이들을 너무 많이 나열하지 않도록 한다. (7개가 권고되는 최대치이다) 너무 많이 나열도는 경우 이는 관리를 어렵게 한다. 또한 대중적인 최상위나 루트 도메인에 대하여 꼭 필요한 것만 나열한 다. 또한 NS 질의가 512 바이트의 UDP 패킷 제한을 넘어가면 resolver들은 TCP 요청을 하게 되고 이것은 네임서버의 부하를 증가시키게 된다.; 지연시간을 줄이고 신뢰성을 향상시키기 위하여 2차 네임서버의 지형적인 위 치를 선정하는 것도 중요하다. 네트워크의 토폴로지를 명심하여라. 예를 들어 해당 사이트가 느린 지역 지역 혹은 국제적인 링크의 반대쪽 한쪽 끝에 있다 면 2차 서버의 위치를 다른 쪽의 것을 선택하여 평균 지연시간을 줄이는 것을 고려한다. 해당 인터넷 서비스 제공자나 부모 도메인을 접촉하여 사용가능한 2 차 서버들에 대한 정보를 얻는다.
3. BIND 운영: 이 절에서는 네임서버의 실제적인 운영에서 나올 수 있는 공통적인 문제점에 대하여 논의한다. 위에서 설명된 자료가 정확하여야 함은 물론이고 자료가 사 용가능하게 되려면 반드시 네임서버가 정확하게 운영되어야 한다.
3.1 일련 번호: 각 존은 그 존과 연관된 일련번호들을 가지고 있다. 이들의 용도는 어떤 것이 가장 최근의 자료를 가지고 있는지를 확인하기 위해서이다. 주 서버의 존에 대 한 일련번호는 2차 서버가 주 서버로 새로운 존 데이터의 복사를 요청하는 필 요 충분 조건이다. (이에 대한 특별한 경우는 다음을 참조한다); 데이터를 변경했을 때 일련번호를 변경하는 것을 잊지 않아야 한다. 만약 그렇 지 않으면 2차 서버들이 새 존 데이터를 전송 받지 않을 것이다. 이 일련 번호 를 자동으로 증가시키는 소프트웨어를 사용하는 것도 좋은 방법이다.; 만약 일련번호가 너무 크게 증가되었거나 실수를 하였을 경우 일련번호를 작 은 값으로 변경하려고 하는 경우에는 다음의 절차를 사용한다.; '잘못된' 일련번호에 2147483647을 더한다. 만일 이 수가 4294967296를 초 과하면4294967296을 뺀다. 결과 값을 로드한다. 그리고 존 데이터가 다른 모든 서버로 전파되도록 2번의 리프레시 주기를 기다린다. 위의 절차를 일련 번호가 목적하는 일련 번호보다 작아질 때까지 반복한다. 이 일련번 호를 목적 일련번호로 올린다.

이 절차는 2차 서버가 BIND 버전 4.8.3 혹은 이전의 버전인 경우에는 작동하 지 않는다. 이 경우에는 2차 서버에 대한 호스트 마스터를 접촉하여 저장된 백 업 파일을 삭제하고 서버를 재 시동한다. 일련 번호를 편집하는 경우에는 주의 를 기울여야 한다. -- DNS 관리자들은 캐시된 자료를 모두 잃어버려야 하기 때문에 서버를 죽이거나 재 시동하는 것을 좋아하지 않는다.
3.2 Zone 파일의 스타일에 대한 가이드: 여기에 존 파일들을 구조화하기 위한 몇 가지 유용한 팁들이 있다. 이는 실수 를 찾아내는데 도움이 되고 또한 실수를 하지 않도록 해준다.; DNS 파일들을 입력하는 스타일을 일관되게 한다. 만일 $ORIGIN이 podunk.xx인 경우 다음과 같이 쓰지 않도록 한다.

mary IN A 1.2.3.1
sue.podunk.xx. IN A 1.2.3.2
또는:
bobbi IN A 1.2.3.2
IN MX mary.podunk.xx.; 모든 곳에서 모든 FQDN (완전한 도메인 이름)을 사용하거나 그렇지 않은 이 름을 모든 곳에 일관되게 사용한다. 또는 오른쪽에는 모두 FQDN을 사용하고 왼쪽에는 그렇지 않은 이름을 사용한다. 위의 것 모두 반드시 일관되어야 한 다.; 각 필드 사이에는 탭을 사용하고 각 열들이 잘 맞추어지도록 한다. 이것은 빠 진 필드들을 찾아내는데 도움이 된다. (IN과 같은 필드들은 이전의 레코드에서 상속되고 어떤 환경에 남아있게 된다.) 한 개의 호스트에 대해 여러 개의 레코 드를 정의하는 경우 이 이름은 반복될 필요가 없다는 것을 기억한다. 또한 한 호스트에 연관된 레코드들을 파일에 유지하도록 한다. 이는 어떤 호스트를 삭 제하거나 이름을 변경하는 경우 이를 편리하게 하여 준다.; 해당하는 $ORIGIN을 항상 기억하여야 한다. 만일 FQDN의 끝에 '.'을 넣는 것을 빠뜨렸다면 그것은 FQDN으로 인식되지 않는다. 만일 그것이 FQDN이 아니라면 네임서버는 그 이름에 $ORIGIN을 부가한다. 두번 세번 이 끝의 '.' 을 검사한다. 특히 제일 많이 필요로 하는 in-addr.arpa 파일에서 이 검사를 한다.; SOA와 WKS 레코드의 문법에 주의한다. (괄호를 사용하는 레코드). BIND는 이들 레코드들을 파싱하는데 대하여 유연성이 없다. BIND의 문서를 참조한다.
3.3 자료의 검증 (verifying): "Dig"나 선호하는 DNS 도구를 사용하여 입력하거나 resolver의 질의에 의하여 변경된 데이터를 검증한다. 단 몇 초 동안의 반복 검사가 여러 시간에 걸친 오 류, 메일을 잃어버리는 것, 그리고 일반적인 골치거리에서 해방시켜 준다. 또한 네임서버가 재 로드될 때 생기는 syslog 메시지도 함께 검사한다. 만약에 DNS 데이터나 부트 파일에 중대한 오류가 있는 경우 named는 syslog를 통하여 이 오류를 보고한다.; 이 검사를 자동화하거나 소프트웨어를 가지고 네임서버에 이들이 로드되기 전 에 데이터 파일의 검사를 하는 것을 권고한다. 이것들을 행하는 소프트웨어들 이 BIND 배포 판에 포함되어 있다.
4. 기타 사항들
4.1 부트 파일의 셋업: 어떤 존들은 네임서버의 구성에 항상 나타나야 한다.

primary
primary
primary
primary

localhost
0.0.127.in-addr.arpa
255.in-addr.arpa
0.in-addr.arpa

localhost
127.0
255
0

이들은 "특별한" 주소에 대하여 네임 서비스를 제공하거나 우발적인 질의를 브 로드캐스트하는 것을 방지하고 루트 네임서버로 지역 주소들을 보내는 것을 방지해 준다. 이 모든 파일들은 다른 존 파일들처럼 NS 레코드와 SOA 레코드 를 포함하고 있다. 예외는 이들의 데이터가 절대로 변경되지 않기 때문에 SOA 타이머들이 매우 길게 잡혀 있다는 것 뿐이다. "localhist"의 주소는 지역 호스트가 항상 참조하는 특별한 주소이다. 다음의 줄이 반드시 포함되어야 한 다.

localhost.

127.0.0.1

"127.0" 파일은 반드시 다음의 줄을 포함하여야 한다.

PTR

localhost.

지역 도메인을 여기에 붙일 것인가 안 붙일 것인가에 대한 논의가 있었다. 결 론은 "localhost"가 가장 좋은 해결책이라는 것이었다. 이 이유는 :

"어떤 시스템에서는 "localhost"자체로 사용된다"는 것이다.

127.0.0.1 을 "localhost.dom.ain"으로 번역하는 경우 소프트웨어가 루프백 인터 페이스를 통해 다시 연결되어야 하는 경우가 생긴다. 이것은 "localhost"와 "localhost.dom.ain"이 다르기 때문이다.

255와 0의 파일들은 NS와 SOA 레코드를 제외한 어떤 부가적인 자료를 포 함해서는 안된다.

미래의 BIND 버전들은 부가적인 구성을 하지 않더라도 이것에 대한 모든 혹 은 일부의 자료를 자동적으로 포함하게 될 것이다.
4.2 resolver와 서버의 다른 버그들: 아주 오래된 DNS resolver는 이름에 대한 질의를 IP 주소에 대한 것처럼 보는 것들이 있다 이 이유는 사용자가 IP 주소를 제공했는데 소프트웨어가 주소를 해석할 필요가 없다는 것을 판단하지 못했기 때문이다. 이것은 교정되었지만 가끔씩 나오는 수가 있다. 이것은 이 질의들이 이미 대량의 로드를 받고 있는 루트 네임서버로 직접 전달되어 부하를 가중시키기 때문에 중요하다.

2차 네임서버를 운영하는 중에 다른 2차 네임서버를 운영시키는 것이 가능하 나 이것은 네트웍 토폴로지에 필요한 경우가 아니면 권고되지 않는다. 이들이 가짜 TTL 값으로 인도되는 경우들이 있다. 이들은 오래되거나 잘못된 DNS 구현들에 의해 생기지만 2차 서버들을 연쇄적으로 운영하는 것은 이들이 부가 적인 신뢰성을 주는 것처럼 새로운 존 데이터의 갱신에 부가적인 지연을 초래 한다.
4.3 서버의 쟁점들: DNS는 UDP를 통하여 운영된다. 어떤 UNIX 운영체제들에서는 CPU 사이클을 절약하기 위해 UDP의 첵섬을 사용하지 않을 수 있다. 이것의 상대적인 장점 은 오랫동안 쟁점이 되어왔다. 그러나 CPU 속도의 증가로 성능에 대한 고려는 덜 중요해졌다. DNS 서비스뿐만이 아니라 다른 서비스에 대해서도 데이터의 파손을 막기 위 하여 이 UDP 첵섬을 사용하는 것이 장려된다. 이 UDP의 첵섬이 가능하게 되 어 있는지는 운영체제의 문서를 참조한다.

References

[RFC 974]	Partridge, C., "Mail routing and the domain system", STD 14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
[RFC 1033]	Lottor, M, "Domain Administrators Operations Guide", RFC 1033, USC/Information Sciences Institute, November 1987.
[RFC 1034]	Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
[RFC 1035]	Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
[RFC 1123]	Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, IETF, October 1989.
[RFC 1178]	Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC 1178, Integrated Systems Group/NIST, August 1990.
[RFC 1183]	Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart, "New DNS RR Definitions", RFC 1183, October 1990.
[RFC 1535]	Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, ACES Research Inc., October 1993.
[RFC 1536]	Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, USC/Information Sciences Institute, USC, October 1993.
[RFC 1537]	Beertema, P., "Common DNS Data File Configuration Errors", RFC 1537, CWI, October 1993.
[RFC 1713]	A. Romao, "Tools for DNS debugging", RFC 1713, FCCN, November 1994.
[BOG]	Vixie, P, et. al., "Name Server Operations Guide for BIND", Vixie Enterprises, July 1994.

5. 보안에 대한 고려

보안에 대한 문제는 논의되지 않았다.

6. 저자 주소: David Barr
The Pennsylvania State University
Department of Mathematics
334 Whitmore Building
University Park, PA 16802

Voice: +1 814 863 7374
Fax: +1 814 863-8311
EMail: barr@math.psu.edu

Steven over blog

9 Entries : Results for study

방화벽 차단됨

Comments Leave your comment

비트 개수 세기 - Bit Counting

Comments Leave your comment

distance metic

Comments Leave your comment

[RFC 1912] DNS의 운영과 구성에 대한 일반적 오류들

Comments Leave your comment

8051보드 (MAX232)와 시리얼 케이블 결선도

Comments Leave your comment

Recent Posts

« 2024/04 »
일	월	화	수	목	금	토
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30