공인 서버와 캐시 전용서버
공인 서버와 캐시 전용 서버
리눅스 중에서도 서버에 관하여 알아보도록 하자. 마스터, 슬레이브, 캐시 전용 서버는 데이터를 어디서 가져오는지, 서버가 도메인의 공인 서버인지 아닌지에 따라 구분한다.
존마다 마스터 서버가 하나씩 있다. 마스터 서버는 존 데이터의 공식 사본을 디스크에 저장한다. 시스템 관리자는 마스터 서버의 데이터 파일을 편집함으로써 존 데이터를 변경한다. 슬레이브 서버는 '존 전송' 과정을 거쳐 마스터 서버에서 데이터를 얻는다.
존에는 슬레이브 서버가 여러 개 있을 수 있으며, 최소한 하나 이상 있어야 한다. 자투리 서버는 특별한 종류의 슬레이브 서버로 마스터 서버의 NS(네임 서버) 레코드 정보만 받는다.
장비 하나를 어떤 도메인의 마스터 서버이면서 다른 존의 슬레이브 서버로 사용할 수도 있다. 이런 협력 관계로 좋은 DNS 이웃사촌을 맺을 수도 있다.
캐시 전용 네임 서버는 시작 파일에서 루트 도메인 서버의 주소를 읽고, 나머지 데이터는 처리한 질의응답을 캐시함으로써 구축한다. 캐시 전용 네임 서버에는 자신이 보유한 데이터가 없으며, 로컬 호스트 존을 제외한 어떤 존에 대해서도 공인 서버가 될 수 없다.
네임 서버의 공인 응답은 정확함이 '보장'돼 있다. 비공인 응답은 오래돼 잘못된 정보일 수 있다. 하지만 대부분의 비공인 응답도 정확할 확률이 아주 높다. 마스터와 슬레이브 서버는 해당 존에 대해서는 공인이지만 캐시한 다른 도메인 정보에 대해서는 비공인이다.
솔직히 말하자면 관리자가 마스터 서버의 데이터를 변경하고 변경사항을(데이터의 일련번호를 변경하지 않은 이유 등으로 인해) 제대로 적용하지 못한다면 공인 응답도 부정확할 수 있다.
존의 마스터 서버는 안정적이며, 사용자가 적고 비교적 안전하며, 무정전 장치가 부착된 장비를 사용해야 한다. 같은 공간에 하나, 원격지에 하나를 두는 방법으로 슬레이브 서버가 최소 둘은 있어야 한다.
같은 공간에 있는 슬레이브 서버도 다른 네트워크와 다른 분전반에 연결돼 있어야 한다. 네임 서비스가 멈추면 네트워크 상태가 정상적일지라도 접근이 전혀 불가능해진다.
캐시 서버는 비공인이지만 이를 사용하면 사용자를 위한 응답 시간을 개선할 수 있고, 내부 네트워크에서 DNS 패킷양을 줄일 수 있다. 하위 네트워크별로 캐시 전용서버를 두는 방식을 고려할 만하다. 인터넷상의 장비에 연결하기 위해 데스크탑 장비에서 보내는 대다수 질의는 캐시 서버가 처리한다.
BIND 4와 BIND 8에서는 존의 공인 서버와 사용자를 위한 캐시 서버를 장비 한곳에서 사용하는 방식이 바람직하지 않았다. 각 named가 메모리 데이터베이스 하나를 사용하므로 메모리가 부족하면 상호 메모리 오염이 발생해 캐시된 데이터와 공인 데이터가 뒤섞일 수 있었다.
BIND 9에는 이런 문제가 없으므로 장비 한 곳에서 같이 사용해도 된다. 하지만 보안과 DNS 전문가들은 공인 데이터를 외부에 제공하는 기능과 외부 데이터를 내부 사용자에게 제공하는 기능은 분리하는 방식이 바람직하다고 주장한다.
이름 공간 관리
소규모이고 독립적으로 운영되는 사이트의 경우 기술 외적인 이유로 하위 도메인을 사용할 수밖에 없는 경우가 아니라면 하위 도메인 사용은 필요하지 않으며 오히려 사용하지 않는 편이 좋다. 반면 독립적인 여러 시스템 관리자 그룹이 있는 중급 규모 사이트라면 하위 도메인을 도입함으로써 사이트 전체에 영향을 미치는 작업을 진행하는 빈도를 줄일 수 있다.
규모가 큰 사이트란 사이트 내에 호스트명이 중복되지 않게 제대로 관리하기 어려우므로 하위 도메인이 필요하다. 상황에 따라서는 다층 구조로 하위 도메인을 구성할 수도 있다.
하위 도메인을 만들려면 상위 도메인을 관리하는 시스템 관리자와 하위 도메인을 설정을 할 때 나중에 서버 추가, 변경, 삭제 작업할 때를 대비해 필요한 연락처를 반드시 기록해 둬야 한다. 외부에서 하위 도메인에 접근하지 못하게 방화벽이 막고 있지는 않은지 확인한다.
이 글을 공유합시다
