Workshop - 인프라
상태바
Workshop - 인프라
  • 승인 2005.12.06 00:00
  • 댓글 0
이 기사를 공유합니다

네임 시스템 업데이트는 다이내믹 DNS로…

IP 어드레스 관리 자동화 … 역동적 업데이트·통보·IXFR 등 기능 제공

회사의 부서와 사무실 안에서 컴퓨터의 이동과 변화를 추적하는 일은 보통 번거로운 일이 아니다. DHCP(Dynamic Host Configuration Protocol)가 도움이 되긴 하지만 DNS(Domain Name System) 엔트리들 때문에 움직임이 느려지거나, 혹은 수동 업데이트를 해야 할 것이다. DNS 엔트리를 업데이트할 수 있는 보다 나은 방법은 다이내믹 DNS를 사용해서 자동으로 네임 시스템(Name Systems)을 최신 상태로 유지하는 것이다.

DHCP는 분명 엔터프라이즈 네트워크에서 컴퓨터 IP 어드레스를 관리하는 데 효과가 있다. 워크스테이션은 자신들의 IP 어드레스와 네트워크 구성을 DHCP에서 집어낸다. 부서가 이동을 하면 그 서버와 워크스테이션은 새로운 네트워크 구성을 받게 된다. 하지만 IP 어드레스를 지속적으로 추적하고 유효한 DNS 엔트리를 서버와 네트워크 서비스에 할당하는 일은 DHCP만 가지고는 만만치가 않을 것이다.
그보다는 네트워크에 있는 IP 어드레스를 유효한 NDS 이름과 연관시킴으로써 네트워크화된 컴퓨터를 믿을 수 있고 편리하게 식별할 수 있게 하는 것이 좋다. DNS가 있으면 코어 시스템이 DNS 룩업(lookup)을 수행하고, 이 값을 저장하고, 어떤 컴퓨터가 어떤 IP 어드레스를 이용하고 있는지를 알 수 있다.
하지만 다이내믹 DNS 시스템이 없이 DHCP와 DNS를 돌릴 경우 호스트 이름에는 아마 각각의 컴퓨터에 대한 고유의 데이터가 포함돼 있지 않을 것이다(아마 dhcp-192-168-12-34.example.com 같은 모양일 것이다). accounting-sue.workstation.example.com과 같은 DNS 호스트 이름이 로그에 있는 게 더 유용하다. 이런 식의 네이밍은 DDNS에서 훨씬 쉽게 가능하다. DDNS는 다이내믹 DHCP와 DNS 사이의 간격을 잇고, IP기반 서비스(특히 웹 서버)용으로 로깅된 다이내믹 DHCP 임대 기록을 레코딩한다.
DDNS가 DHCP와 DNS 제품에서 널리 사용 가능해지기 이전에 많은 기업들이 DNS를 업데이트하는 전용 방안을 이용하고 있었다. 물론 이런 것들도 좋긴 하지만, 이들은 독립적이며 지원과 유지보수가 어려울 때가 많다. 따라서 아무래도 DDNS 제품을 인프라에 통합시키는 편이 낫다고 할 수 있다.

세 가지 고급 DNS 기능
DDNS에는 역동적 업데이트(dynamic update), 통보 및 IXFR(incremental transfer) 등 세 가지 고급 DNS 기능이 포함돼 있다.
역동적 업데이트는 DHCP 서버나 다른 IP 어드레스 서비스가 DNS 서버에게 새로운 정보를 통보하는 데 사용되는 프로세스다. 보안 접속을 이용해 예를 들어 DNS 서버에게는 workstation-bill.accounting.example.com이 현재 IP 어드레스 10.35.99.124에 있다는 사실이 통보된다. DNS 서버는 이 정보를 기억하고, 예전 정보를 폐기하며, 10.35.99.124란 이름으로 들어오는 어떤 요청이든 workstation-bill.accounting.example.com으로 대답하기 시작한다.
대부분의 조직에는 중복성과 부하 공유를 위해 하나 이상의 DNS 서버가 있다. DNS 용어로 영역(zone)은 기간별로 독립된 하나의 DNS 엔트리의 부분들 가운데 하나다(예를 들어 .accounting.example.com). DNS 정보는 이 영역과 관련되어 저장 및 전송된다. 예를 들어 인터넷 시스템즈(Internet Systems)의 BIND(Berkeley Internet Name Daemon) 오픈소스 DNS 서버 소프트웨어는 보통 그 주 서버로부터 보조 DNS 서버의 영역 레코드를 15분마다 업데이트하며, 따라서 실시간 정보가 제공되지 못한다.
하지만 DDNS의 영역 통보 기능에서는 이 점이 수정되었다. 즉 DNS 서버는 보조 DNS 서버에게 새롭고 업데이트 된 DNS 영역 레코드 버전을 통보한다. 그러면 보조 DNS 서버는 영역 파그일의 업데이트된 카피를 가져와서 그 구성이 서버에서 새 값과 맞게 해야 한다는 사실을 알게 된다.
DDNS를 사용하지 않을 경우에는 이 정보를 전달하기 위해 영역의 전체 카피를 전송해야 하는데, 이것은 완전 역동적 DNS 엔트리에서는 문제가 된다. 즉 규모가 크거나 혹은 신속하게 업데이트되는 DNS 영역이 있을 경우 서버가 금방 다 차버릴 것이다. DDNS의 IXFR 기능이 있으면 보조 서버는 변화된 부분만을 주 서버에게 요청한다. 예를 들어 영역 파일에 1만 개의 DNS 엔트리가 있고 단 세 개만이 바뀌었으면, 전체 영역이 아니라 이들 세 개만이 주 서버에서 보조 서버로 전송된다.

