한빛출판네트워크

By 크리켓 리우, DNS and BIND, 4th Edition 공동 저자 BIND 8 사용자는 최근 BIND 8 네임 서버에 나타난 보안 문제(BIND Vulnerabilities를 참조하자)를 보면서, BIND 9로 업그레이드해야겠다는 생각을 했을 것이다. 혹은 뷰(view)와 같은 BIND 9의 새로운 특성을 사용해보고 싶을 수도 있다. 동기야 무엇이든 간에 BIND 9와 BIND 이전 버전 사이에는 큰 차이가 있으므로, 업그레이드하기 전에 먼저 익히도록 하자. 중요도에 따라 BIND 9의 9가지 새로운 특성을 설명했다. 1. BIND 9는 영역 데이터 파일(zone data files)의 에러를 다르게 처리한다. BIND 9는 구문이나 논리에 에러가 있는 영역은 로드하지 않는다. 이와 달리 BIND 초기 버전은 에러에 상관없이 대부분의 영역을 로드했다. 사용자가 syslog 파일에 나타나는 여러 경고를 무시한 채 웹 서핑을 즐기는 스타일이라면, BIND 9로 업그레이드하는 것은 다시 한번 생각해 봐야 할 것이다. BIND 9 네임 서버(name server)가 영역을 로드하지 않게 되는 에러의 몇 가지 예를 들었다:

• CNAME 레코드나 다른 레코드(또 다른 CNAME 레코드를 포함)가 있는 하나의 도메인 네임
• 리소스 레코드에서 빠진 필드

2. BIND 9는 named.conf의 에러를 다르게 처리한다. 이전의 BIND 네임 서버는 named.conf에서 에러가 나타나면 아주 부분적인 설정만으로 동작했다. 그래서 슬레이브 영역 문(slave zone statement)에서 마스터 하위문(masters substatement)을 빠뜨리는 경우도 생긴다:

zone "test.example" { type slave; file "bak.test.example"; };

BIND 8 네임 서버라면 위의 영역 문을 그냥 지나치고서 시작할 것이다. 하지만 BIND 9 네임 서버는 시작하지 않는다:

Apr 2 16:05:10 ns1 /usr/local/sbin/named[6501]: zone "test.example": missing "masters" entry Apr 2 16:05:10 ns1 /usr/local/sbin/named[6501]: loading configuration: failure Apr 2 16:05:10 ns1 /usr/local/sbin/named[6501]: exiting (due to fatal error)

이 문제는 named가 시작하기도 전에 마스터 하위문을 덧붙여서 수정해야 한다. 3. $TTL 제어문(control statement)이 필요하다. BIND 9 네임 서버에서는 각각의 영역 데이터 파일에 $TTL 제어문이 있는 영역에 대한 TTL 값을 디폴트로 지정해야 한다(각각의 레코드에 TTL 값을 명백히 지정해 주면된다. 하지만 누가 이런 귀찮은 일을 하겠는가?). 그렇지 않으면 다음과 같은 에러 메시지가 뜰 것이다:

Apr 2 14:39:33 ns1 /usr/local/sbin/named[6054]: dns_master_load: db.test.example:1: no TTL specified Apr 2 14:39:33 ns1 /usr/local/sbin/named[6054]: dns_zone_load: zone test.example/IN: loading master file db.test.example: no ttl

BIND 8.2와 9 네임 서버는 $TTL 제어문이 지정돼 있지 않으면, 영역의 SOA(state of authority) 레코드에 있는 마지막 필드를 디폴트 $TTL로 사용한다. (BIND 8.2 이전 버전에서는 $TTL 제어문을 전혀 인식하지 못했다.) 4. BIND 9의 디폴트 영역 전송 형식(zone transfer format)은 many-answers이다. BIND 8은 새롭고 더 효과적인 many-answers 영역 전송 형식을 지원하기는 하지만, 상호운용성(interoperability)을 높이기 위해 이전의 one-answer 형식이 디폴트 값으로 지정되어있다. 반면 BIND 9는 many-answer 형식이다. BIND 4 슬레이브가 없다면, named.conf에서 서버 스테이트먼트로 사용자의 BIND 9 네임 서버에 one-answer 영역 전송을 하라고 지시해야 할 것이다:

