geekforum: DNS를 개선하려 한다면?
글쓴이: geekforum / 작성시간: 금, 2001/05/18 - 12:25오후
요즘 이리저리 서핑중에 외국 보안 그룹 로프트의 연설중 "인터넷은 10년도 더 된 낡은 기술이기 때문에 계속적인 문제가 발생한다" 라고 써있더군요.
그래서 이런저런 생각을 해보니 인터넷 구조를 다시 설계하면 어떨까 하는 생각이 들게 되었습니다. 제가 이런 생각을 하게 만든것은 DNS의 존재입니다. 만약 몇개의 최상위 DNS가 뻗어버리면 아예 전멸되는게 인터넷 도메인네임의 구조이다 보니 그런 생각이 자꾸 들고, 자주 터지는 BIND의 보안 문제 역시 심각한 수준이라고 생각합니다. 그래서 지금의 인터넷의 개발과 발전방향을 고려하여, 좀더 안정적인 구조의 인터넷을 구축하기 위해서 도메인네임 리졸빙 부분을 새로 설계한다고 했을때 어떤 방식으로 현재의 구조를 대체하거나 개선할 수 있을까 하는 토론을 했으면 합니다. 물론 다른 프로토콜 까지 토론할 수도 있겠지만 여기선 DNS를 대체/개선할 수 있는 뭔가 획기적인 아이디어에 대해서 우선 토론했으면 합니다. 과연 어떤 것이 대안이 될 수 있을까요? 과연 어디를 어떻게 수정을 하거나 다시 설계해야 지금과 같은 피라미드 구조의 DNS를 탈피할 수 있을까요?
Forums:
http://www.ietf.org에서 세계적인 석학들이 열분들이 지적하
http://www.ietf.org에서 세계적인 석학들이 열분들이 지적하신
문제를 해결하기위해..이시점에서도 뎔쉬미 워킹하고 있습니다.
현재는 구조의 변경도 중요하지만 인증시스템의 강화가 더 중요
하지 않을까..생각됩니다.
-이상- ^^*
dns는 트리형식을 취하고 p2p는 평행적인 관계가 아닌 가요.(제가 잘
dns는 트리형식을 취하고 p2p는 평행적인 관계가 아닌 가요.(제가 잘 몰라서) 만약 그러하다면 꼭 dns를 바꾸는 것 보다는 dns와 p2p를 병행하여 사용하는 것이 좋은 방향이 아닐지...
또 tcp/ip방식 자체를 완전히 교체하는 것도 문제가 있지 않을까요. 그 대안이 되는 방식이 나왔다 하여도 현재 전세계적으로 쓰고 있는 방식을 순식간에 교체하는 것도 문제가 있고 단계적으로 교체한다고 해도 그에 따른 또다른 시행착오가 발생하여 한동안 인터넷이 어지러워 지지 않을까 생각합니다.
또 하드웨어적으로 현재 사용중인 이더넷이 새로운 방식을 지원을 해야 하는데 만약 지원을 하지 못하는 상황에서 다른 방식이 나오고 이를 실행한다면 엄청난 혼란을 야기하지 않을까 생각합니다.
(제가 쓴 내용 맞는지 모르겠네요..개인적인 생각일 뿐)
문제는 현재의DNS구조가 문제가 아니라 tcp/ip프로토콜 문제가아닌
문제는 현재의DNS구조가 문제가 아니라 tcp/ip프로토콜 문제가
아닌가요
이너넷이 이렇게 성장하리라고는 1960년대 그 어느누구도 예상치 못한
결과입니다.지금 많은 문제가 대두되고 있죠
이너넷2라고 미국의 몇몇 대학과 연구소에서 개발하고있고
ip6 또한 개발중인걸로 알고있읍니다.
그치만 ip6가 현실화된다고 해도 문제는 많죠..
현재 ip4로 되어있는것들을 모두 ip6로 한번에 바뀐다면야 좋겠지만..
그것도 불가능하죠..
그 대안으로 ip6와 ip4의 중간쯤되는 단계 역시..난해합니다..
dns구조 역시 이걸 바꾼다고 하면은 캬..엄두가 안나겠죠..
보아 아니 별로 IPV6에 대해서 별로 모르시는 분 같은데IPV6
보아 아니 별로 IPV6에 대해서 별로 모르시는 분 같은데
IPV6는 IPV4와 완벽한 호환을 이룹니다.
우리나라에서는 IPV6를 2002년부터 도입하기 시작해서 2005년까지 완전하게 도입하기로 한 상태입니다.
우리나라도 IP부족국가 중에 하나니깐 중요한 문제죠...
ipv6는 개발 중이 아니라 벌써 나와있습니다. 사람들은 이미 1995년
ipv6는 개발 중이 아니라 벌써 나와있습니다. 사람들은 이미 1995년경에 ip주소가 모자를 것을 예상하고 ITF에서 ipv6에 관한 개발에 착수 이미 표준안은 다 나와있습니다. 주소가 128bit 였던걸로 기억하는데.. (교수님 표현으로는 전세계 모든 사람의 세포 하나하나에 ip 주소를 부여할 수 있다고 하시더군요..) ipv4에서 ipv6로 넘어가는 문제 또한 ipv6 내에 고려되어 있습니다. 문제라면 그 수많은 백본 라우터들을 교체해야 하고 프로토콜들을 교체해줘야 한다는 거겠죠.. 프로토콜 교체는 간단할 것 같군요.. 걍 ms에서 새 OS에다가 껴넣어주면 될테니..
교수님의 표현이 너무 강하신거 같은데요.정확한 표현이 아마 화성
교수님의 표현이 너무 강하신거 같은데요.
정확한 표현이 아마 화성 표면에 1평방미터당 5개의 ip를 부여할수 있다는
것일거고..
(지구 보다 화성이 더 크죠 훨씬.. 정확한 표현이 기억 안납니다. 죄송.)
표준안은 다 나왔지만 그에 따르는 기술개발(주로 QOS-VoIP관련, 무선 통신
환경 따위) 문제가 이제야 해결되고, 외국 및 현재 국내의 경우 교육망을
위주로 5개 대학에서 환경을 구축해 테스트와 연구를 하고 있습니다.
(기사를 올해 초에 읽은거 같은데 전자신문에서 ipv6해보세요. 숭실,카이스트,포항 정도였던가..)
또 정부 지원의 경우 세계에서 일본에 이어 두번째로 정부 차원에서의 지원이
약속되었습니다. 망하면.. 이런..
언급하신거와 소프트웨어의 교체는 별 문제가 되지 않습니다. 이미 리눅스나
여타 유닉스 계열도 다 지원하고 windows도 지원을 합니다. (98은 모르겠네요)
그래서 하드웨어가 새로운 시장이 만들어 진다는...
한가지 간과하고 있는 사실이 있습니다.DNS는 IP 주소를 사람이
한가지 간과하고 있는 사실이 있습니다.
DNS는 IP 주소를 사람이 인식하기 쉬운 도메인 네임으로 혹은 그 반대로 번역해주는 거대한 분산 데이타베이스입니다.
인터넷 초기에는 /etc/hosts파일을 통해서 이러한 역할을 대신했고 서버가 들어날수록 이들 파일을 동기화하는 것이 문제가 되었죠. 그 대안으로 DNS가 나온것이구요.
P2P는 DNS와는 전혀 별개의 문제입니다. P2P가 네임 리졸빙과 무슨 관련이
있는지 이해할 수가 없군요.
아마 DNS Daemon으로 가장 널리 사용되는 BIND의 보안문제를 지적하신 것 같은데요. 그렇다면 새로운 BIND를 개발한다던가 하는 방향이 더 나을 것 같습니다. 한국어 같은 다국어를 지원하도록 DNS 프로토콜을 개선하고 보안문제를 해결할 수 있도록 패킷변조를 못하도록 한다거나... BIND의 캐슁 알고리즘을 개선하여 네트웍 트래픽을 줄인다거나...
P2P의 가장 대표적인 것이 스타크래프트이고C/S의 가장 대표적인것은
P2P의 가장 대표적인 것이 스타크래프트이고
C/S의 가장 대표적인것은 디아블로2입니다.
여기에서 우리가 느끼는 대로 생각하면 되지요.
상대적으로 스타크래프트 해킹이 더 쉽지요?
디아블로도 해킹이야 가능하겠지만 스타크래프트와 같은식의 해킹은 절대 불가능하지요.(맵핵,돈핵등등)
DNS보안이 문제라면 C/S인 지금 형태가 맞습니다.(물론 지금과 같이 하드웨어가 발달한 시점에서 굳이 트리구조를 갖을 필요가 없을것같아요. 국가마다 슈퍼 DNS서버 하나만 두어도 될텐데... 국가끼리의 서버는 미러링하구요.)
DNS성능이 문제라면 P2P를 생각해야 할텐데...
DNS는 성능이 문제이진 않거든요.
자룡님 말씀이 맞는것 같네요.현재 우리들이 사용하는 모든 주소와 같은
자룡님 말씀이 맞는것 같네요.
현재 우리들이 사용하는 모든 주소와 같은 것들이
모두 피라미드 형식으로 되어있는 것을 본다면
현재의 DNS구조가 가장 적절한 것 같습니다.
P2P는 특히 DNS에 적절한 대안은 아닌듯 싶습니다.^^;
그리고 구조상의 커다란 문제도 없구요. DNS서버가 폭주해서
뻗었다는말은 들어보지 못했거든요..
처음 이 토론을 제안하신 의도는 보안에 관련된 접근에서
시작되었다고 생각하면 DNS 구조의 변화 보다는 좀 더
하이레벨 적인 DNS 프로토콜 방식의 변화쪽이 더 필요한것
같습니다.
현재의 DNS구조는 DNS를 Spoofing할 수 있습니다.
한 클라이언트가 kldp.org 에 대한 query를 전송했다고
했을때 org에서 kldp를 찾아 ip를 전송하는 것이 아니라
다른 악의적인 사용자가 그보다 먼저 anwer를 클라이언트로
전송하면 그 클라이언트는 그 IP를 그대로 믿게 되어 그곳으로
접속하게 되겠죠..
그리고 BIND 문제는 BIND 프로그램 자체가 갖고 있던
취약점들로 BIND자체만 패치함으로써도 충분히 해결
되었고, 계속 그럴 것이라고 생각합니다..
DNS말고도 더 시급한 인터넷 자체가 갖는 문제들은 많겠죠..
TCP/IP 라는 것을 각각의 소프트웨어나 OS에서 implementation
하는 과정에서 OS마다 다른 점들이나 실수한 점들이
계속해서 등장할테고..그걸 또 찾아내서 취약성으로 악용하는
사람들도 늘어날테고...
계속 해서 패치할테고..
현재도 계속 인터넷은 RFC문서를 통해 새롭게
발전하고 있지요. 똑똑한 사람들이 그런 문서를 제시하고
만들어 나갈테니. 문제가 생겨서 인터넷이 망할 일은
없을겁니다.. 크크..그리고 10년전보다야 인터넷은
훨씬 견고해 졌다고 생각합니다~
그런데.. Spoofing까지 견뎌낼 수 있는 방법이 있을까요??TC
그런데.. Spoofing까지 견뎌낼 수 있는 방법이 있을까요??
TCP/IP 란 방법위에서 구현되는 한..
Spoofing에는 속수무책 아닌가요??
아랫분이 얘기하셨지만 P2P에서는 더 심해지겠지만..
네트웍상에 물려있는 컴퓨터(서버든 피어든)가 신뢰할 수 없다는
것까지 고려하려면 효율성 면에서 너무 많은 걸 잃어버리지 않을까요..
머 예를 들어서 DNS도 한 대여섯군데에서 정보를 받은 다음에
가장 많은 득표를 얻는 거를 옳은 정보로 취한다면...
별루 좋은 방법은 아닐 거 같네요..
P2P를 사용한다면....음 일단 하이브리드 방식의 P2P는 현재
P2P를 사용한다면....
음 일단 하이브리드 방식의 P2P는 현재의 DNS 와 별차이가 없을것같네요.
어차피 하이브리드 방식은 서버를 사용하잖아요.
피어가 서버에 쿼리를 날리고 해당 피어의 주소를 받아서 그 후에
그 피어와 직접연결되는 하이브리드 방식과
클라이언트가 DNS 에 쿼리를 날리고 해당 서버의 주소를 받아서 그 후에
그 서버와 직접연결되는 현재의 DNS 방식.
비슷하죠? ^^;;
그럼 퓨어방식을 써야되는데....
이럴러면 각 피어들은 밑에 자우랑님 말씀처럼 각 피어들이 DNS DB 를
가지고 있어야 될것 같네요.
만일 요청된 도메인이 자신의 DNS DB 에 없으면 자기와 연결된 피어에게
메시지를 날리고, 그걸 받은 피어는 자신의 DB를 검색하고 없으면
다시 다른 피어에게 날리고....
하지만 먼저 해결되어야 할것이
어떻게 각 피어가 적절한 DNS DB 를 유지할것인가...
퓨어방식의 문제점인 패킷의 범람을 어떻게 적절하게 조절할것인가...
새로운 도메인네임을 어떻게 기존의 p2p망에 연결할것인가...
이 문제를 해결한다고 할지라도 성능이나 기능면에서 현재의 DNS 방식보다
효율적일것인가...
...
...
개인적으론... 현재의 DNS 보다 못할것 같다는...
(패킷량은 현재보다 상대적으로 많아지고.. 해당 도메인네임의 IP를 찾기위해 들이는 노력이 너무 커진다는 생각이 드는군요.. )
뭐 P2P 에 대해 수박 겉핥기식으로 알고 있어서
제가 제대로 생각하고 있는건지는 모르겠습니다만...
제 생각은 이러네요. =)
-----
이글을 읽는 모든 이에게 평화가 함께 하기를... ^^;
P2P가 모든 대안인 것처럼 말씀들 하시지만,P2P의 가장 큰 문제중
P2P가 모든 대안인 것처럼 말씀들 하시지만,
P2P의 가장 큰 문제중에 하나는,
악의적인 (혹은 실수로) DNS정보를 조작하거나 변경할 수 있다는 겁니다.
예를들어, kldp를 쳤는데, 어쩌다가 서버를 잘 못 만나면
M$사이트가 접속될 수도 있다는 거죠.
아마도...중앙서버방식이나 P2P 그 이후에 또 뭔가가 나오겠죠? --;
(패러다임 전환이 필요해...이제 한계야 한계... --;)
저기요..DNS를 문제 삼은게 아니라라우터에 문제가 있다고 한건디
저기요..DNS를 문제 삼은게 아니라
라우터에 문제가 있다고 한건디요..
어느 한 라우터를 집중 공격함으로써...
인터넷의 마비를 만들수 있다..이런야그였음..
아래에서 의견을 제시했듯이 p2p가 해결책이고, 앞으로는 그런 방향으로
아래에서 의견을 제시했듯이 p2p가 해결책이고, 앞으로는 그런 방향으로 될것입니다.
흠 그러니까.. p2p로 구현되는 방식에 대해 조금 설명을 쿨럭
흠 그러니까.. p2p로 구현되는 방식에 대해 조금 설명을 쿨럭
오랜된 기술이라 위험하다는것은 dns보다는 현재 tcp/ip의 라우팅 체
오랜된 기술이라 위험하다는것은 dns보다는 현재 tcp/ip의 라우팅 체계등 tcp/ip고유의
문제인걸로 알고 있는데요...
만약 dns 구조를 혁신적으로 바꾼다 하더라도 tcp/ip 프로토콜이 그대로라면
이는 모래성위에 다시 집을 짓는경우와 무엇이 틀리겠습니까..?
tcp/ip체계를 싹 바꾼다는게 그리 쉬울 꺼 같지 않아서 모래성이라도
tcp/ip체계를 싹 바꾼다는게 그리 쉬울 꺼 같지 않아서 모래성이라도 파도에 견뎌보기 위한 토론을 하는거죠 :-) 혹시 압니까 모래성에 시멘트 보강공사 하면 파도에 견딜지 :-)
흠... p2p가 대안이 될수도 있겟군요. 흠 p2p라면 자체에도 도메인
흠... p2p가 대안이 될수도 있겟군요. 흠 p2p라면 자체에도 도메인 db를 가지고 흠 p2p로 된다면 인터넷에 연결된 모든 컴퓨터는 도메인 db를 가지고 있어야 하는건가요?
흠... 딱 와 닿지가 않아서 그러는데 p2p로 구현될수 있는 dns에 대해 설명좀 부탁드립니다 :-)
한가지 빠뜨린게 있는것 같은데요.DNS 의 피라미드 구조의 대안 구조
한가지 빠뜨린게 있는것 같은데요.
DNS 의 피라미드 구조의 대안 구조는 어떤것이 있을지 생각하고 있는 것이 있습니까?
M$의 경우 NT 에서의 Multimaster Domain 모델을 2000에서는 계층구조로 바꾸었습니다.
이것은 관리및 에러 추적이 용이하며 상위 계층의 서버 부담을 크게 줄일 수 있는 모델입니다.
그러므로 DNS 구조는 확장에 용이한 잘 설계된 구조라 생각이 듭니다.
아마도 인터넷에 쓰이는 10년도 더 낡은기술 이라 하면 DNS 가 아니라 프로토콜 부분이라는 생각이 드는군요.
:-) 흠 낡은 기술이라 문제가 생긴다(?) 라는 것에 느낌이 팍 오던게
:-) 흠 낡은 기술이라 문제가 생긴다(?) 라는 것에 느낌이 팍 오던게 dns더군요 :-) 그래서 난 생각입니다 :-) 실질적으론 dns문제를 토론하고 싶습니다 첫줄의 그 연설문 내용은 dns문제를 생각 하게 된 계기를 적어논것입니다 :-)
현재 인터넷의 구조아래서 DNS는 최선의 시스템이라고 생각합니다.
현재 인터넷의 구조아래서 DNS는 최선의 시스템이라고 생각합니다.
만약 바뀌어야 할것이 있다면, 원천적으로 중앙 집중화되는 트래픽을 분산시켜야 한다고 생각합니다.
P2P로의 이행.
플러스Pure P2P는 아직까지 성능문제를 해결하지 못했습니다.
플러스
Pure P2P는 아직까지 성능문제를 해결하지 못했습니다.
그누텔라같은 순수 P2P의 경우 바로 이웃한(거리가 1hop내의)
네트워크에만 패킷을 전달하는 방식이기 때문에
네트워크가 증가하는것에 비례해 현격하게 성능이 저하됩니다.
적합한 해결방식 ( 알고리즘의 획기적 개선, 하이브리드 방식의 채용 )
이 전제되지 않는 인터넷 시스템의 P2P화는 심각한
성능저하를 가져올 것입니다.
ps.여기서 인터넷 시스템의 P2P화는 오리얼리에서 나온
Peer To Peer에서 나온 인터넷의 원천적 속성인 P2P와는
다른 예기입니다.
중앙집중화되는 트래픽이라는 부분에 대해 잘 이해가 안되는군요.인터넷의
중앙집중화되는 트래픽이라는 부분에 대해 잘 이해가 안되는군요.
인터넷의 어디에도 원천적으로 "중앙집중"이라는 부분은 없습니다.
몇개의 루트서버가 존재하는 DNS의 경우에도
각자 자기 영역은 자기 DNS가 관리하는 지극히 자기관리적인 시스템입니다.
뉴스서버나 웹서버, FTP, 메일 어디에도 한군데에 모든걸 몰아서
중앙집중으로 관리하는 시스템은 없습니다.
웹은 어떻습니까?해마다 웹은 2exambyte씩 증가한다고 합니다
웹은 어떻습니까?
해마다 웹은 2exambyte씩 증가한다고 합니다. 하지만, 그 트래픽은 분산되지 못하고 있습니다. 인기있는 사이트는 언제나 인기있고, 그렇지 않다면 기억속에서 사라질 뿐입니다.
물론 한 서버가 모든걸 처리한다는 뜻이 아닙니다. 하지만 인터넷의 입장에서 봤을때 yahoo.com은 웹의 한 부분으로 밖에 보이지 않습니다.
P2P가 DNS의 대안이 된다는 얘기가 아닙니다. DNS는 말씀하신것 처럼 부하는 너무나도 잘 분산시켜주고 있습니다.
웹이라는 패러다임 자체가 변해야 된다는 생각이었습니다. 1servergroup - *client -> *client - *client