MySQL 파라메터 중
skip_name_resolve





MySQL 레퍼런스를 보면


"skip_name_resolve를 적용하게 되면 MySQL 서버가 클라이언트들의 접속시 DNS LOOKUP 과정을
생략시킨다."



 


덧붙여서 인터넷에 있는 글들을 본다면 "그러므로 속도가 빠르다" (인터넷 대부분의 글들) ...... 라고
설명이 되어 있다.



 



오라클은 접근 하려는 스키마의 ID와 패스워드를 알고 있는 상태에서 각 서버간의 네트워크 접근 권한만 허용된다면,


리스너를 통해 마음대로 접속할 수 있다. ( 물론 sqlnet.ora 파일에 접근 제한 설정이 안된 상태)



 


하지만 그와 다르게 MYSQL은 DB가 자체적으로 ID PASSWORD
그리고 IP(HOST)를 체크한다.


위 3가지 조건 중 하나라도 만족을 하지 못한다면, DB에 접근 할 수 없다.



 


MYSQL의 계정 권한이 저장된 USER 테이블을 조회한다면 이러한 결과값을 볼수 있다.


(또한 hash 함수로 암호화 저장 되어 있는 password를 볼 수 있다.)



 


mysql> select user, host , password from
mysql.user;
+----------+---------------------+-------------------------------------------+
|
user | host |
password
|
+----------+---------------------+-------------------------------------------+
|
root | localhost |
*E74858DB86EBA20BC33D0AECAE8A8108C56B17FA |
| repl |
% | *A424E797037BF97C19A2E88CF7891C5C2038C039 |
| dumpuser
| 192.168.100.100 | *56C09388C92050AD66D96D207790DFBA76CD410B |


| testuser | kthcorp |
*56C09388C92050AD66D96D207790DFBA76CD410B
|
+----------+--------------------+-----------------------------------------------+



 


해당 계정들을 대상으로 하여서 서버로의 접근 상황을 예로 든다면


일단 해당 ID와 패스워드를 모두 알고 있다고 하여도 모든 계정들의 접근에는 제한이 있다.


왜냐하면 host 컬럼에 등록된 IP 권한들이 모두 다르기 때문이다.



 


1. root 계정의 경우 localhost 로 등록되어 있어서 로컬에서만 접근이 가능하다.


(보안상 root는 로컬에서만 접근하도록 허용하는 것이 좋다.)



 


2. repl 계정의 경우 %로 되어 있다.


%는 어디서 접근을 하던지 간에 무조건 id와 패스워드만을 알고 있다면 접근을 허용 해준다.



 


3. dumpuser의 경우 192.168.100.100이라는 곳에서만 접근을 허용 해준다.



 


4. testuser의 경우 kthcorp라는 호스트를 가진 클라이언트가 접근 요청시에만 허용
해준다.



 


위의 1,2,3 의 경우는 모두 MYSQL 서버가 클라이언트 접근 요청시 자체적으로 판단이 가능하다는 것을 알 수 있다.


하지만 4번의 경우 MYSQL이 kthcorp 라는 호스트명을 가진 서버가 어느 서버인지를 알 수가 없다.



 


그러므로 4번 testuser 계정이 접근을 요청할 경우,


MySQL 서버는 먼저 /etc/hosts 파일에서 kthcorp라는 호스트명을 가진 서버의 ip를 체크하여 접근을 허용해준다.



 


가상의 시나리오를 한가지 생각하자면,


MySQL 서버에 저러한 host명으로 등록된 계정들이 굉장히 빈번하게 접근할 경우,


그 때마다 MYSQL은 일일이 hosts 파일을 체크하며, 접근을 제한하려 하므로 서버에는 부하가 생길 것이다.


그러므로 skip_name_resolve 라는 파라메터를 설정하여 이러한 룩업 과정을 생략함으로,


서버에 접근 부하를 줄일수 있다고 한다면 이 얼마나 좋은 상황인가.....?



 


하여 직접 테스트를 해보았다.


결론은 skip_name_resolve 파라메터를 적용한다면, 위의 룩업 과정을 생략한다.


그런데 중요한 점은 인증 과정을 생략하고 접근을 허용해주겠다는 의미가 아니라,


이러한 인증 없이 그냥 HOST로 등록된 계정들은 무시하겠다는 의미이다....


그러므로 skip_name_resolve 파라메터를 적용한 순간부터는 HOST명으로
등록된 계정들은 모두 서버에 접근할 수 없다.


(localhost, ip, %로 등록된 계정만 접근할 수
있다)



 



일반적으로 DBA 조직이 운영하는 서비스 DB에서는


산발적으로 개별 클라이언트들을 모두 MySQL 서버로 붙게 하는 구성은 하지 않을
것이다.


DB 앞단에 존재하는 WAS 서버에서 커넥션을 조절하며, 관리를
하기에


이러한 skip-name-resolve와 관련된 이슈 사항을 접할 일은 사실상 흔치 않을 것이다.



 



/etc/hosts 파일과 mysql.user 테이블의 상호 연관성 테스트 시나리오



 


1. MySQL 서버 hosts 파일에 등록된 클라이언트 서버의 host ip 부분을 삭제 한후,


클라이언트에서 host로 등록된 계정 접속을 시도할 경우 접근이 불가능함을 알 수 있다.


단 최초 mysql 서버 오픈 이후 이미 인증한 hosts에 한해서는 hosts 파일을 삭제해도 접근이 가능함을 알 수 있다.


(메모리에 host 정보 기록됨)



 


2. skip_name_resolve 설정된 MySQL 서버에 /etc/hosts가 등록된 계정으로도 접근 불가능함을 알 수
있다.

=====================================================================
출처:http://www.cyworld.com/oracooler/9179996

2012/12/20 16:16 2012/12/20 16:16
샤이 이 작성.

Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다

Trackback RSS : http://www.worldwalker.co.kr/rss/trackback/120

Trackback ATOM : http://www.worldwalker.co.kr/atom/trackback/120


당신의 의견을 작성해 주세요.

: 1 : ... 15 : 16 : 17 : 18 : 19 : 20 : 21 : 22 : 23 : ... 134 :