한빛출판네트워크

제공 : 한빛 네트워크
저자 : Ron Aitchison
역자 : 추홍엽
원문 : Five Basic Mistakes Not to Make in DNS

[이전 기사 보기]
DNS에서 하면 안되는 기본적 실수 5가지(1)

로컬호스트의 정매핑과 역매핑 여부 확인

한 연구에 따르면 루트 서버에 오는 질의의 1퍼센트 이상이 로컬호스트를 찾는 것이었다. 연구에서 예를 든 사례를 보면, 이것은 전체 루트 서버 질의 부하량의 일부이고 로컬호스트 지역 정의가 안된 DNS설정이 12,000건이 넘었다. 로컬호스트는 많은 어플리케이션에서 로컬 PC를 참조하는 축약형으로 사용되어 지고 항상 루프백 주소인 127.0.0.1(혹은 IPV6에서는 ::1)로 매핑되어 있다. 불필요한 루트 서버 트래픽을 발생시키는 외에도 이것은 어플리케이션의 속도를 현저하게 저하시킨다. 로컬호스트(그리고 그 역매핑)를 해석하기 위해 BIND named.conf 파일은 다음의 지역 파일을 가지고 있어야 한다:

// named.conf fragment
// forward map zone of localhost
zone "localhost" IN {
 type master;
 file "master.localhost";
 allow-update {"none";};
 allow-transfer {192.168.5.6;}; // ip address of zone slave
}
// reverse map zone of IPv4 localhost
zone "0.0.127.IN-ADDR-ARPA" IN {
 type master;
 file "localhost.rev";
 allow-update {"none";};
 allow-transfer {192.168.5.6;}; // ip address of zone slave
}

로컬호스트 정매핑 지역파일은 보통 대부분의 BIND 배포판에 localhost 혹은 localhost.zone라는 이름으로 공급된다. 역매핑 지역파일--이것도 역시 일반적으로 BIND 배포판과 함께 공급된다--은 보통 named.local과 같이 뭔가 매우 의미있는 이름을 가지는데, 이것이 왜 12,000개가 넘는 환경설정에서 생략되어지는지를 설명하는데 도움이 될 것이다. 로컬호스트 지역은 위에서 보여진 것처럼 마스터/슬레이브 설정(allow-transfer 문이 전송 요청 자원을 제한하기 위해 사용되는 경우)으로 다뤄진다. 그러나 대부분의 경우 지역파일이 BIND와 함께 배포되기 때문에 모든 경우에서 마스터로 정의되는 것이 보통이다.

대부분의 BIND 배포판과 함께 공급되는 정매핑 지역 파일은 지나치게 줄여쓰고 이해할 수 없게 되어 있는 걸작인데 전형적인 예는 다음과 같다:

$TTL 86400
$ORIGIN localhost.
@  1D  IN    SOA @ hostmaster (
             0 ; serial
             12h  ; refresh
             15m  ; retry
             1w ; expiry
             3h ; minimum
     )
@  1D  IN  NS @ ; localhost is the name server
   1D  IN  A  127.0.0.1 ; always returns the loop-back address

기능적으로 동일하게 바꾼 지역파일 형식이 좀 더 이해하기 쉬울 것이다. 안바꾸면 그땐 좀 더 이해하기 어려울 것이고!

$TTL 1d ; 24 hours could have been written as 24h or 84600
$ORIGIN localhost.
localhost.    IN    SOA localhost. hostmaster.localhost. (
             2007040800 ; serial
             3H ; refresh
             15M ; retry
             1w ; expire
             3h ; minimum
     )
localhost.     IN  NS localhost. ; localhost is the name server
localhost.     IN  A  127.0.0.1 ; the loop-back address

역방향 매핑된 지역 파일은 다음과 같아야 한다:

$TTL 86400 ; 24 hours
$ORIGIN 0.0.127.IN-ADDR.ARPA.
@       IN      SOA     localhost. hostmaster.localhost.  (
                        2007040800 ; Serial number
                        3h      ; Refresh
                        15      ; Retry
                        1w      ; Expire
                        3h )    ; Minimum
        IN      NS      localhost.