오픈 소스와 상용 서버
대형 네트워크에 DNS를 배치하고 싶을 때 가장 안전한 방법은 BIND 서버 소프트웨어를 사용하는 것이다. 이것은 잘 지원되며 안정적이다.
뿐만 아니라 상용 DDNS 제품은 보통 단순한 DNS 관리 이상을 하며, 전체적인 IP 어드레스 관리 기능도 또한 제공한다. 몇 가지 예로는 인포블록스 네트워크 아이덴티티(Infoblox Network Identity) 어플라이언스, 루슨트 테크놀로지즈 바이탈QIP(Lucent Technologies VitalQIP) 소프트웨어, 그리고 메타인포 메타 IP(MetaInfo Meta IP) 소프트웨어 등을 들 수 있다. 이들은 IP 어드레스 관리와 DNS/DDNS 서비스를 위한 턴키 솔루션들이다.
BIND를 돌리기로 결정했다면 최소한 버전 9.2가 되는지를 확인해야 한다. 이전 버전에서는 문제가 나타났기 때문이다. BIND는 애플 맥 OS X, 리눅스, 윈도 및 유닉스에서 돌아간다.

강력한 암호화 키 필수
데이터를 업데이트할 때는 안전하게 하는 게 중요하다. 예를 들어 누가 업데이트를 보내고 있는지를 확인하도록 DNS 서버를 구성하지 않을 경우에는 침입자가 secure-intranet.example.com을 www.i-am-a-hacker.com으로 방향조정할 수 있다. 여기서는 중복성이 있다고 해서 도움이 되지는 않는다. 역동적 업데이트와 IXFR이 있으면 중복 DNS 서버는 이 잘못된 정보를 신속하게 업데이트할 뿐이기 때문이다.
따라서 DDNS 업데이팅을 구성할 때는 강력하게 암호화가 된 키를 반드시 사용해야 한다. 보안 DDNS 통신에는 두 가지 방식이 있는데, 그것은 바로 TSIG(Transaction Signature)와 SIG(0)다. TSIG 키는 대칭적인 HMAC-MD5(Hashin Message for Authentication MD5) 키다. 대칭적 키는 기본적으로 공유되는 비밀이라고 할 수 있다. 즉 DNS 서버로 업데이트를 보내는 기계가 손상될 경우 각 기계와 DNS 서버가 같은 키를 공유하기 때문에 비밀이 누설된다. 하지만 TSIG 키는 보통 셋업이 쉽고, DNS와 DHCP 제품에서 SIG(0) 키보다 폭넓게 지원된다.
SIG(0)는 표준 암호화 방안을 이용하는 공중/전용 키 쌍으로 구성돼 있다. 이것은 HMAC-MD5보다는 안전하지만 작동하도록 하는 데 더 많은 시간을 투자해야 한다. 각각의 업데이터는 고유의 키를 가지며, SIG(0)과 작동하려면 대부분의 클라이언트 소프트웨어에서 추가 구성이 필요하다.
또한 DNS 구성 파일에서 다중 키를 가질 수 있기 때문에 *.a.example.com은 *.b.example.com와는 다른 키를 가질 수 있을 것이다. 이런 식으로 하면 손상된 키가 유발할 수 있는 손해의 가능성을 제한할 수 있다. 하지만 허가(permission)에서는 주의해야 한다.

