접속 지연현상에 대한 유용한 글입니다. 접속 지연 현상을 극복하는
방법은 2가지가 있습니다. 하나는 tcp-wrapper 를 조작하는 방법이고
또하나는 named 를 운영할 경우 reverse zone 을 적절하게 속이는 방
법입니다.
1. TCP-WRAPPER 조작하기
강제로 소스를 수정해서 reverse lookup 을 하지 않게 하는 방법
입니다.
소스의 Makefile 중
HOSTNAME= -DALWAYS_HOSTNAME
부분을 주석 처리합니다. 그리고 컴파일을 합니다. 만약 컴파일중
에러가 발생하면 Makefile 에서
CFLAGS = -DFACILITY=$(FACILITY) $(ACCESS) $(PARANOID) $(NETGROUP) \
$(BUGS) $(SYSTYPE) $(AUTH) $(UMASK) \
-DREAL_DAEMON_DIR=\"$(REAL_DAEMON_DIR)\" $(STYLE) $(KILL_OPT) \
-DSEVERITY=$(SEVERITY) -DRFC931_TIMEOUT=$(RFC931_TIMEOUT) \
$(UCHAR) $(TABLES) $(STRINGS) $(TLI) $(EXTRA_CFLAGS) $(DOT) \
$(VSYSLOG) ${HOSTNAME)
부분을 찾아서
CFLAGS = -DFACILITY=$(FACILITY) $(ACCESS) $(PARANOID) $(NETGROUP) \
$(BUGS) $(SYSTYPE) $(AUTH) $(UMASK) \
-DREAL_DAEMON_DIR=\"$(REAL_DAEMON_DIR)\" $(STYLE) $(KILL_OPT) \
-DSEVERITY=$(SEVERITY) -DRFC931_TIMEOUT=$(RFC931_TIMEOUT) \
$(UCHAR) $(TABLES) $(STRINGS) $(TLI) $(EXTRA_CFLAGS) $(DOT) \
$(VSYSLOG)
로 수정을 하신 다음 컴파일을 하면 됩니다. 이렇게 수정된 tcp-wrapper
는
ftp://mirror.oops.org/pub/Linux/UPDATES/ 에서 RH 6.x 용과 7.x 의
rpm package 를 구하실 수 있습니다.
2. named 를 이용해 reverse zone 을 속이기
제목: tcp wrapper, resolv.conf 와 telnet, ftp간의 관계
일자: Sat May 19 08:38:10 KST 2001
작성: 장우현 <
whchang
inempire.com>
1. 문제제기
Linux를 이용하는 이용자들이 이런 이야기를 할 때가 있습니다.
"이상하게 telnet 이나 ftp를 이용할 때 login prompt가 나올 때까지
걸리는 시간이 매우 길다. 30초에서 60초 가량. 그런데, login 후부터
느리지는 않다. web 접속 및 전송속도는 양호하다".
본인도 2000년 5월에 이러한 문의를 접하고 문제점이 무엇일까 원인을
찾아보려고 노력을 했었습니다. 그리고, 결국 원인을 찾아 대처를
했었습니다. 그런데 관련 문서를 만들지 않고 있었는데 오늘 다시
동일한 문의가 있어서 이제는 미루지 말고 만들때가 되었구나라고
판단이 되어 이 글을 씁니다.
2. 힌트
위 문제의 원인은 tcp wrapper, resolv.conf, 그리고 국내 몇몇 ISP들이
DNS 서버를 올바르게 운영하지 못하는 것들이 복합되어서 나타나는
것입니다. 그것에 대해서는 다시 언급하겠습니다.
만약 제기된 문제점을 해결하려면 tcp wrapper를 이용하지 않거나,
resolv.conf를 교묘하게 처리하거나, 아니면 국내 몇몇 ISP들이
DNS 서버를 올바르게 운영해주면 됩니다. 그러나, 국내 몇몇 ISP들이
DNS 서버를 올바르게 운영해 주길 바라는 것은 (지난 몇년간의
경험을 바탕으로 판단하건데) Non-sense입니다.
따라서 서버를 운영하는 자신이 tcp wrapper와 resolv.conf를 조작해야만
합니다.
3. NT, Windows 2000 서버는 tcp wrapper를 이용하지 않으므로 관계없음.
tcp wrapper를 이용하는 서버만 해당.
* 국내에서 많이 이용하는 Redhat Linux를 기준으로 설명하겠습니다.
Redhat Linux를 기본으로 설치하면 telnet, ftp, pop3 등은
tcp wrapper (/usr/sbin/tcpd)의 영향을 받게 됩니다.
/etc/inetd.conf를 뒤져보면 아래와 같은 것을 볼 수 있습니다.
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
만약 tcpd의 영향을 받지 않으려면 다음과 같이 수정을 하면 됩니다.
ftp stream tcp nowait root /usr/sbin/in.ftpd
telnet stream tcp nowait root /usr/sbin/in.telnetd
pop-3 stream tcp nowait root /usr/sbin/ipop3d
그러나, tcpd를 삭제해 버리면 접근제한(access control)을 할 수 없게
되는 단점이 있으므로 권장하고 싶은 사항은 아닙니다. 그러므로,
tcp wrapper가 어떻게 동작하는지를 이해하여 문제를 해결해 나갈 필요가
있습니다.
참고로 NT, Windows 2000 서버는 tcp wrapper를 이용하지 않으므로
여기에서 말하는 문제는 없습니다.
4. TCP wrapper의 역할
서버address 3.3.3.3
/usr/sbin/tcpd in.telnetd
/etc/resolv.conf
nameserver 127.0.0.1
PC-address 2.2.2.2
2.2.2.2에 대한 reverse zone을 갖고 있다고 지정된
DNS서버 1.1.1.1
만약 PC가 서버에 telnet으로 접근을 하게 되면 서버의 tcpd는 PC의
address 2.2.2.2에 대해서 reverse lookup을 합니다
(본인도 tcp wrapper에 대해 상세하게 모르지만 reverse lookup을 하는
것만은 확실합니다).
참고: www.inempire.com ---> 210.124.122.135 : forward lookup
210.124.122.135 ---> www.inempire.com : reverse lookup
서버안에서 발생하는 모든 DNS lookup은 /etc/resolv.conf에 지정된
nameserver로 전달됩니다. 이 예에서는 서버 자신입니다.
서버의 DNS 설정을 살펴보면 자신이 2.2.2.2에 대한 reverse
lookup을 담당하는 서버가 아님을 알게 됩니다. 따라서, PC address에
대해 reverse lookup query 과정을 실시하게 됩니다 (이 과정은 일반적인
forward lookup 과정과 100% 동일합니다). DNS cache에 어떤 정보가
남아 있는지에 따라 조금씩 다르지만 최종적으로 2.2.2.2에
대한 reverse lookup을 담당하는 DNS server까지 도달하게 됩니다.
그런데 만약 최종 DNS server 1.1.1.1이 자신은 2.2.2.2에 대한
reverse zone file을 갖고 있다고 선언되어 있지 않다면 어떻게 될까요?
그 경우 최종 DNS server 1.1.1.1은 서버 3.3.3.3 과 마찬가지로
2.2.2.2에 대한 reverse query를 하게 됩니다. 그 query는 서버
1.1.1.1로 다시 돌아오게 되므로 결국 looping이 발생하게 됩니다.
이 경우 서버 3.3.3.3은 계속 reverse query가 끝나기를 기다리고
있습니다. 그러나 무한정 계속 기다릴 수는 없어 일정시간(timeout)이
지나면 reverse lookup을 포기하게 됩니다.
(질문: 이 timeout은 tcp wrapper에서 지정된 timeout일까요?
아니면 reverse lookup의 timeout일까요?)
그리고 PC 2.2.2.2에게 login prompt를 전달하게 됩니다. 따라서,
reverse lookup에 문제가 있는 경우 PC 2.2.2.2는 서버 3.3.3.3으로
부터 login prompt를 받을 때까지 30~60초가량 기다려야만 하는
것입니다.
5. 국내 몇몇 ISP들의 DNS Server 운영 문제점
가. 위 4.에서 발생된 문제는 해당 IP address를 관리하는 ISP가 자신의
DNS Server에 reverse zone을 선언해 놓지 않았기 때문입니다.
모든 PTR record를 선언해 놓는 것이 어렵기 때문에 그것까지는
필요없다고 하더라도 반드시 reverse zone은 선언해 놓아야 합니다.
나. reverse zone은 선언해 놓았더라도 reverse lookup이 자주
실패하는 상태로 DNS server를 운영하는 경우도 문제입니다.
이런 경우 어떤 때는 접속이 빠르다가 바쁜 오후 혹은 저녁에 login
prompt를 전달받기까지 걸리는 시간이 들쭉날쭉하게 됩니다.
DNS server를 잘 구성해 운영해 주길 희망합니다.
6. 목마른 사람이 우물을 판다
위 5.에서의 언급한 사항을 잘하고 있는 국내 ISP는 많지 않습니다.
따라서, 내가 문제를 스스로 해결할 수 밖에 없습니다.
문제를 해결하는 방법은 크게 2가지가 있습니다. 첫번째는 tcp wrapper의
기능을 off시키는 것이고, 두번째는 reverse lookup 과정을 조작하는
것입니다. 첫번째는 access control이 필요한 경우 할 수 없으므로
두번째에 대해서 서술하겠습니다.
2가지 방법(아래 7. 과 8.)이 있습니다.
7. reverse lookup을 자기(서버 3.3.3.3)가 모두 직접 처리하게 함
서버 3.3.3.3이 자신이 모든 IP address에 대해 reverse lookup에 대한
master라고 선언하여 reverse query가 다른 서버로 전달되지 않게 하는
방법입니다. 이것의 장점은 신속하게 reverse query에 대한 reply를
받게 되므로 PC에게 빨리 login prompt를 전달해 줄 수 있습니다. 단점은
traceroute, tracert, 혹은 기타 필요에 의해서 reverse lookup이 필요한
경우 hostname을 알 수 없다는 것입니다.
방법은 간단합니다. 그러나 조금은 무식합니다. 그러나 확실합니다.
* 아래 문법이 조금 틀릴 수 있으니 주의하세요.
o named.conf에 모든 IP address에 대해 자기가 master라고 선언
zone "1.in-addr.arpa" {type master; file "zone.1.in-addr.arpa";}
zone "2.in-addr.arpa" {type master; file "zone.2.in-addr.arpa";}
zone "3.in-addr.arpa" {type master; file "zone.3.in-addr.arpa";}
......생략........
zone "223.in-addr.arpa" {type master; file "zone.223.in-addr.arpa";}
o 해당 reverse zone file을 생성해 줌
$ more zone.1.in-addr.arpa
@ IN SOA ns.haha.com root.ns.haha.com (
2 ; serial number
10800 ; refresh
3600 ; retry
86400 ; expire
21600 ) ; minimum TTL
@ NS ns.haha.com.
@ NS ns2.haha.com.
1.1.1 PTR dummy.haha.com.
$ ln -s zone.1.in-addr.arpa zone.2.in-addr.arpa
$ ln -s zone.1.in-addr.arpa zone.3.in-addr.arpa
$ ln -s zone.1.in-addr.arpa zone.4.in-addr.arpa
....... 생략 ......
$ ln -s zone.1.in-addr.arpa zone.223.in-addr.arpa
* PTR record는 1개 밖에 선언하지 않았습니다.
아무 의미없는 것입니다. 마음대로 하세요.
8. 위 가.의 서버를 /etc/resolv.conf에 등록하기만 하면 됨
$more resolv.conf
nameserver 3.3.3.3
9. 인터넷제국의 고객들께
위 7.에서 제시한대로 해도 되고, 8.에서 제시한대로 인터넷제국의
DNS server를 resolv.conf에 등록을 해도 됩니다.
이상입니다. 도움이 되기를 바랍니다.
댓글을 달아 주세요