1       IN      PTR     localhost.

도메인명에 헛다리 정보가 없게 하라

헛다리 정보(lame delegation)란 인증 응답을 하지 않는 지역에 대한 NS 리소스 레코드에서 정의된 네임서버를 의미한다. 즉, 이것은 지역에 대한 질의 응답에서 AA 비트를 설정하지 않는다. 이는 보통 둘 중 하나의 이유로 생긴다. 지역이 어떤 이유로 로딩에 실패할 수 있는데, 이 경우 BIND의 로그에 문제가 생긴다. (혹은 여러분이 지역 파일을 검증하기 위해 named-checkzone 유틸리티를 실행했을지도 모른다.) 아니면 도메인에 대해 NS RR에 정의된 하나 이상의 네임서버에 지역 구절이 설정되지 않았다. 아래의 지역 파일 일부는 도메인에 대한 두개의 네임서버를 보여준다. BIND의 named.conf 파일은 양 네임 서버(형태는 마스터나 슬레이브가 될 수 있다)에 "example.com"에 대한 지역 구절이 반드시 있어야 한다. 그렇지 않으면 헛정보가 생길 것이다:

; fragment of example.com zone file
$ORIGIN example.com.
; name servers Resource Records for the domain
; the ns1 is inside our domain, ns2.example.net
; is in another domain
; both name severs must be configure with a zone clause
; for example.com in BIND"s named.conf
          IN      NS      ns1.example.com.
; out of domain name server
          IN      NS      ns2.example.net.
; normal A RR for the in domain name server
ns1       IN      A       192.168.5.2

몇가지 깔끔하게 짚고 넘어가야할 점이 있다. 도메인에 대한 마스터 서버와 모든 슬레이브 서버는 도메인에 대한 질의에 인증 응답을 할 것이다. 그러므로 SOA RR을 보는 방법을 제외하고는 마스터와 슬레이브 응답을 구분할 수가 없다. 캐싱 네임서버는 지역에 대해 마스터나 슬레이브 서버가 될 수 없으므로, 인증 네임 서버로부터 DNS 리소스 레코드 데이터를 처음 읽었을때 AA 비트를 가지고 응답할 것이다. 만약 이것이 캐시로부터 RR을 가지고 온다면 AA 비트는 설정되지 않을 것이다. 더 명확하게 설명하자면 캐싱 네임 서버는 도메인에 대해 인증을 할 수 없다. 도메인에 대해서는 BIND의 named.conf 파일에 지역 구절을 가진 네임 서버만이 그 도메인에 대한 인증을 할 수 있다.

헛다리 정보는 두 가지 이유에서 좋지 않다. 첫째, 이것은 인증 응답을 찾기 위해 지역의 네임서버에 대해 재질의를 일으키며, 이것은 불필요한 네트워크 부하를 가중시킨다. 둘째, BIND가 친절하게도 헛정보에 대해 로그를 남기기 때문에 여러분이 정말 원치 않았던 이유로 순식간에 유명해질 수 있다. 헛정보를 피하라!

공개 재귀 네임서버를 운영하고 있지 않은지 확인할것

공개 재귀서버를 돌리는 것--이것은 근본적으로 어디서나 누구라도 여러분의 네임서버를 사용해서 재귀 질의를 수행할 수 있다는 것을 의미한다--은 매우 나쁜 생각이다. 첫째, 이것은 필요한 것보다 많은 재귀 질의를 일으킴으로써 캐시 중독(거짓 DNS 데이터를 악의적으로 주입하는 것)의 가능성을 증가시킨다. 근본적으로 모든 질의는 캐시 중독의 잠재적인 근원인데 뭣하러 해야할 것보다 많은 것을 하는가.