TTL의 의미
어떠한 DNS 레코드가 캐싱돼야 하는 시간의 길이를 TTL(Time To Live)이라고 한다. 이 숫자가 낮을수록 다른 인터넷 DNS 서버가 변화를 학습하는 속도는 빨라지지만 DNS 서버로 정보를 요청하는 빈도는 더욱 잦아지게 된다. 이 숫자가 높아지면 인터넷에 날짜가 지난 DNS 정보가 더 많아질 것이다. 하지만 업데이트 빈도가 줄기 때문에 DNS 서버의 부하가 줄어든다.
처음 구성을 하는 동안에는 DNS와 DHCP 서버의 모든 로깅 기능을 켜 둬야 한다. DDNS 시스템이 설치 및 가동된 후에는 다시 보고 제어하고자 하는 에러만을 보여주도록 세팅을 다시 돌려 놓으면 된다. 예를 들어 DNS는 제어권 밖에 있는 인터넷에서 잘못 구성된 DNS 서버에 대해 많은 로그를 만들어 내기 때문에, 이런 데이터를 모두 로깅할 필요가 없다.
역동적 IP 어드레스 업데이팅 시스템을 구축하는 데 있어 다음 단계는 DNS 서버를 업데이트하도록 DHCP 서버를 구성하는 것이다. 인터넷 시스템즈의 DHCPD는 디펙토 표준 DHCP 서버며 현재 버전인 3은 DNS로 역동적 업데이트를 보낸다. 인터넷 시스템즈의 DHCPD에는 여러 가지 옵션이 있지만, 클라이언트용의 네이밍 제한과, 이들이 업데이트돼야 하는 영역, 그리고 컴퓨터가 호스트 이름을 제공하지 않을 때 무엇을 해야 하는지 등에 특히 주의를 기울여야 한다.

디렉토리의 역동성
이상적으로 볼 때는 DDNS를 이용하는 데 마이크로소프트 액티브 디렉토리를 구성하겠지만 이것은 선택에 따라 달라질 수 있다. 윈도 2000 이상에서는 컴퓨터 이름 관리에 WINS 대신 DNS와 SRV(service) 레코드를 사용한다. 여기서 좋은 소식은 이것이 모두 같은 DNS 서버에 의해 처리될 수 있다는 사실이다. 그리고 나쁜 소식은 윈도 2000 기계가 당신이 알지 못하는 사이에 DNS 서버를 역동적으로 변경시키려 시도한다는 점이다. 이들을 안전하게 통합하려면 쉽긴 하지만 약간의 작업을 해야 한다.
액티브 디렉토리를 DNS 영역으로 통합시키는 데는 몇 가지 방법이 있다. 우선 액티브 디렉토리가 모든 DNS를 관리하도록 하거나, 혹은 액티브 디렉토리 숲(forest)에 있는 DNS의 일부가 되거나, 혹은 액티브 디렉토리로 하여금 역동적 업데이트를 통해 기본 DNS 서버를 업데이트하도록 할 수 있다. 마이크로소프트만 쓰는 조직이고 모든 것이 액티브 디렉토리 안에 들어 있다면, OS에 번들링된 윈도 2000x DNS 서비스를 사용하는 게 가장 쉬운 방법이다.
하지만 액티브 디렉토리를 기존의 DNS 서비스로 통합시키고 싶을 때는 특정 영역을 디렉토리로 파견할 수 있다. 따라서 *.ad.example.com은 액티브 디렉토리 영역에 의해 처리가 되고 DNS의 나머지 부분은 다른 서버에서 처리할 수 있다.
마이크로소프트의 DNS 서비스를 이용하는 데서 한 단계 올라간 방법이 주 DNS 서버로부터 디렉토리 서버로 특정 액티브 디렉토리 영역을 파견하고, 주 DNS 서버에 DDNS를 직접적으로 사용하지 않는 것이다. 이러한 추가 영역들은 액티브 디렉토리 서버가 서로를 로케이팅하게 도와줄 뿐만 아니라 클라이언트 워크스테이션이 서버를 로케이팅하는 것도 돕는다. 액티브 디렉토리는 _tcp, _udp, _sites 및 _msdcs를 그 루트와 같은 이름에서 원하기만 할 것이다.
완전한 DDNS 이행에서, 액티브 디렉토리는 메인 DNS 서버로 곧장 역동적 업데이트를 보낸다. 이것은 한 곳에서 DNS 정보를 집중화해 패칭, 업데이팅 및 모니터링을 필요로 하는 서버 수를 줄임으로써 보다 안전해진다.

