제공 : 한빛 네트워크
저자 : Ron Aitchison
역자 : 추홍엽
원문 : Five Basic Mistakes Not to Make in DNS
여기에 있는 내용은 여러분의 DNS를 좋은 상태로 유지하고 여러분을 비롯한 인터넷의 평안을 위해 문제를 일으키지 않게 할 다섯가지 것들이다.
DNS는 정말로 중요하다
이메일을 받을때, 웹페이지를 볼때, VoIP 전화를 할때, 혹은 다른 많은 임무를 수행할때 우리는 도메인 네임 시스템(DNS)을 사용한다. 그래서 DNS는 인터넷의 핵심적인 인프라의 일부라 할 수 있다.
이 글은 DNS 인프라구조에 불필요한 부하를 덜어냄으로써 여러분과 여러분의 조직이 안전할 수 있는 다섯가지 것들을 설명한다.
- DNS에서의 사설 IP 주소(RFC 1918)에 대한 역매핑
- 로컬호스트가 정매핑이나 역매핑이 되어 있는가를 확인하라.
- 도메인 명이 헛다리 정보를 가지고 있지 않은지 확인하라.
- 공개 재귀 네임서버(Open Recursive Name Server)를 돌리고 있지 않은지 확인하라.
- SOA RR에 있는 이메일 주소가 정확한지 확인하라.
각각의 사항을 언급할때마다, 고쳐야할 점과 BIND 설정(named.conf), 혹은 지역파일(zone file)의 내용을 같이 포함했다.
DNS에 대한 몇가지 배경지식
DNS는 도메인 이름의 계층적 구조하에 작동하는 복잡하고 매우 분산된 시스템이므로, 간단히 몇몇 배경지식을 언급할 필요가 있을 것 같다.
기술적으로 말해, DNS는 최종적으로 IP주소가 얻어질 때까지 인증 DNS 서버에 연속된 질의를 날려서 이름(도메인명)을 IP주소로 해석한다. 이 과정은 정매핑으로서 참조되며 지역(zone)이라 불리는 단위로 행해지는데, 이 지역은 도메인명 계층 구조의 각 단계에 대응된다. www.example.com 이라는 이름을 해석하기 위해, 로컬 DNS 서버는 이름 내의 각 단계에 대해 인증 DNS에게 질의를 날릴 것이다. 이는 루트-서버로 시작하며 이 서버는 .com의 인증 서버인 gTLD 서버에 대한 참조를 반환할 것이다. gTLD서버는 질의를 받았을때 example.com 도메인에 대한 인증 네임서버로의 참조를 반환할 것이다. 이 서버는 최종적으로 우리가 필요한 IP주소를 반환하게 된다. 때로는 IP 주소로 시작하고 그 주소에 할당된 이름을 찾는것이 유용할때가 있다; 특히 이메일 시스템은 스팸방지의 일부로 이 기술을 사용한다. DNS는 IP주소를 조작하고 역도메인명인 IN-ADDR.ARPA 하에서 역매핑 지역을 사용하여 IP주소를 이름으로 변환한다.
DNS 서버에는 두가지 광범위한 계층이 있다:
- 로컬 네트워크 상이나 거대한 조직--말하자면 하나의 ISP--내에서 하나의 사용자 그룹을 위해 운영되고, 재귀적 서비스로 호출된 것을 제공하는 DNS서버. 이러한 DNS 서버들은 질의를 만들어내고 클라이언트가 필요한 대답을 얻게 하기 위해 어떤 참조라도 따를 것이다. 이런 DNS 서버들은 보통 같은 질의가 반복해서 생기는 것에 대해 시간을 아끼기 위해 해당 질의에 대한 응답을 캐시로 유지한다. 이런 이유로 이들은 종종 캐싱 네임 서버 혹은 재귀 네임 서버, 가끔은 해석기(resolvers)라고도 불린다. DNS 레코드들은 각 리소스 레코드(RR)와 관련된 TTL(Time to Live)값들에 의해 정해진 기간동안 캐시에 유지된다.
- 지역에 대한 마스터 또는 슬레이브로 정의된 DNS 서버. 질의에 대한 응답 내에서 이러한 서버들에게 얻어진 리소스 레코드들은 그것들이 인증 자원으로 부터 온것임을 가리키기 위해 특별한 비트(AA)와 함께 표시된다. 이러한 서버들은, 별로 놀랄일도 아니지만, 보통 인증 네임 서버라고 불린다.
현재, 가끔씩 헷갈리는 DNS의 특성으로 인해, 일부 기관(특히 작은 곳일수록)들은 같은 네임서버에서 캐싱과 인증의 두 기능들을 같이 운영한다. 잠시뒤에 설명할 이유로 인해 이는 별로 추천하는 방법은 아니지만, 단순히 실용적인 해결방법으로 볼 수도 있다. 마지막으로, 각 PC는 가끔이지만 잘못된 해석기(resolver)를 가지고 있는데 이것은 보통 그 결과들을 캐쉬한다. 사실 이것은 거의 항상 이어지는 참조행위가 불가능하기 때문에, 효율적으로 운영하기 위하여 캐싱 네임서버나 재귀 네임서버의 서비스를 필요로 하는 형식적인 해석기이다.
루트 서버는 언제나 모든 새로운 질의 주기의 시작점이다. 그래서 루트 서버는 가장 중요한 인프라구조중에서도 가장 중요한 부분인 것이다! 13개의 루트 서버가 존재하는데 a.root-servers.net부터 m.root-servers.net까지 이름지어져 있다. 애니캐스트(anycast) 기술을 사용하여 이 서버들은 전세계적으로 복제되어 있다. 현재 족히 100개의 인스턴스가 넘는 다양한 루트 서버가 운영용으로 쓰이고 있으며, 이들 중 대부분이 현재 북미지역 바깥에 위치하고 있다. 루트 서버는 하루에 20억개 이상의 질의를 받고 있으며, (일부 연구에 따르면[6]) 이들 중 단지 2퍼센트만이 적법한 쿼리다! 절대 다수의 불필요한 트래픽이 소프트웨어 버그와 잘못된 방화벽 설정에 관계되어 있는 반면, 잘못 설정된 DNS 소프트웨어에 의해 발생되는 것도 꽤 된다.
이제 이러한 모든 정보들을 입수했으니, DNS 인프라구조 상에서 불필요한 트래픽을 줄이기 위해 체크해야할 다섯가지 DNS 이슈들을 살펴보고 여러분의 조직이 더 부드럽게 돌아갈수 있게 도움을 주도록 하자.
사설 IP 주소(RFC 1918)에 대한 역매핑
일부 루트 서버에 도달하는 전체 트래픽의 7퍼센트가 사설 IP 주소에 대한 역(reverse) 질의로 구성되어 있고, 완전한 라우팅 인프라구조(AS112)는 이런 문제를 다루기 위해 구축되어 왔다. 사설 IP 주소는 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 범위 내에 있는 모든 주소이다. ISP들은 범용 IP에 대한 역매핑의 임무를 맡아왔지만 사설 IP에 대해서는 어떠한 책임도 없다. 여러분이 만약 여러분만의 로컬 재귀 네임서버를 돌리고 있다면, 이러한 IP들이 여러분의 DNS 설정에 확실하게 역매핑 돼있게 해야 할 책임이 있다.
역매핑을 지역으로 설명하기 위해, 192.168.5.0/28(16개의 IP주소만)의 사설 주소 범위를 사용하고 있다고 가정해보자. BIND의 named.conf 파일은 역매핑된 지역을 정의하고 다음과 같은 모습을 하고 있어야 한다:
// named.conf fragment
zone "5.168.192.IN-ADDR.ARPA" IN {
type master;
file "192.168.5.rev";
allow-update {"none";};
allow-transfer {192.168.5.6;}; // ip address of zone slave
}
위의 지역 파일명 규칙은 이해하기 쉽게 만들기 위해 192.168.5.rev를 사용한 반면, 지역 이름은 반드시 5.168.192.IN-ADDR.ARPA이어야 한다. 그러나 여러분이 만약 정말로 역주소를 작성하는 것을 즐긴다면, 파일명으로 "5.168.192.in-addr.arpa"을 사용할수도 있다. 역매핑은 표준 지역 파일이며 슬레이브(세컨더리) 네임서버를 갱신하기 위해 지역 변환을 사용한다. allow-transfer문은 단순히 슬레이브 네임서버로 오는 지역변환 요청 자원을 제한한다. allow-update문은 예방책이며, DHCP나 다른 자원으로부터 자동 갱신하고 있다면 제거되어야 한다. 역지역 프래그먼트는 다음과 같을 것이다:
; reverse map for 192.168.5.0/28
$ORIGIN 5.168.192.IN-ADDR.ARPA.
; Start of Authority (SOA) record defining the key characteristics of the zone
@ IN SOA ns1.example.com. hostmaster.example.com. (
2007040800 ; serial number
12h ; refresh
15m ; retry
3w ; expiry
2h ; min = minimum
)
; name servers Resource Records for the domain
IN NS ns1.example.com.
IN NS ns2.example.com.
; A RRs for name servers are not glue and therefore
; not necessary
; PTR RR maps an IPv4 address to a host name
2 IN PTR ns1.example.com.
3 IN PTR ns2.example.com.
4 IN PTR mail.example.com.
.....
14 IN PTR joe.example.com.
이 파일에서 오른편에 있는 모든 이름들은 반드시 완전한 도메인명(Fully Qualified Domain Names, FQDNs)이어야 한다. 즉 이 이름들은 마침표(.)로 끝나야 한다. 만약 mail.example.com의 끝에 있는 마침표가 생략되면 $ORIGIN 치환규칙이 mail.example.com.5.168.192.IN-ADDR.ARPA라는 이름을 생성해낼 것인데 이런건 아마도 원했던 결과가 아닐것이다.