발단은 http://blog.1day1.org/333 여기서부터 시작인데, 최소한 상황을 재현(?)할 수 있게 되었다.
정확한 원인이 내쪽에서내쪽에서 찾을 수는 없을 것 같고, 최종적으로 YDN 쪽에서 답을 줘야 할할 듯 하다.
아무튼 상황재현과 그 간의 시도를 리포트 한다.
일단일단 이전 상황은 http://t.1day1.org/post/177433640 여기까지 진행했었다.
즉, 도메인을 체크할 때, 제대로제대로 데이터를 가져가는 것을 확인할 수 있었다.
그런데, 왜 안될까? 뭔가 파일파일 체크 이외에 더 확인하는 작업이 있다는 것인데...
여기서 부터 상상의 나래(?)를나래(?)를 펼치며 테스트하게 된다.
몇가지 가능성을 따져봤다.
1. 웹서버의 문제.
2.2. 서버 자체의 문제 혹은 OS(배포판) 문제.
3. 그외의 알 수 없는없는 문제.
1,2 는 여러서버를 바꿔가면서 테스트 해보기로 했다.
apache2 ,, lighttpd , nginx 를 바꿔가면서 테스트 했다.
서버는 웹호스팅, 서버호스팅 등등 계정을 바꿔가며 테스트 해보았다.
제일먼저 웹서버를 변경하면서 테스트테스트 해봤다.
웹서버 테스트. 각각의 헤더를 살펴보면서 체크를 했다.
(동일서버에서 웹서버를 변경하여 테스트 했다.)
(동일서버에서 웹서버를 변경하여 테스트 했다.)
펼쳐두기..
lighttpd
HTTP request sent, awaiting response...
HTTP/1.0 200 OK
Connection: keep-alive
Content-Type: text/html
Accept-Ranges: bytes
ETag: "2038624153"
Last-Modified: Mon, 07 Sep 2009 14:35:42 GMT
Content-Length: 0
Date: Mon, 07 Sep 2009 14:49:51 GMT
Server: lighttpd/1.4.19
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html.1'
nginx
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: nginx/0.6.35
Date: Mon, 07 Sep 2009 14:44:17 GMT
Content-Type: text/html
Content-Length: 0
Last-Modified: Mon, 07 Sep 2009 14:35:42 GMT
Connection: keep-alive
Accept-Ranges: bytes
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
apache2
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 14:45:40 GMT
Server: Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.2 with Suhosin-Patch
Last-Modified: Mon, 07 Sep 2009 14:35:42 GMT
ETag: "cc190-0-472fdc3ac8b80"
Accept-Ranges: bytes
Content-Length: 0
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html.1'
HTTP request sent, awaiting response...
HTTP/1.0 200 OK
Connection: keep-alive
Content-Type: text/html
Accept-Ranges: bytes
ETag: "2038624153"
Last-Modified: Mon, 07 Sep 2009 14:35:42 GMT
Content-Length: 0
Date: Mon, 07 Sep 2009 14:49:51 GMT
Server: lighttpd/1.4.19
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html.1'
nginx
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: nginx/0.6.35
Date: Mon, 07 Sep 2009 14:44:17 GMT
Content-Type: text/html
Content-Length: 0
Last-Modified: Mon, 07 Sep 2009 14:35:42 GMT
Connection: keep-alive
Accept-Ranges: bytes
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
apache2
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 14:45:40 GMT
Server: Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.2 with Suhosin-Patch
Last-Modified: Mon, 07 Sep 2009 14:35:42 GMT
ETag: "cc190-0-472fdc3ac8b80"
Accept-Ranges: bytes
Content-Length: 0
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html.1'
여기까지 바꾸면서 발급을 시도해도 계속 실패가 되었다.
그래서 서버자체의 문제인가 싶어, 다른 계정에서 테스트 해보기로 했다.
실패하던 서버는 Ubuntu(우분투) 이고, 따로 테스트하려는 계정은 Centos 이다.
펼쳐두기..
centos - apache.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 15:30:24 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Mon, 07 Sep 2009 15:28:27 GMT
ETag: "3d0385-0-472fe80529cc0"
Accept-Ranges: bytes
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
centos 다른 계정.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 16:03:44 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Mon, 07 Sep 2009 15:58:01 GMT
ETag: "d0b74-0-ea0fb440"
Accept-Ranges: bytes
Content-Length: 0
Connection: close
Content-Type: text/html
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 15:30:24 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Mon, 07 Sep 2009 15:28:27 GMT
ETag: "3d0385-0-472fe80529cc0"
Accept-Ranges: bytes
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
centos 다른 계정.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 16:03:44 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Mon, 07 Sep 2009 15:58:01 GMT
ETag: "d0b74-0-ea0fb440"
Accept-Ranges: bytes
Content-Length: 0
Connection: close
Content-Type: text/html
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
다른 계정 Centos 에서는 되는 것이었다.
둘다 우분투쪽도 apache 인데, 웹서버가 아니라 OS 배포판의 문제였단 말인가?
좀 생각을 해봤다.
그래서 둘의 apache 설정이 다른 부분이 있어서일까? 헤더를 보면서 차이점을 살펴봤다.
Keep-alive 문제일까? charset 문제일까? 등등 차이가 있는 부분은 설정을 바꿔가며 테스트 해봤다.
펼쳐두기..
charset 은 아닌듯. keep-alive 도 상관없는 듯.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 16:05:43 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Mon, 07 Sep 2009 15:58:01 GMT
ETag: "d0b74-0-ea0fb440"
Accept-Ranges: bytes
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
keep-alive 를 없애고 해보자.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 15:37:26 GMT
Server: Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.2 with Suhosin-Patch
Last-Modified: Mon, 07 Sep 2009 15:37:06 GMT
ETag: "cc140-0-472fe9f41ec80"
Accept-Ranges: bytes
Content-Length: 0
Vary: Accept-Encoding
Connection: close
Content-Type: text/html
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
utf-8 charset 지정. 문제일까?
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 15:40:55 GMT
Server: Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.2 with Suhosin-Patch
Last-Modified: Mon, 07 Sep 2009 15:38:35 GMT
ETag: "cc140-0-472fea48ff4c0"
Accept-Ranges: bytes
Content-Length: 0
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=UTF-8
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
Vary: Accept-Encoding 이 부분은 뭘까?
다른 웹호스팅 계정도 테스트.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 15:49:38 GMT
Server: Apache
P3P: CP='NOI CURa ADMa DEVa TAIa OUR DELa BUS IND PHY ONL UNI COM NAV INT DEM PRE'
X-Powered-By: PHP/5.2.5
Connection: close
Content-Type: text/html
Length: unspecified [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 16:05:43 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Mon, 07 Sep 2009 15:58:01 GMT
ETag: "d0b74-0-ea0fb440"
Accept-Ranges: bytes
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
keep-alive 를 없애고 해보자.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 15:37:26 GMT
Server: Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.2 with Suhosin-Patch
Last-Modified: Mon, 07 Sep 2009 15:37:06 GMT
ETag: "cc140-0-472fe9f41ec80"
Accept-Ranges: bytes
Content-Length: 0
Vary: Accept-Encoding
Connection: close
Content-Type: text/html
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
utf-8 charset 지정. 문제일까?
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 15:40:55 GMT
Server: Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.2 with Suhosin-Patch
Last-Modified: Mon, 07 Sep 2009 15:38:35 GMT
ETag: "cc140-0-472fea48ff4c0"
Accept-Ranges: bytes
Content-Length: 0
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=UTF-8
Length: 0 [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
Vary: Accept-Encoding 이 부분은 뭘까?
다른 웹호스팅 계정도 테스트.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Mon, 07 Sep 2009 15:49:38 GMT
Server: Apache
P3P: CP='NOI CURa ADMa DEVa TAIa OUR DELa BUS IND PHY ONL UNI COM NAV INT DEM PRE'
X-Powered-By: PHP/5.2.5
Connection: close
Content-Type: text/html
Length: unspecified [text/html]
Saving to: `JwiHkHpJfCXx1KeHgs7FfA--.html'
Centos 계정이외에 다른 계정은 모조리 실패하는 것이었다.
아! OS 의 문제로 결론을 내려야 하나? 뭔가 간과하는것이 있지 않을까?
뭔가 놓치고 있는 것이 있을거야! 곰곰히 생각한다.
어! 혹시!
안되는 계정은 모두 1day1.org 의 서브도메인 이었다.
되는 계정인 Centos 는 OOO.com 과 YYY.kr 의 도메인을 사용했었다.
설마 org 도메인이 안되는 것일까? 그래서 교차실험을 했다.
안되는 계정에 OOO.com 의 서브도메인으로 되는 계정에는 ooo.1day1.org 의 서브도메인으로 테스트 했다. 결과는 안되던 계정에 OOO.com 이 제대로 발급이 되었다. 또 되던 계정은 ooo.1day1.org 는 안되는 것이었다.
OTL
정말 그 문제란 말인가? 키 발급시에 도메인 자체도 테스트를 하는 것인가?
nslookup 또는 whois , dig 등을 체크해서 유효한 값을 체크하는 것인가?
그런데, 직접 쿼리를 날려봐도 별다른 차이점을 발견할 수 없었다.
org 도메인의 네임서버 설정이 잘못된 것일까? apache 로그를 보면 파일을 찾아서 가져가는(GET) 것을 볼 수 있다. 설정이 잘못되었다면 파일을 찾지 못할 것인데 말이다.
미궁에 빠지게 된다. 왜! 인지 알 수 없게 되었다.
상황을 재연까지는 하게 되었지만, 왜! 인지는 모르겠다.
여기서 끝내려 했다. 그런데 뭔가 이상했다.
이유가 뭐란 말인가?
안되는 1day1.org 와 되는 OOO.com 은 똑같이 dnsever.com 에 설정되어있다.
둘의 설정상의 차이가 뭐일까? 살펴봤다.
설마!
OOO.com 은
1차: ns1.dnsever.com1day1.org 는
2차: ns2.dnsever.com
1차: ns16.dnsever.com의 각각 다른 네임서버로 설정되어 있다는 차이가 있었다.
2차: ns34.dnsever.com
3차: ns83.dnsever.com
4차: ns231.dnsever.com
5차: ns259.dnsever.com
YDN 측에서 org 자체를 막거나 하지는 않았을 것이고, dnsever 쪽에서 네임서버 쿼리를 막도록 설정되어 있는 것일까? nslookup , dig 로 테스트 해보면 이상이 없는데 이상하다.
특정 IP 대역에 대해서 막아놨을까? (그럴지도 모르겠다.)
dnsever 가 기존 ns1,ns2 에서 ns16~ns259 등으로 분리를 시켜놓은게 예전 DDOS 공격을 당했을때 공격을 분산,회피 하기 위한 조치였던 것으로 알고 있다. 그렇다 보니 새로운 네임서버에 대해서 쿼리 권한을 제한했을 가능성이 많을 듯 하다.(org 가 막혔다는 것 보다 좀더 설득력이 있어 보인다)
최종 테스트는 되는 다른 도메인을 ns16,ns34 등으로 바꿔보고, 1day1.org 를 독립네임서버로 바꿔보거나 ns1,ns2 의 예전 네임서버로 바꿔서 교차 테스트를 해보면 명확한 답이 나올 듯 싶다.
최종 테스트가 예상대로 나오게 된다면 ns16~ns259 의 어떤 설정 문제일 듯 하다.
dnsever 쪽 문제라고 해도 좀 이상한 부분이 있다.
YDN 쪽에서 검증파일(?) 만 체크하는 것이 아닌 듯 한데, 그에 대한 언급이 있어야 할 듯 하다.
분면 검증파일을 확인했으면서 체크오류를 내는 것은 문제가 있어 보인다.
그 확인사항이 정확히 무엇인지 모르겠지만, API KEY 발급상에서는 그에 대한 언급이 없다.
ps. 현재 최종테스트를 위해 네임서버를 변경해 두었다. 적용되려면 최소한 반나절,하루 정도가 걸리기 때문에 아직 테스트 할 수 없다.