시스템이야기2010. 11. 11. 22:04
커피닉스(coffeenix.net)의 '범냉이'님이 dig과 nslookup툴을 사용하여, resolv.conf에서 지정한 DNS 서버가 죽었을 경우 timeout시간은 어떻게 되는지 테스트를 하셨다. 테스트한 글은 '커피닉스'에 'DNS 질의 TimeOut의 진실은..'  에 정리되어 있다.

lookup

※ 이미지 출처 : 구글 'domain lookup' 이미지 검색


resolv.conf에 지정한 DNS서버 중 한대가 응답이 없을 때, DNS 요청의 timeout은 5초일까? 1초일까?
왜 이런 궁금증을 갖게됐을까? /usr/include/resolv.h에는 RES_TIMEOUT은  5초로 설정되어 있다. 하지만 dig이나 nslookup으로 테스트한 결과는 1초였기 때문이다.

1) Primary 정상, Secondary 정상
2) Primary 비정상, Secondary 정상
3) Primary 정상
4) Primary 비정상

위 4가지 상황에 대한 테스트 결과는 범냉이님의 글을 읽어보면 결과를 확인할 수 있다.
이후, 추가적인 실험은 제가 넘겨받아 하게 됐다. 자세한 글은 '커피닉스'의 'DNS 질의 TimeOut의 진실은.. (2번째)' 에 쓰여있고, 여기에는 간단하게 요약해서 적었다.

1. dig, nslookup에서는 왜 timeout이 1초인가?

결론적으로는 bind 소스내의 dig과 nslookup툴은 resolv.h의 설정값을 사용하지 않는다. dig소스의 dig.h에 timeout이 1초(#define SERVER_TIMEOUT 1)로 정의되어 있기 때문이다.

2. 만약 resolv.conf에 지정한 모든 서버가 응답이 없다면 dig, nslookup의 timeout 결과는?

정리하면 다음과 같다.
1) resolv.conf에 나열된 서버간 요청 대기는 1초(SERVER_TIMEOUT)
2) 나열된 모든 서버 요청 후 retry시 대기는 5초(UDP_TIMEOUT)
3) retry 횟수는 3번이다.

resolv.conf에 지정한 서버 대수에 따라서,

1) 1대일 때 응답없다면 : 5초 + 5초 + 5초 = 총 15초 소요.
2) 2대일 때 모두 응답이 없다면 : 1초+5초  +  1초+5초  +  1초+5초 = 총 18초 소요
3) 3대일 때 모두 응답이 없다면 : 1초+1초+5초  +  1초+1초+5초   +  1초+1초+5초 = 총 21초 소요

3. gethostbyname() 함수, ping 프로그램 테스트 결과는?

gethostbyname()함수를 사용하는 C프로그램이라면 지금까지 설명한 resolv.h와 resolv.conf을 따르게 된다. 대표적인 것이 ping일 것이다.

resolv.conf에 지정한 DNS서버에서 ICMP응답을 받을 수 있느냐 없느냐에 따라서 대기시간(timeout시간)은 달라지게 된다.

ICMP Port Unreachable

ICMP Port Unreachable (UDP Port 53)


1) ICMP응답이 온다면, timeout없이 바로 다음 서버로 요청을 한다.
2) ICMP응답이 없다면, timeout동안(5초) 대기하다가 다음 서버로 요청을 한다.

4. 효과적인 resolv.conf 설정

만약 resolv.conf에 지정한 첫번째 네임서버(또는 네임서버 VIP) 자체가 죽는다면 ICMP 응답을 못받을 것이다. 따라서 응답시간을 줄이고자 한다면 resolv.conf에서 timeout시간을 줄여주는게 더 나은 대비책이 될 것이다.

options timeout:1 attempts:2 또는
options timeout:1 attempts:1

하지만 resolv.conf 설정을 사용하지 않는 프로그램도 있다. 모든게, resolv.conf 설정대로 될 것이라는 믿음은 절대 금물.