클라이언트 점검
IP 어드레스가 바뀌는 컴퓨터들 가운데 DHCP나 액티브 디렉토리를 사용할 수 없는 게 있다면, BIND의 nsupdate와 같은 다른 툴이 필요할 것이다. 이 프로그램은 수동으로 사용되거나, 혹은 DNS 정보를 직접적으로 업데이트해주는 스크립트를 통해 사용되도록 돼 있다(예를 들어 DHCP가 없이 DDNS 업데이트를 하는 데 이것을 이용할 수 있다). nsupdate는 기본 입출력을 이용해 DDNS 엔트리를 업데이트한다. nsupdate를 이용해 리눅스 기계가 자신의 IP 어드레스를 www.knuthaugen.no/linux/ddns/에서 직접적으로 업데이트하게 해주는 간단한 스크립트를 찾을 수 있을 것이다.
마이크로소프트 윈도 2000과 XP 스탠드얼론 워크스테이션이 로그인에서 액티브 디렉토리 양식의 DDNS 엔트리를 이용해 스스로를 자동으로 등록시키고 매시간 이를 시도한다는 사실을 명심하라. DNS 서버가 이것이 허용되지 않게 구성돼 있다면 많은 불필요한 트래픽과 에러 로그 엔트리들이 생겨날 것이다. 2000과 XP 기계에 의한 자동 등록 기능을 중지시키려면 HKEY_LOCAL_MACHINE SystemCurrentControlSetServicesNetlogonPar ametersUseDynamicDns를 0x0로 설정하라(디폴트는 0x1이다).
이것은 윈도 제어판의 네트워크 카드 설정에서 TCP/IP 스택용 고급 DNS 설정을 통해 기계로 중지시킬 수 있다. 이렇게 하면 윈도 2000이나 XP 기계가 DDNS 업데이트를 보내려는 시도를 멈추게 될 것이다.
적절하게 구성될 때 DDNS는 IP 어드레스 관리 작업부하를 줄이고, 네트워크에 있는 서비스로 세부적이고 일관성 있는 정보를 제공할 수 있다. 그리고 결국에는 이름 정보를 역동적으로 업데이트하는 동시에 DHCP로 네트워크를 구성할 수 있게 될 것이다.

BIND와 DNS 캐시 중독

올해는 인터넷 시스템즈의 BIND DNS 서버 소프트웨어가 포워딩 네임 서버(forwarding name server)인 것처럼 작동함으로써 몇 건의 DNS 캐시 중독(cache poisoning) 사건이 일어났다.
DNS 서버는 또 다른 보다 큰 네임 서버를 인터넷에서 DNS 정보용의 첫 소스로 이용하도록 맞춤화될 수 있다. 포워딩 네임 서버는 유용하긴 하지만 DNS 질의에 대답하는 데 걸리는 시간을 대폭 줄여주기 때문에 유용하다.
하지만 DNS RFC 사양에 있는 결점으로 인해 DNS 캐시 중독에 취약한 상태로 버려질 수가 있다. 캐시 중독에서는 공격자가 그 혹은 그녀가 제어하는 서버로 www.nwc.com과 같이 잘 알려진 사이트에 대한 정보를 방향조정한다. DNS 서버는 예를 들어 불량 ns1.i-am-a-hacker.com 서버에서부터 www.nwc.com에 대한 정보를 가져오게 될 수 있다. 따라서 이것은 언제나 www.nwc.com에 대한 정보를 찾아 위조 서버로 가게 된다. www.nwc.com이 예를 들어 은행 웹 사이트라면, 공격자는 당신의 모든 금융정보를 훔칠 수 있을 것이다.
비록 이런 구멍은 10년도 더 전에 발견되었을 때 이미 패치가 되긴 했지만, 포워딩 네임 서버로 BIND 버전 4와 8가 작동할 경우 이런 불량 정보가 전달될 수 있다. 따라서 ISP의 DNS 서버가 BIND 4나 8을 돌리고 있고, 이것을 포워딩 네임 서버로 사용하고 있다면, 불량 데이터를 받고 있을 가능성이 있다는 얘기다.
최선의 방법은 최소한 BIND 9.2 이상의 서버(이것은 이런 캐시 중독에 면역성이 있다)를 포워딩 네임 서버로, 그리고 내부 DNS 서버용으로도 사용하는 것이다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.