DNS(BIND)

목차

1. DNS의 개념
1.1. 이름과 주소
1.2. DNS 이전의 구현방법
1.3. DNS의 필요성

2. DNS구조와 위임
2.1. DNS이름의 계층구조
2.2. TLD
2.3. 인터넷 도메인 이름 체계
2.4. DNS관리
2.5. 국내 도메인 명 표준

3. DNS 네임 서비스 설정
3.1. BIND
3.2. resolver 설정
3.3. named 설정

4. DNS 오류 수정
4.1. host
4.2. Dnswalk
4.3. DOC (Domain Obscenity Control)
4.4. DDT(Domain Debug Tools)
4.5. DIG (Domain Information Groper)
4.6. 기타

[부록1]

[부록2]

본문내용

루프백 네트워크가 되는 것이다.
● secondary
이것은 변수로써, domain name와 address list 그리고 file name을 사용한다. 이는 로컬 서버를 명시된 도메인을 위한 두 번째 마스터 서버로 변환시켜 놓는다. 두 번째 서버는 도메인에 있는 믿을 만한 데이터를 가지고 있지만, 파일에서 자료를 가지고 오진 못한다. 하지만 프라이머리 서버로부터 자료를 전송 받는다. 프라이머리 서버에 있는 IP 주소 중 적어도 하나는 named로 주어져야 한다. 로컬 서버는 데이터를 zone 데이터베이스에 성공적으로 전송할 때까지, 각 주소에 접속할 것이며, 결과는 세 번째 변수로 주어진 백업 파일에 저장되어 진다. 만약 어떤 프라이머리 서버도 응답하지 않는다면, zone 데이터는 대신에 백업파일에서 그 정보를 검색하게 된다. named는 규칙 적인 간격으로 zone 데이터를 Refresh하게 된다.
● cache
이것은 domain name과 file name을 변수로써 사용한다. 이 파일은 root server hint를 포함하고 있으며, 모든 레코드 목록이 루트 네임서버를 가리키도록 되어 있다. 오직 NS와 A레코드가 인식될 것이다. domain 변수는 일반적으로 루트 도메인 네임을 지칭하는 것이다. 이 정보는 named에서 절대적인 것이다. 만약 cache 문이 부트 파일에서 발생하지 않았다면, named는 더 이상 로컬 저장소를 개발하지 않는다. 만약 질의를 받은 다음 서버가 로컬 네트워크에 존재하고 있지 않다면, 이것은 그러한 수행작업을 중단시켜 버릴 것이고, 네트워크 적재 작업을 심하게 증가시킬 것이다. 게다가 named는 어떤 루트 네임 서버에도 도달할 수 없을 것이고, 그리하여, 믿을 만한 것을 제외하고는 어떤 주소도 해결 (resolve)하지 못할 것이다. 이러한 규칙에서 예외가 있다면, 그것은 전송중인 서버를 사용할 때뿐일 것이다. ( 아래에 있는 forwarders 옵션)
● forwarders
이것은 변수로써 address list를 사용한다. 이 목록에 있는 IP 주소들은 만약 로컬 저장소에서 질의하는 과정이 실패로 끝이 났다 면, named가 질의할 수 있는 네임 서버의 목록을 명시한다. 이것들은 질의에 응답하는 것이 하나라도 있을 때까지 이러한 작업을 계속한 다.
● slave
이것은 네임 서버를 slave 서버로 만들어 준다. 그 자체 내에서는 질의를 수행할 수 없지만, forwarders 문을 써서, 명시된 서버로 질의를 향하게끔 만든다.
[부록 2]
마스트 파일들이 이용하는 표준 리소스 레코드
● SOA
이것은 권한 구역을 표시해 주고 있다. (SOA는 "Start of Authority"를 의미한다.) 이 신
호는 SOA RA에 해당하는 레코드가 도메인을 위한 믿을 만한 정보를 가지고 있다는 것
을 표시해 준다. primary 문장에 포함되어 있는 모든 마스터 파일은 이러한 구역을 위한
SOA 레코드를 포함시켜야 한다. 여기에 있는 리소스 데이터는 다음과 같은 필드를 포함
하고 있다.
origin : 도메인을 위한 프라이머리 네임 서버의 호스트네임 ex) ns.taegu.ac.kr
contact : 도메인을 유지 관리하고 있는 사람의 전자우편 주소 '@'이라는 문자 대신에
도트를 사용한다. ex) yjpark.biho.taegu.ac.kr
serial : 구역(zone) 파일의 버전 번호.
구역 파일에 데이터가 변경될 때마다 하나씩 증가한다. 두 번째 네임서버는 일정한 간격
을 두고 프라이머리 서버에게 SOA 레코드를 요 청하고, 저장된 SOA 레코드를 시리얼
번호와 비교한다. 만약 그 번호가 변경되었다면, 두 번째 서버는 프라이머리서버로부터
모든 구역(z one) 데이터베이스를 전송 받는다. ex) 1997071603 ; Serial [yyyymmdd]
refresh : 두 번째 서버가 프라이머리 서버의 SOA 레코드를 검사하는 동안에 기다리는
시간
retry : 두 번째 서버가 프라이머리서버와 접속하는 시간 간격
expire : 두 번째 서버가 마지막으로 모든 구역(zone)데이터를 폐기 처분할 때 걸리는
시간
minimum :
자원(resource) 레코드를 위한 ttl의 초기 값을 나타낸다.
● A
이것은 호스트네임을 가지고 있는 IP 주소와 관련되어 있다. 각 호스트에는 오직 하나의
A 레코드가 할당되어야 한다. A 레코드에서 사용되는 호스트네임은 공식적인 호스트네
임으로 간주한다.
ex) IN A 203.244.128.51
● NS
이것은 종속(subordinate) 구역의 마스터 네임 서버를 가리킨다.
ex) IN NS ns.taegu.ac.kr
● CNAME
이것은 canonical hostname이라고 하는 호스트의 별명과 관련되어 있다. 마스터 파일이
제공하는 A 레코드들 중에서 호스트 네임도 포함되어 있다. 별명(alias)은 단순히
CNAME 레코드에 연결되어 있지만, 그 자체로는 아무런 레코드도 가지고 있지 않다.
● MX
이것은 RR이 mail exchanger를 가리키도록 한다. MX 레코드는 메일 교환기를 사용해서
domain을 host 네임으로 바꾸어 주는 역할을 한다.
[domain] [ttl] [class] MX preference host
모든 메일 교환기는 그것과 관련되어 있는 정수형태로 되어 있는 preference를 가지고
있다. domain으로 메일을 전달하길 바라는 우편물 대행업자 (mail transport agent)는
이러한 전달과정이 성공할 때까지, MX 레코드를 가지고 있는 모든 호스트에게 질의를
할 것이다. 우선 순위가 제일 낮은 것부터 질의를 할 것이다.
ex) IN MX 0 biho.taegu.ac.kr.
lN MX 10 stbiho.taegu.ac.kr.
● PTR
이 레코드 형태는 호스트네임을 가지고 있는 in-addr.arpa 라는 도메인과 연관지어 사
용한다. 이것은 IP주소와 대응하는 호스트네 임으로 변경시킬 때 사용한다.
● HINFO
이 레코드는 시스템의 하드웨어와 소프트웨어에 관한 정보를 제공한다.

키워드

DNS,   BIND,   dns,   bind,   네트워크,   도메인,   domain name