둘째, 훨씬 중요한 이유로, 공개 DNS는 공격받는 지역에 대한 질의들이 요청됨으로써 서비스 거부와 같은 공격을 증폭시키는데 사용될 우려가 있다. 슬프게도, 공개 메일 전달과 함께 주변사람들과 친해지기 위해 사용되는 것들이 잠재적으로는 인터넷에서의 다른 모든 사람들에게는 해를 끼칠 수 있게 되었다. 재귀 질의를 일으키는 기능을 완전히 제거하던지 재귀질의를 허용된 사용자들만 사용하게 제한하라. 다음의 BIND named.conf 일부에 모든 방법들이 나와있다:

// if you are running an authoritative only server
// the following statement should always be present
recursion no;

캐싱 네임서버나 인증과 캐싱이 혼합된 네임서버를 위해(권장사항은 이 두가지를 혼합하지 않는다는 것을 기억하라), 아래의 두 방법중에 하나를 사용한다:

// mixed authoritative and caching server
// use an appropriate local address scope statement
// to limit recursion requests to local users
allow-recursion {192.168.2.0/24;};
//
// if you run only a caching name server use this method
// use an appropriate local address scope statement
// to limit all query requests to local users
allow-query {192.168.2.0/24;};

기억하라: 공개된 DNS = 매우 안좋은 생각이다. 이것을 가장 높은 우선순위로 다루고 만약 여러분의 서버가 공개 DNS인것이 발견된다면 가능한한 빨리 고쳐라.

이메일 주소가 SOA RR에 올바로 되어 있는지 확인할 것

속담처럼, 뭔가 일어났다. 하늘이 금지한, 사람들에게 문제를 일으키는 지역을 여러분이 사용하고 있을지 모른다. 모두를 위해, 특히 여러분을 위해 지역에서의 이메일이 제대로 되어 있고 기능을 하고 있는지 확인하라. SOA 리소스 레코드(RNAME 필드라고도 부른다)에는 지역에 대해 책임을 지고 있는 사람의 이메일이 다음처럼 정의되어 있다:

@         IN      SOA   ns1.example.com. hostmaster.example.com. (
                        2007040800 ; serial number
                        12h         ; refresh
                        15m        ; retry
                        3w         ; expiry
                        2h         ; min = minimum
                        )

위 의 예제에서, 보여지는 이메일 주소는 (RFC 2142 에서) 권장되고 있는 hostmaster(hostmaster.example.com로 명시되어 있음)이다. 그러나 이것은 여러분이 신속하고 확실하게 메일을 받을 수 있는 아무 유효한 이메일 주소라도 괜찮다. 이것은 어떤 필요한 개선안에도 신속히 응답할 수 있다는 것을 의미하며, 이로 인해 올해의 네티즌상을 받을수 있을지도 모른다.

약간의 DNS 부속실을 가지자

DNS 시스템은 20년 이상동안 잘 동작해 왔고, 모든 종류의 유쾌하지 않은 문제에도 불구하고 계속해서 동작한다. 그럼에도 불구하고, 우리 모두가 가능한 한 이런 재미없는 것들을 제거하는 역할을 확실히 수행하려는 것은 이기심일지도 모른다. 가끔이지만 진짜 문제가 터지면, DNS 인프라 구조는 그 문제를 고치거나 흡수해버리기 위해 약간의 부속실(headroom)을 가지고 계속해서 인터넷을 즐겁게 돌리게 될 것이다. 이것이 우리 모두가 원하는바 아닌가. 조용한 삶 말이다.

참고자료

1. RFC 4697 Observed DNS Resolution Misbehavior (www.ietf.org/rfc.html)
2. ISC OARC (oarc.isc.org)
3. IEPG (www.iepg.org)
4. Cooperative Association for Internet Data Analysis (www.caida.org)
5. Root-server web site (www.root-servers.org)
6. Wow that"s a lot of Packets (dns.measurement-factory.com/writings/wessels-pam2003-paper.pdf)

---

저자 Ron Aitchison은 Pro DNS and BIND (Apress, 2005)의 저자이다. 이 책은 DNSSEC.bis 보안 업데이트에 대해 설명하는 DNS에 관한 첫번째 책이며, 정신이 멍해질 정도로 내용이 자세하다.