Posted by 좋은진호
IT이야기2009. 4. 28. 23:27
국내 몇몇 주요 사이트의 도메인 정보가 25일(토)에 변조된 사건이 발생했다. 상태(Status) 정보, 관리책임자(Administrative Contact)정보, 기술책임자(Technical Contact)정보 등이 변경되었다. 다행인 것은 네임서버 정보는 변경되지 않았다는 것. 만약 이 정보까지 변경됐다라면 큰 난리가 생겼을 것이다. 랭키닷컴 기준으로 1위~100위 사이트 중 .com, .net 도메인과 그외 추가로 몇개를 whois 검색했다. 총 7개 도메인에서 특이한 점이 보였다.

  • daum.net
  • hanmail.net
  • n------.com
  • c------.com
  • c------.com
  • d------.com
  • i------.com (도메인 길이에 상관없이 '-' 갯수를 임의로 통일해서 표기함)

daum.net 도메인을 살펴보자. daum.net의 whois는 DomainTools whois  또는 godadday whois  등을 포함하여 여러 whois 사이트와 whois 명령으로 살펴보았다.

daum.net whois

[ 2009.4.28현재 daum.net whois 결과 ]


daum.net whois

[ 2009.4.28현재 daum.net whois 결과 ]



1. 최종 갱신일(Updated Date)을 보면 4.25(토)이다. 변조는 토요일에 발생났다. 위 도메인 모두 그렇다.

   Updated Date: 25-apr-2009

2. Status정보가 특이하다.

   Status: clientDeleteProhibited
   Status: clientRenewProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Status: serverDeleteProhibited
   Status: serverRenewProhibited
   Status: serverTransferProhibited
   Status: serverUpdateProhibited

   일반적으로 ok로 표시되거나 clientTransferProhibited 이나 clientDeleteProhibited, clientUpdateProhibited 정도의 상태 정보만 표시가 되는데, client... 로 시작하는 것 4개와, server... 로 시작하는 상태 정보까지 보인다. 이는 1) 도메인 정보를 악의적으로 변경한 자가 더이상 도메인 정보를 변경할 수 없도록 금지(Prohibited)시켰거나,  2) 도메인업체에서 관리기관에서 더이상 누군가 변경을 못하도록 임시로 보호조치를 취했을 것 같다. daum.net의 3.5일 갱신 정보에는 clientDeleteProhibited, clientTransferProhibited, clientUpdateProhibited 이렇게 3개 상태 정보만 갖고 있었다.

참고로 google.com이나 yahoo.com은 clientRenewProhibited 과 serverRenewProhibited를 제외한 6개의 Status를 갖고 있다.

3. Administrative Contact 정보와 Technical Contact 정보가 모두 아래와 같이 변경되어 있다. 도메인 소유 업체의 정보가 나와야할 것인데, 엉뚱한 정보뿐이다. 그리고, 얼핏보면 메일주소가 미국 업체Godaddy인 것처럼 보인다.

      Tigran, Arutunyan  domain.godaddy@yahoo.com
      Domain
      537 Seabright Ave.
      Santa Cruz, California 95062
      United States
      +1.4965784      Fax --


위의 3가지 도메인 정보때문에 변조되었을 것으로 추정한 것이다. 7개 도메인이 모두 같은 '국내 도메인 등록업체'(의심가는 서비스 업체가 있으나 얘기하지는 않겠음)일 가능성이 있다. 그리고, 그 등록업체의 문제로 인해 변조되었을 것이다. whois의 history정보를 볼 수 있다면 좀 더 명확해질텐데, 비용이 발생해서 볼 수가 없다. ^^ whois 정보로만으로 제3자 입장에서 파악하는게 쉽지가 않다. 한가지는 확실하다. 국내 대표 사이트의 도메인 정보가 이렇게 나온 경우는 본 적이 없다.



* 도메인 변조 관련

----------------------------------------------------
2009.6.4(목) 추가 사항