server 10.0.0.1 { // our poor BIND 4 slave transfer-format one-answer; };

5. BIND 9는 ndc가 아닌 rndc를 사용한다. BIND 8은 ndc(name daemon controller)를 도입했다. 원래는 네임 서버의 PID를 찾아 신호를 보내서 일을 하도록 자동화되어, 네임 서버를 리로드하는 등 재미있는 일을 수행한다. BIND 8.2에서 ndc는 바이너리(그 당시에는 셸 스크립트였다)가 되어, 유닉스 도메인 소켓 기반, 혹은 TCP 기반의 “제어 경로(control channel)”로 작동중인 네임 서버에 제어 메시지를 보냈다. 네임 서버를 설치하기만 하면 BIND 8이건 9건 간에 ndc는 잘 작동했다. 다른 점이 있다면 버전 8에서는 named.pid 파일에서 서버의 PID를 추적하지만, 버전 9에서는 로컬 유닉스 도메인 소켓으로 네임 서버와 커뮤니케이트한다는 것이다. BIND 9는 ndc의 뒤를 잇는 rndc를 사용해서 네임 서버를 통제한다. rndc는 인증된 제어 경로로 네임 서버에 메시지를 보낸다. 이러한 과정은 두 가지 이유에서 중요성을 띠는데, 제어 경로로 전송되는 메시지를 다른 사람이 스푸핑(spoofing)할 위험이 줄어들며, rndc가 “상자 밖에서는” 작동하지 않기 때문이다. rndc를 사용하려면, rndc.conf 파일을 생성해서 키 문(key statement)과 제어문을 named.conf 파일에 덧붙여야 한다. rndc.conf 파일을 간단히 소개한다. 이 파일은 대개 /etc 안에 있다:

options { default-server localhost; default-key "rndc-key"; }; key "rndc-key" { algorithm hmac-md5; secret "jZhJ6D0KwJapRhr4Ln6RYQ=="; };

명령어를 전송할 때, rndc가 rndc-key라고 이름이 붙여진 키를 로컬 호스트에서 동작 중인 네임 서버에 디폴트 값으로 제공한다는 것이다. named.conf 파일에는 이에 상응하는 키와 제어문이 있다:

controls { inet * allow { any; } keys { "rndc-key"; }; }; key "rndc-key" { algorithm hmac-md5; secret "jZhJ6D0KwJapRhr4Ln6RYQ=="; };

그러면 named는 모든 로컬 네트워크 인터페이스에서 제어 메시지가 있는지 확인한 다음, IP 주소에서 네트워크 인터페이스를 생성한다. 이때 인터페이스는 rndc-key 키와 연계되어있어야 한다. 키 문(key statement)은 rndc.conf 파일에 있는 제어문과 같아야 한다. 키의 이름은 키가 나타내는 특성을 나타내줌과 동시에, rndc.conf와 named.conf와 매치되어야 한다. rndc는 키의 이름으로 해시 값을 생성하는 키를 인식하기 때문이다. 여기에서 해시 값은 제어 메시지를 인증한다. 6. BIND 9는 영역 경계를 엄격하게 적용한다. 이전 버전의 네임 서버는 다음과 같은 설정도 문제없이 수행했다:

subdomain IN NS ns1 subdomain IN TXT "Delegated subdomain"

기술적인 측면에서 보면, TXT 레코드는 부모 영역이 아니라 서브도메인의 영역 데이터 파일에 속해야 한다. 하지만 이전 BIND 버전에서는 부모 영역에 속했다. 물론 BIND 9 버전은 이와 다르다. BIND 9는 TXT 레코드를 “영역을 벗어난 데이터”로 무시해 버린다. BIND 9가 이처럼 엄격하기 때문에, 부모 영역의 위임 정보(delegation information)와 관련된 문제가 발생할 수 있다. 이때 관리자는 주로 하나의 네임 서버 내, 부모 영역으로 위임된 영역의 NS 레코드를 자동 “프로모션(promotion)"한다. 그래서 BIND 8 네임 서버가 bar.example의 주 마스터, 혹은 foo.bar.example의 슬레이브로 설정되어 있으면, 자동으로 foo.bar.example의 NS 레코드를 bar.example 영역에 있는 foo.bar.example의 위임 정보로 “프로모트”한다. 이때 사용자는 위임 정보를 수동으로 유지할 필요가 없다. 하지만 BIND 9는 하위 영역의 정보와 부모 영역의 정보를 섞지 않는다. 그래서 bar.example 슬레이브가 영역 전송을 요구하면, foo.bar.example NS 레코드는 보내지 않는다. 이는 또한 stub 영역에도 영향을 끼쳐서, BIND 9 네임 서버는 stub 영역의 NS 레코드를 부모 영역으로 “프로모트”하지 않는다. 물론 사용자가 stub 자식 영역이 있는 모든 부모 영역의 네임 서버를 설정할 수 있다. 7. BIND 9는 다중스레드이다. 만약 다음으로 BIND 9를 구축하지 않으면,

./configure --disable-threads

다중스레드인 네임 서버가 생긴다. 이로써 사용자의 네임 서버는 컴퓨터가 사용하지 않는 CPU를 이용할 수 있게 된다. 하지만 ps의 결과물이 다소 혼란스럽다:

% ps ax | grep named 6052 ? S 0:00 /usr/local/sbin/named 6053 ? S 0:00 /usr/local/sbin/named 6054 ? S 0:00 /usr/local/sbin/named 6055 ? S 0:00 /usr/local/sbin/named 6056 ? S 0:00 /usr/local/sbin/named 6318 pts/0 S 0:00 grep named

왜 이런 불필요한 프로세스가 나타나는 것인가? 이는 스레딩에 따른 부가적 산물일 뿐이다. 위에서 각각의 스레드는 프로세스 리스트의 별개 프로세스로 나타나므로, 전혀 걱정할 필요는 없다. 어쨌든 네임 서버를 멈추거나 리로드하려면 named에 신호를 전송하지 말고, rndc를 사용한다는 것을 상기하자. 8. BIND 9는 네임 검사(name checking)를 지원하지 않는다. BIND는 도메인 네임에서 받아들이는 문자가 없기 때문에, 일부에서는 BIND 9를 불필요하다고 여긴다. 하지만 버전 4.9.4부터 8을 거쳐 BIND의 전 버전은 네임 검사를 수행하며, 호스트(BIND에서 호스트는 “주소 레코드가 있는 도메인 네임”을 의미한다)를 가리키는 도메인 네임의 불법적인 문자를 금지한다. 합법적인 문자는 기호와 문자, 숫자, 그리고 대시를 사용한다. 이와 달리 BIND 9는 네임 검사를 하지 않는다. 도메인 네임에서 사용자는 밑줄을 비롯해, 원하는 어떤 문자라도 사용할 수 있다. 하지만 현재 많은 리졸버(resolver)가 네임 검사를 하고 있으며, 이상한 문자가 있는 도메인 네임을 리졸브하지 못한다. 9. BIND 9 개발자는 이전 버전의 개발자와는 다른 곳에서 작업한다. 과거에는 bind-users mailing list에서, 그리고 유즈넷 뉴스그룹인 comp.protocols.dns.bind에서 BIND 개발자를 자주 볼 수 있었다. named.conf의 구문에 관련한 문제라면 이쪽으로 도움을 청하자. 수 분 내에 응답을 받을 수 있을 것이다. BIND 9 개발자는 좀더 배타적인 bind9-users mailing list에서 작업한다. (뉴스그룹은 아직 없다.) BIND 9에 관련된 문제가 있으면, 여기에 문의하면 된다. 그리고 문의하기 전에 mailing list"s archive나 searchable archive를 먼저 찾아보자.

---

크리켓 리우는 DNS and BIND, 그리고 DNS on Windows NT의 공동 저자이며, Managing Internet Information Services의 주된 저자이기도 한다. 최근에는 버전 8.2.3와 9.1.0을 다루는 DNS and BIND, 제 4판의 집필을 끝냈다.

---