* 도메인 상태 코드(Status Code)에 대한 자세한 것은 '도메인 정보의 숨겨진 비밀, 상태 코드'를 보시길 (2009.5.28, 글 좋은진호)
Posted by 좋은진호
IT이야기2008. 3. 20. 23:10
사용자 삽입 이미지
[ 이미지 출처 : 세팡 서킷 홈페이지 ]
F-SECURE의 'Formula 1 racing and computer security' 글에 따르면 말레이시아의 F1 경기장인 세팡 인터내셔널 서킷(Sepang International Circuit)이 DNS 해킹당했다고 한다. www.malaysiangp.com.my 접속하면 순간 'Hijack by CuciOtak' 메시지를 뿌려주는 페이지가 나왔다고 한다. (현재는 도메인을 못찾아서 접속 안됨) 해커가 도메인 관리 비밀번호(이를테면 도메인 관리 사이트의 로긴용 ID/PW)를 알아냈거나 사회 공학기법(보이스피싱 등등)을 이용해서 DNS서버를 ns1.oxyhostsfree.com, ns2.oxyhostsfree.com로 변경한 것으로 추측하고 있다.

This change has happened just hours ago - perhaps by the hacker guessing a password for the DNS management system or by using social engineering to get a provider to change the DNS ip address.

사용자 삽입 이미지

실제 ns1~ns2.oxyhostsfree.com DNS서버에서는 malaysiangp.com.my 도메인 설정이 없는 것으로 보인다. 현재 lookup해 본 결과 IP를 찾지 못한다. DNS trace 해봤는데, IP를 찾지 못한다.
... 생략 ...
malaysiangp.com.my.     86400   IN      NS      ns1.oxyhostsfree.com.
malaysiangp.com.my.     86400   IN      NS      ns2.oxyhostsfree.com.
;; Received 120 bytes from 61.6.38.139#53(ns5.jaring.my) in 196 ms

;; Received 36 bytes from 64.191.50.45#53(ns2.oxyhostsfree.com) in 253 ms

정상적인 서버의 IP는 202.157.186.171 이다. DNS lookup만 못했을 뿐 접속해보면 정상적으로 잘 나온다.
whois 결과 다음과 같이 나왔다. 'Record Last Modified'시간이 최근으로 변경되어 있다.
a [Domain Name]             malaysiangp.com.my
b [MYNIC Registration No.]  D1A021681
c [Record Created]          03-OCT-2001
d [Record Expired]          03-OCT-2009
e [Record Last Modified]    19-MAR-2008

k [Primary Name Server]
  ns1.oxyhostsfree.com     64.191.50.36        SVA016558
l [Secondary Name Server]
  ns2.oxyhostsfree.com     64.191.50.45        SVA016559

혹시나 저 URL이 공식 홈페이지는 아닐까 싶어서 구글에서 'Sepang Circuit'로 검색해봤다. 검색 결과 첫번째 나오고, 위키페디아에서도 저 URL로 표시되었다. 공식 홈페이지가 맞다.

이런 DNS해킹을 보면, 비밀번호는 역시 추측하기 어려운 것으로 해야한다는 것과 사회공학적 기법으로 인한 피해를 입지 않도록 주의해야한다는 것을 일깨워준다. 요즘 보이스피싱의 증가 추세라고 한다. 우리세대보다 부모님세대가 걱정이다. 며칠전에도 부모님에게 전화오면 조심하라고 말씀드렸지만, 다시 한 번 말씀드려야 겠다.

Posted by 좋은진호
시스템이야기2007. 2. 16. 00:05
매일경제 DNS의 SPF 레코드 설정에 잘 못된 부분이 있다. SPF는 메일주소를 위조해서 보내는 것을 방지하기 위한 스팸 필터링 정책중의 하나로, SPF에 대한 자세한 것은 '스팸필터링을 위한 SPF 설정과 운영'에 적어둔게 있으니 참고하기 바란다.

설정 실수와 관련하여
- 지난 1월에 메일을 4번(1.9, 1.13, 1.17 2번)
- 매일경제 홈페이지의 '서비스 문의'에서 2번
을 알려드렸으나 수정이 없었다. 제가 직접적으로 접근할 방법이 없는 관계로 이 글을 읽고, 매경쪽에 아시는 분이 있면 전달해 주기를 바라면서...

DNS lookup한 결과이다.

$ dig mk.co.kr txt

; <<>> DiG 9.2.4 <<>> mk.co.kr txt
;; global options:  printcmd

... 생략 ...

;; QUESTION SECTION:
;mk.co.kr.                      IN      TXT

;; ANSWER SECTION:
mk.co.kr.               86400   IN      TXT     "v=spf1 ip4:220.73.139.52 ipv4:220.73.139.81 ip4:220.73.139.82 ip4:220.73.139.201 ip4:203.238.57.9 ipv4:203.238.57.6 ~all"

;; AUTHORITY SECTION:
mk.co.kr.               86400   IN      NS      ns.mk.co.kr.
mk.co.kr.               86400   IN      NS      ns2.mk.co.kr.

위의 'ipv4:220.73.139.81' 과 'ipv4:203.238.57.6' 은 'ip4:220.73.139.81' 과 'ip4:203.238.57.6' 로 수정해야 한다. ip4를 ipv4로 잘 못 표기한 것이다. @mk.co.kr 에서 오는 메일을 받는 분 중에서는 경우에 따라 필터링되어 못 보는 경우가 생길 수 있다. (못 보는 경우가 있다는 것은 수신측 필터링 강도(softfail까지 모두 필터링해라)에 따라 달라질 수 있음을 의미함) 저는 매경 메일을 whitelist에 넣어서 잘 받고 있지만, 읽고 싶어도 필터링되어서 못 읽는 안타까운 분들이 없기를 바라는 맘이다.

SPF 레코드를 설정하신 엔지니어는 1) 본인의 설정은 잘 못된 것은 없는지, 2) 그리고 송신할 메일서버의 IP는 빠짐없이 SPF 레코드에 등록을 했는지 다시 한번 확인해보기 바란다.


Posted by 좋은진호
IT이야기2007. 2. 9. 11:13
RIPE NCC의 DNSMON 페이지를 보면 13 root DNS 서버중에 g.root-servers.net와 l.root-servers.net DNS서버에서 대략 12시간정도 공격을 받은 것으로 보입니다. 06번이 G root서버 (DDN 관리), 11번이 L root서 버 (ICANN 관리)입니다. L root서버는 중간에 공격이 줄었다가 재차 공격을 시도를 했습니다.
 
* RIPE NCC의 DNSMON 페이지 (root DNS, 2007.2.5~2.7, 48시간)
사용자 삽입 이미지

org DNS 서버는 tld1.ultradns.net, tld2.ultradns.net, tld3.ultradns.org, tld4.ultradns.org, tld5.ultradns.info, tld6.ultradns.co.uk 6대가 골고루 공격을 당했습니다.
 
* RIPE NCC의 DNSMON 페이지 (org DNS, 2007.2.5~2.7, 48시간)
사용자 삽입 이미지

 
Team Cymu의 DNS Query Time Graph에는 정확히 확인하기 쉽지 않지만 G root 서버에서 Response Time이 그 시간대에 순간 올라갔음을 확인할 수 있습니다.
 
* DNS Query Response Time Graphs (Chicago, g.root-servers.net)
[ Tokyo와 Chicago와 회선에서 체크한 결과 ]
사용자 삽입 이미지
사용자 삽입 이미지

기사에도 나와있네요. ^^*. 처음 보도때는 없던데, 글을 늦게 쓰다보니깐 이러네요. ^^*
 
* 인터넷 백본, 집중 공격에도 난공불락임을 입증 ( Zdnet, 2007.2.8 )

DNS 시스템을 겨냥한 것으로 보이는 데이터는 6일 오전 2시 30분(미국 시간)에 집중적으로 쏟아지기 시작했다. 람잔은 “여러 대의 루트 서버에 트래픽이 폭발적으로 증가했다. 미 국방성에서 가동하는 「G」서 버와 ICANN에서 가동하는 「L」서버가 주로 공격을 받은 것 같다.”고 말했다. ICANN의 크레인 역시 그런 느낌을 받았다고 확인해주었다.
 
* 참고 : Huge DNS attack goes virtually unnoticed


Posted by 좋은진호