3월 28일 (목) 오후 7:33

logo

  • home
  • head
  • itnews
  • product
  • mobile
  • game
  • benchmark
  • analysis
  • blog

개봉 2023.11.22. / 등급: 12세 관람가 / 장르: 드라마 / 국가: 대한민국 감독 : 김성수 출연 : 황정민, 정우...
노량: 죽음의 바다 / 개봉 2023.12. / 장르: 액션, 드라마 / 국가: 대한민국 감독 : 김한민 출연 : 김윤석, ...
2015.04.09 21:23

DNS 정의와 계층 구조

조회 수 2857

DNS 개관, 역사, 표준

  • 초기 DNS의 개발과 계층 도메인으로의 이동
    • 1981년 9월 발표된 RFC 799, "Internet name domains"이 처음으로 이 개념을 도입
      • 실제로 도메인 자체보다는 도메인 간의 이메일 전송 방법을 다룸
      • 평면적인 도메인 구조를 가정하고 있으며 계층 구조는 향후에 개발될 가능성이 있다는 정도로만 언급
    • RFC 881, "Domain names plan and schedule"
      • 새로운 DNS 구현과 관련한 문제와 호스트 테이블 체계로부터의 전환방법을 다룸
    • RFC 882, "Domain names: Concepts and facilities"
      • DNS의 개념과 기능적 요소를 매우 자세히 설명
      • 네임 공간과 자원 레코드뿐 아니라 네임 서버와 변환기의 동작 방법에 대한 논의도 포함
    • RFC 883, "Domain names: Implementation specification"
      • DNS 메시징과 동작의 구체적인 핵심 내용을 다룸
  • DNS의 표준화와 초기 표준 정의
    • RFC 1032, "Domain Administrators Guide"
      • 도메인 운영에 필요한 관리 절차와 정책을 설명
    • RFC 1033, "Domain Administrators Operations Guide"
      • DNS의 분산 데이터베이스 각 부분을 관리하는 방법을 포함해 DNS 서버의 동작에 대한 기술적인 세부 사항을 제공
    • RFC 1034, "Domain Names - Concepts and Facilities"
      • RFC 882 대체
      • DNS의 소개와 개념적인 설명을 다룸
    • RFC 1035, "Domain Names - Implementation and Specification"
      • RFC 883의 개정판
      • 자원 레코드에 대한 정의, 메시지 유형, 마스터 파일 형식, 변환기와 네임 서버의 상세한 구현을 포함한 DNS의 동작 원리를 자세히 설명
  • DNS의 발전과 중요한 추가 표준들
    • RFC 1183, "New DNS RR Definitions"
      • 실험적인 자원 레코드 타임에 대해 정의
    • RFC 1794, "DNS Support for Load Balancing"
      • DNS 서버의 성능향상을 위한 부하 분산에 대해 다룸
    • RFC 1995, "Incremental Zone Transfer in DNS"
      • 효율성을 위해 일부 구역(zone)만을 2차 네임 서버로 전송하는 새로운 기능을 제안
    • RFC 1996, "A Mechanism for Prompt Notification of Zone Changes(DNS NOTIFY)"
      • 기본(중앙 관리) DNS 서버가 2차 서버에게 메인 데이터베이스의 새로운 변경 사항을 전달해줄 수 있는 DNS 메시지 타입을 추가함
    • RFC 2136, "Dynamic Updates in the Domain Name System(DNS UPDATE)"
      • 동적으로 DNS 데이터베이스의 자원 레코드를 변경하는 기술에 대해 다룸
      • Dynamic DNS라 불리기도 함
    • RFC 2181, "Clarifications to the DNS Specification"
      • RFC 1034와 1035에서 정의한 주요 DNS 표준과 관련한 여러 문제를 다룸
    • RFC 2308, "Negative Caching of DNS Queries(DNS NCACHE)
      • 네거티브 캐싱의 동작에 대해 설명
      • 더 이상 존재하지 않는 네임 정보를 서버가 좀더 효율적으로 유지하게 해주는 기능
  • 인터넷 프로토콜 버전 6으로의 DNS 적용

DNS의 설계 목표, 목적, 가정

  • DNS의 설계 목표와 목적
    • 전세계적인, 확장성 뛰어난, 그리고 일관성 있는네임 공간의 개발
    • 로컬 자원에 대한 로컬 제어
    • 병목 현상을 막기 위한 분산 설계
    • 응용 일반성
      • 광범위한 응용을 지원할 수 있도록 충분히 일반적이어야 한다.
      • 예를 들어 호스트 식별, 메일 전송 등과 같은 기능을 지원해야 한다.
    • 다양한 기본 프로토콜에 대한 지원
    • 하드웨어 일반성
  • DNS의 설계 상 가정
    • 데이터베이스 규모의 빠른 확대
    • 다양한 데이터 변경 속도
    • 위임 가능한 조직적 책임 구조
    • 네임 정보 접근의 상대적 중요성
    • 부재하는 정보에 대한 요청 다루기
    • 성능을 위한 캐싱 사용

앞에서 우리는 Hostname IP Address로 풀이(Name resolution)하는 방법으로 hosts.txt파일을 이용했을 때 생기는 몇가지 문제점을 살펴 보았다. 이름중복이라는 문제점을 해결하고, 현재상태의 컴퓨터의 호스트이름들을 반영할 수 있어야 하고, 관리적인 측면에서도 가장 손쉽게 접근할 수 있는 방법이라면 어떤 방법을 이용해야 할까? 이 점이 해결해야 할 중점과제이다. <?XML:NAMESPACE PREFIX = O />

 

한가지 예를 들어본다. 회사에는 수많은 부서가 존재한다. 그렇듯 부서를 나누는 이유는 무엇일까? 물론 여러 가지 이유가 있겠지만 관리적인 측면을 무시할 수 없을 것이다. 모든 사원들을 사장이 혼자 관리하는 것보다는 당연히 부서를 나누고 부서장이 관리를 하다면, 보다 효율적인 관리를 할 수가 있을 것이다. 또 부서가 없는 경우에 한 개인은 "000"라는 형식으로 개개인의 이름을 가지지만, 부서로서 개인을 조직하게 되면 "00부서의 000"로서 불리우게 될 것이다. 한 회사에 "<?XML:NAMESPACE PREFIX = ST1 /><?XML:NAMESPACE PREFIX = ST2 />송원석"이라는 이름을 가진 사람이 둘이 있다고 하자. 부서의 개념이 없을 때는 단순히 "송원석"하고 부르면 누구를 가리키는 것인지 헷갈릴 수밖에 없다. 하지만 그들을 구별해 주는 부서가 있다면 "00부서의 송원석"이라는 식으로 어긋나지 않게 원하는 사람을 구별할 수 있게 된다.

 

앞에서 문제가 되었던 이름중복은 조금만 생각을 바꾸면 해결이 가능한다. 이름을 평면적인(flat) 이름으로 사용하는 것 대신에 부서처럼 다른 이름을 하나쯤 더 붙이면 되지 않을까? 예를 들면 "www"라는 이름 대신에 "A회사의 www"로서 등록을 한다는 것이다. 그렇다면 모든 회사의 웹서버가 "www"라는 이름을 사용하더라도 더 이상 이름의 충돌은 염려하지 않아도 될 것이다.

 

hosts파일크기의 증가로 인한 네트워크 트래픽을 줄이고, 빠른 업데이트를 가능하게 하기 위해서는 관리를 분산시킬 수 있는 구조가 최선이라는 해결책을 찾고 결국 호스트들을 그룹화하는 작업을 하게 되었다. 그 그룹을 바로 "도메인(domain)"이라고 부른다. 여기서의 도메인은 Microsoft가 사용하는 도메인이라는 용어와는 구별을 해야 한다. Microsoft의 도메인은 어디까지나 마이크로소프트의 NT라는 운영체제가 제공하는 보안의 경계영역을 구분하는 회사의 작업그룹인 반면에, DNS에서의 도메인은 전 세계에서 구분할 수 있는 작업그룹이다.

 

DNS의 도메인은 수없이 많은 종류가 있을 수 있다. 대표적으로는 여러분들이 속해 있는 회사를 생각할 수 있고, 국가를 구분할 수도 있고, 특별한 단체를 구분지을 수도 있다. 인터넷에 연결되고 자신들의 집단을 구분할 수 있는 이름을 가지고자 한다면 어느 누구라도 도메인이라는 하나의 작업그룹을 할당받을 수 있다는 이야기다. 추가로 이러한 그룹 역시 또 다른 그룹에 소속되어 있고, 최상위에 모든 그룹은 하나의 그룹으로 묶이게 된다. 회사의 조직구조와 비슷한다. 회사안에는 몇 개의 사업본부가 있고, 사업본부 안에는 몇 개의 부서가 있고, 부서 아래에 팀이 있고, 팀 안에 팀원들이 소속되어 있는 구조와 같다. 실제 구조를 살펴보면 우리가 윈도우 탐색기를 통해서 볼 수 있는 폴더구조와 흡사한다. 최상위에 root(c:)가 있고, 그 밑에 폴더가 있으며 폴더밑에는 또 다른 폴더가 있고, 최종적으로 폴더 밑에는 파일이 들어있다. 이러한 형태의 구조를 우리는 계층구조라고 부른다. DNS는 계층구조로 구성되어 있다.

 

결국 최종적으로 만들어진 DNS의 구조를 살펴보면 아래의 <그림5-8>과 같다

 

 

49201440d00f4


<그림5-8. Domain Name Space의 계층구조>

 

위의 그림에서 볼 수 있는 것처럼 DNS는 뚜렷한 계층구조를 가지고 있다. 최상위에는 모든 도메인의 근본이 되는 루트도메인을 두고, null라벨(공백의 문자, "  ")로서 이름을 할당하였다. 이것을 가리켜서 루트-레벨 도메인이라고 부른다. 루트-레벨 도메인의 아래에는 top-level domain을 두는데, 우리에게 친숙한 이름이 보일 것이다. kr, com, net, org등이 그것이다. 각각의 top-level domain은 특별한 원칙을 가지고 있다. 어느 집단이 사용을 하는 이름인지를 알아볼 수 있게 만든 것이다. 현재 약 250여개 정도의 top level domain이 사용되고 있다.

 


< Top-level
도메인 이름 구조>

-      com : 영리목적의 기관 (Commercial organization)

-      net : 네트워크 기관 (dacom, hitel 등이 사용하고 있다)

-      org : 비영리 기관

-      gov : 정부 기관

-      mil : 군사 기관

-      edu : 교육 기관

-      kr (Korea), jp (Japan), au (Australia) : 국가 이름

 

이들 루트 도메인과 탑 레벨 도메인은 우리가 등록해서 사용할 수 있는 이름이 아니다. InterNIC에서는 이미 전세계의 도메인들의 밑바탕이 될 이름을 등록하였고, 실제로 우리가 사용하게 될 이름은 이들 탑 레벨 아래의 도메인부터라고 할 수 있다. <그림5-8>에서 볼 수 있는 것과 같이 탑 레벨 도메인 아래에는 세컨드 레벨 도메인이 있고, 거기에서 실제로 우리나라 회사의 이름을 반영하는 이름들을 찾아볼 수 있게 된다. 우리가 도메인 등록을 한다고 이야기를 하면 바로 그러한 이름을 이야기하는 것이다. 물론 COM이나 Net과 같은 도메인 아래에 여러분의 회사를 등록하다면 바로 세컨드 레벨에서 등록하는 것이 가능하겠지만, 우리나라를 가리키는 Kr도메인 아래에 회사를 등록하고자 하다면, 우리는 한단계 더 아래로 내려갈 수밖에 없다. Kr아래에 또 다시 영리회사를 가리키는 "co"라는 이름이 second level로서 등록되고, 여러분이 원하는 회사이름은 그 아래에 등록되어야 하기 때문이다. 왜 그래야 할까? 답은 뻔하지 않은가! 미국에서 만들어서 사용하고 그들이 발전시켜 오고 있는 것이기 때문에 우리는 그들이 할당해준 kr이라는 top level domain을 우리나라 입장에서는 root로 삼고, 다시 그 안에서 분리작업을 해야 하기 때문인 것이다. 아쉬운 일이지만 힘을 키우는 도리밖에 어쩔 수가 없는 노릇이다.

 

이러한 계층구조를 가진 분산데이타베이스 구조를 가리켜서 DNS (Domain Name Space혹은 Domain Name System)라고 부른다. 그렇다면 이들 DNS는 실제로 어디에 존재하는 것일까? 질문이 너무 막연해 보인다. 여러분이 즐겨찾는 인터넷이라는 공간을 가리켜 우리는 사이버공간이라고 부른다. 실체는 없는 가상공간이라는 뜻이다. 실제로 존재하는 것은 클라이언트 시스템으로서 사용하는 PC가 있고, 그들이 접속해서 사용하는 서버라는 것이 있다. 전세계에 네트워크에 연결된 이들 모든 컴퓨터들이 어우러져서 인터넷이라고 부르는 하나의 커다란 가상공간이 존재하게 된 것이다. DNS역시 마찬가지이다. 어느 한곳에 DNS라는 이름이 기록되고 관리되고 있는 형태는 아닌 것이다. 실체로 본다면 역시 물리적인 시스템인 서버가 존재하겠지만, 이들 모든 서버들이 만들어 내고 있는 하나의 가상공간인 셈이고, 이러한 가상공간을 제공하는 서비스를 DNS를 관리하는 서버, 바로 DNS Server가 이루어놓고 있는 것이다. 결국 <그림5-8>에서 각각의 그룹을 가리키는 도메인이라는 녀석이 존재하고 있었는데, 그 도메인의 중심에는 바로 DNS Server라고 하는 컴퓨터가 차지하고 있게 된다.

 

DNS를 정리해보면 "각각 회사를 구분해주는 도메인이름을 관리하는 DNS Server들이 모여서 만들어낸 가상 이름 공간"이라고 요약을 해 볼 수 있겠다.

 

다음은 DNS의 표기법에 대해서 알아보겠다. 이름충돌의 문제를 해결하다는 예제를 가지고 생각해 보자. <그림5-8>에서 second level domain중에 "feelanet"라는 이름이 있고, 그 회사가 가지고 있는 서버중에 "www"라는 웹서버가 있다. 또한 secure라는 조직도 역시 "www"라는 웹서버를 가지고 있다. 이들은 어떻게 똑같은 이름을 가질 수가 있게 되는가? 바로 DNS에서 바라보는 서버의 이름체계가 이 문제점을 해결해 주고 있다. 이제 더 이상 인터넷에 연결된 서버들은 서로를 구분하는데 있어서 평면적인 www라는 형태의 단순한 이름체계로 사용되지는 않는다. 인터넷상에서 서버들의 이름은 다음과 같은 표기법을 사용하기 때문이다.

 


Fully Qualified Domain Name (FQDN)

 

DNS에서의 서버의 이름 = Host name + Domain Name


> www+feelanet+com+(공백)

표기법) www.feelanet.com.   www.secure.pe.kr

 

 

결과적으로 feelanet의 웹서버인 www서버는 www.feelanet.com과 같이 표기되고, Secure의 웹서버는 www.secure.pe.kr과 같이 표기되고 구별되기 때문에 전혀 다른 이름을 가지게 된다. 예전에 사용했던 평면적인 이름체계에서 벗어나 계층구조의 이름을 가짐으로써 이름충돌에 대한 문제점을 해결하게 된 것이다.

한가지 고려사항은 여전히 남아있다. 같은 계층에 2개의 같은 도메인이 있을 수가 있을까? 라는 것이다. 정답은 NO. 예를 들면 com이라고 하는 도메인에 feelanet이라는 도메인이 등록되어 있다. 또 다른 회사에서 역시 그들도 feelanet이라는 이름을 사용하고자 하다면 당연히 허용해 주어선 안될 일이다. 이러한 문제 때문에 새로운 신기술이 나오면 서로 먼저 그 이름을 이용한 도메인을 등록하기 위해서 도메인전쟁이라고까지 표현되는 등록싸움이 발생하고 있는 것이다. 그렇다면 왜 도메인 등록을 하여야 할까? 그냥 우리가 사용하고 싶은 이름을 마음대로 쓰면 되는 것 아닌가? 라고 생각하다면 다음에 설명할 DNS의 이름풀이 과정을 이해하고 생각을 바꿀 수가 있을 것이다. 지금부터는 DNS Server가 어떤 과정을 통해서 이름풀이 과정을 진행하는 지에 대해서 설명하도록 하겠다.

 

<그림5-11>의 예제에서 DNS 클라이언트로 표기된 PC에 앉은 사용자는 하나로 통신 가입자이다. 이 사용자는www.feelanet.com이라는 이름을 가진 feelanet회사의 웹서버에 접근해서 웹서비스를 받고자 한다. 사용자가 www.feelanet.com IP Address를 알고 웹 브라우저를 통해서 이름이 아닌 IP주소로 접근을 했다면 간단하겠지만, 사용자가 그런 주소를 알 필요는 없다. 이 사용자의 PC는 하나로 통신DNS서버를 사용하는 DNS클라이언트로 셋팅이 되어 있다. DNS 클라이언트에 대한 부분은 앞장에서 확인한 바 있다.

 

492014aa61688


< 그림5-11. DNS Name Resolution Process>

 

사용자는 웹 브라우저의 주소창에 http://www.feelanet.com 이라고 입력하고 <Enter>키를 누를 것이다. 이 요청은 http라는 프로토콜을 가지고 www.feelanet.com이라는 이름의 서버에 요청을 보내겠다는 뜻이다. 결국 웹서비스를 요청하는 메시지이다. 이 요청을 처리해 주기 위해서 사용자의 시스템은 먼저 www.feelanet.com IP Address를 알아야 한다. 하지만, 스스로 알 수 있는 방법이 없다. 그런데 DNS 클라이언트로 셋팅이 되어 있기 때문에 DNS Server로 셋팅된 서버에게 질문을 던질 수가 있다.

 

사용자의 시스템은 자신의 TCP/IP등록정보에 DNS Server로 셋팅된 IP Address의 서버에게 www.feelanet.com IP Address를 요청한다.(그림5-11-①) 이 요청을 가리켜서 resursive query(재귀적질의)라고 한다. resursive query라고 함은, 이 요청을 받은 서버가 '모 아니면 도' 둘중의 하나의 응답을 해야만 하는 Query를 말한다. IP Address를 가르쳐주거나, 에러메시지를 반납하거나의 선택을 뜻한다.

 

의 요청을 받은 DNS Server는 응답을 해야 하는데, 자신 역시 자신이 관리하는 이름을 알 뿐이지 어디 있는지도 모르는 feelanet이라는 회사의 웹서버의 IP Address를 알 수가 없다. 그래서 먼저 DNS Server Cache라고 부르는 데이터베이스에서 클라이언트가 요청하는 정보가 있는지를 확인해 본 다음, 없다면 다른 DNS에게 질문을 던져서 클라이언트의 요청을 해결하려는 시도를 한다. Windows Server에서 DNS Service를 추가하고, DNS Server로 동작하게 되면 그 서버에는 한가지 정보가 기본적으로 추가된다. 바로 루트 도메인을 관리하고 있는 DNS Server들의 목록이다. 서버는 그 정보를 이용해서 루트 도메인의 DNS Server에게 클라이언트가 요청한 www.feelanet.com에 대한 이름풀이 요청을 보내게 된다. (그림5-11-②) 이 때의 Query를 가리켜서 Iterative Query (반복적 질의)라고 부른다. Recursive Query와는 조금 성격이 틀린 것을 알 수 있을 것이다.

 

루트네임서버는 요청을 받았으니 응답을 해야 할텐데, 자신 역시 모든 정보를 알고 있는 것은 아니다. 자신이 알고 있는 것은 "com"도메인을 관리하는 네임서버의 정보를 알고 있을 뿐이다. 그래서 하나로통신의 DNS Server가 원하는 것에 대한 100% 정답은 아닌, "com"도메인을 관리하는 네임서버의 정보를 제공해 주게 된다. (그림5-11-③)

 

하나로통신의 DNS Server는 한번의 query를 통해서 com도메인을 관리하는 네임서버의 정보를 알 게 되었다. 아직 완전한 정보는 얻지 못했기 때문에 계속해서 책임을 완수하고자 한다. 계속해서 "com"도메인의 네임서버에게 www.feelanet.com. IP정보를 요청한다. (그림5-11-④)

 

하지만 'com'도메인의 네임서버 역시 하나로통신의DNS Server 가 요청한 호스트이름에 대한 IP정보를 알지는 못한다. 그렇지만 feelanet을 관리하고 있는 네임서버의 정보는 알고 있다. 자신이 관리하고 있는 하위도메인이기 때문이다. 그래서 요청에 대한 응답으로feelanet.com.의 정보를 알려 주게 된다. (그림5-11-⑤)

 

Feelanet.com.도메인의 네임서버정보를 얻은 하나로통신의 DNS Serverfeelanet.com의 네임서버에게 www.feelanet.com이라는 자신의 클라이언트가 요청했던 호스트에 대한 IP정보를 요청한다. (그림5-11-⑥)

 

이 요청을 받은 feelanet.com.의 네임서버는 요청한 FQDN이 자신이 관리하고 있는 도메인에 소속된 호스트이기 때문에 IP Address정보를 응답해 줄 수가 있다.(그림5-11-⑦)

 

몇 번의 query를 통해서 DNS 클라이언트가 요청한 정보를 알게 된 하나로통신의 DNS Server www.feelanet.com IP Address를 제공해 줄 수가 있게 되었다.(그림5-11-⑧)

 

그렇다면 이제 사용자는 DNS Server를 통해서 원하는 웹서버에 대한 IP Address를 알 게 되었기 때문에 TCP/IP통신을 할 수가 있게 되었다. http프로토콜로써 웹서버에게 서비스를 요청하고, 웹서버는 홈페이지를 서비스해 주게 되는 것이다.

 

글로써 기록하니 상당히 복잡해 보인다. 하지만 실제로 사용자 입장에서 본다면, 사용자는 웹 브라우저의 주소창에 친숙한 이름표기법에 따르는 이름을 입력했을 뿐이고, 내부사정은 잘 모르겠지만 어찌됐건 원하는 웹사이트의 홈페이지를 볼 수 있게 되었다. 이러한 작업을 가능하게 하기 위해서 DNS Server는 부지런히 발로(?) 뛰며 서비스를해 주고 있었던 것이다. DNS가 없었다면 이런 일이 가능했을까? 실로 DNS의 위력은 엄청나게 보이다. 필자는 감히 인터넷을 이끌어가고 있는 것은 바로 DNS라고 말하고 싶다. 그만큼 인터넷에 있어서 DNS의 기능은 필수적이기 때문이다. 하는 일은 크지 않지만 어떤 것보다도 중요한 역할을 담당하고 있다. 만일 DNS가 없다면 지금 우리가 사용하는 인터넷이라는 환경이 상당히 많이 다를 거라고 생각한다. TV에서 하고 있는 광고중의 상당수는 도메인이름을 알리는 광고를 하고 있다. DNS가 없다면 업체에서는 도메인이름을 알리는 광고가 아니라 IP Address를 알리는 광고를 해야만 할 것이다.

 

그렇다면 앞서서 가졌던 한가지 의문중에 "왜 반드시 원하는 도메인이름을 등록해야만 사용할 수 있을까"라는 것을 생각해 보자. <그림5-11>의 예제에서 웹서버 입장을 생각해 고려해 보겠다. Feelanet이라는 회사는 자신의 웹서버를 통해서 회사를 홍보하고, 몇가지 서비스를 판매하는 일을 하고 있다고 가정한다. 사용자가 자신의 웹서버의 IP Address를 알고 찾아오게 하는 일은 가장 중요한 일이라고도 할 수 있다. 그런데 앞에서 보았듯이 사용자가 자신의 웹서버의 IP주소를 알기 위해서는 어떤 과정이 있었는가? Feelanet DNS Server까지 요청이 와야 하는데, 그것보다 선행되었던 작업이 com도메인의 DNS Server를 찾는 과정이었다. 만일 com도메인의 DNS서버에 Feelanet의 도메인 정보가 등록되어 있지 않았다면 당연히 com도메인의 DNS Server는 하나로통신의 DNS서버의 요청에 대해 그런 도메인의 정보는 없습니다라는 에러메시지를 전송해야만 했을 것이다. 이 경우 당연히 하나로통신의 DNS Server는 이름풀이를 처리하지 못했기 때문에 사용자에게 에러메시지를 반송할 수밖에 없다.

 

그래서 도메인등록이라는 용어를 풀어본다면, "회사에서 사용하기를 희망하는 도메인 이름을 관리하는 DNS Server의 정보를 상위 도메인을 관리하는 DNS Server에 등록하는 작업"이라고 보여진다.

 

처음 볼 때는 상당히 번거로운 작업이라는 생각이 들 수도 있다. 하지만, 이러한 DNS의 진행과정은 2장에서 보았던 hosts.txt파일을 이용한 이름풀이의 과정이 가졌던 모든 문제점을 해결할 수 있는 방법이 되고 있다. 문제점과 비교해서 DNS의 이름풀이과정을 연관시켜서 정리해 보길 바란다.


출처 - http://www.secure.pe.kr/31 

http://wooguy-tcpip.blogspot.kr/2014/08/dns.html






  1. 5G란 무엇인가 : 현황, 기술개발, 해결과제, 일정, 전망

    Craig Mathias | Network World 5G라고 알려진 차세대 무선 WAN 통신이 조만간 언론의 1면을 장식할 것으로 보인다. 5G는 유선 보완제에서 유선 대체제로 이동통신의 진화를 완성할 것이며, 전략적으...
    Date2017.07.15 CategoryIT KNOWLEDGE
    Read More
  2. [보안NW] 내부망, DMZ구간, 외부망 이란?

    개인정보보호법이 시행되면서 개인정보보호의 기술적 보호대책을 위해 내부망, DMZ구간, 외부망이라는 말이 많이 언급되고 있습니다. 내부관리계획을 세우다보면, 내부망을 단순히 사내조직원들끼리 사용...
    Date2017.07.08 CategoryIT KNOWLEDGE
    Read More
  3. Wireless Multicast 무선구간 멀티캐스트

    * Lesson 2 Describing Implications for Multicast in 802.11 (p223) 멀티캐스트는 유선쪽에서 오는 트래픽을 무선 STA에 배포 하거나 혹은 모빌리티 메시지 정보를 교환하는데 사용 합니다.     -----...
    Date2017.06.10 CategoryIT KNOWLEDGE
    Read More
  4. L2TPv3 프로토콜, VPN

    L2TPv3(Layer 2 Tunnel Protocol Version 3, RFC 3931)은 Layer2 의 프레임을 그대로 IP 캡슐화해서 remote 측으로 전달하는 프로토콜이다. 즉 CDP, STP, ARP 까지 사업자를 통해서 remote 측으로 전달 ...
    Date2017.05.13 CategoryIT KNOWLEDGE
    Read More
  5. 리눅스 vi 명령어 모음

    <command mode> h 왼쪽 j 아래 k 위 l 오른쪽 H,J,K,L(대문자): 끝까지 이동 w: 단어의 처음 특수기호 인식 왼->오 공백인식 b: 단어의처음 특수기호 인식 오->왼 공백인식 e: 단...
    Date2017.04.10 CategoryIT KNOWLEDGE
    Read More
  6. L4 스위치/Alteon SLB/서버로드밸런싱

    대부분의 네트워크망에서 꼭 알아야지만 전체 트래픽의 흐름도를 알 수 있는 Layer4 Switch 입니다. 일단 가장 Layer4 SW를 많이 사용하는 SLB(Server Load Balancing)부터 알아보겠습니다. 이후 방...
    Date2017.02.27 CategoryIT KNOWLEDGE
    Read More
  7. 프로그래밍 언어별 딥러닝 라이브러리 정리

    AI Korea Open 그룹에서도 라이브러리에 관한 투표가 있었고, 많은 분들이 관심있어할 만한 부분이라 생각해서 한 번 정리해 봤습니다! (AI Korea Open 그룹의 투표 결과) Python요즘 뜨는 언어답게, ...
    Date2017.02.02 CategoryIT KNOWLEDGE
    Read More
  8. DevOps (데브옵스)에 대하여

    최근에 DevOps(데브옵스)라는 개발방법론이 솔솔 들리고 있다.  데브옵스는 개발(Development) + 운영(Operation)을 합친 말로 개발와 운영의 상호작용을 원할하게 하는데 있다고 합니다.  [마이크로소...
    Date2016.12.27 CategoryIT KNOWLEDGE
    Read More
  9. 색공간 (sRGB, 어도비 RGB 등)

    목차가장 기본적인 색공간 RGB sRGB(standard RGB) 애플 RGB(Apple RGB) 어도비 RGB(Adobe RGB) 비디오에서 가장 많이 사용하는 색공간 YUV, YCbCr/YPbPr NTSC의 색공간 YIQ 인쇄 매체의 핵심 색공간 CMY, ...
    Date2016.11.25 CategoryIT KNOWLEDGE
    Read More
  10. 2016 SDS 그 유형과 소비 형태에 관해

    소프트웨어 정의 스토리지, Software defined storage(이하 SDS)가 어느 정도 업계에 많이 알려지고 실제로 도입되는 경우가 발생하면서 SDS에 대한 궁금함이 더욱 더 많이 생기고 있습니다. 업계의 많은 ...
    Date2016.11.04 CategoryIT KNOWLEDGE
    Read More
  11. 하둡, HDFS, 맵리듀스 개념

    빅 데이터는 클라우드 컴퓨팅만큼이나 널리 확산되고 있는 개념이다. 그러나 빅 데이터의 역량과 한계에 관해서는 사람들이 잘못 알고 있는 부분들이 많다. 특히 빅 데이터와 관련해 사람들은 다음의 질문...
    Date2016.09.21 CategoryIT KNOWLEDGE
    Read More
  12. 스토리지 풀 개요 (Storage Pool)

    풀 또는 스토리지 풀은 지정된 볼륨 세트에 대한 모든 데이터를 공동으로 포함하는 MDisk 콜렉션입니다. 그림 1은 네 개의 MDisk가 있는 스토리지 풀을 나타냅니다. 그림 1. 스토리지 풀 풀의 모든 MDi...
    Date2016.08.22 CategoryIT KNOWLEDGE
    Read More
  13. Windows Dump 구성 및 강제 생성

    Windows에서 강제로 덤프 생성하기 Action Plan 1. What: Full dump 저장을 위해 Page file을 총 메모리+1MB 정도로 증설 What: ASR 비활성화 To do. 1) Win7 > 제어판\시스템 및 보안\시스템 > 고급 선...
    Date2016.07.29 CategoryIT KNOWLEDGE
    Read More
  14. SMP(Symmetric Multi-Processing) vs AMP(Asymmetric Multi-Processing)

    오늘은 SMP와 AMP에 대해 간략히 학습하는 시간을 갖도록 하겠습니다. 1. SMP(Symmetric Multi-Processing) SMP은 두 개 이상의 동일한 프로세서가 하나의 메모리, I/O 디바이스, 인터럽트 등의 자원...
    Date2016.06.20 CategoryIT KNOWLEDGE
    Read More
  15. 쿨러 베어링 타입별 특징 (슬리브/볼/FDB)

    베어링 [bearing] : 회전하고 있는 기계의 축을 일정한 위치에 고정시키고 축의 자중과 축에 걸리는 하중을 지지하면서 축을 회전시키는 역할을 하는 기계 요소 냉각팬의 베어링 방식에...
    Date2016.05.11 CategoryIT KNOWLEDGE
    Read More
  16. 컨테이너 기반 가상화 기술

    Micro Service Architecture 에서 인프라 적으로 중요한 개념으로 꼽으면 아래와 같이 2가지로 정리할 수 있다.Application Programming Interface (API) 가상화 (virtualization) API는 이미 많은 개발...
    Date2016.04.29 CategoryIT KNOWLEDGE
    Read More
  17. 하이퍼 컨버지드 인프라 (Hyperconverged Integrated System)

    통합 시스템, 컨버지드 인프라 등으로 불리는 Integrated System의 성장과 발전이 데이터센터 전체에 상당히 크게 영향을 미칠 것으로 보입니다. 시장 조사 기관인 가트너에 따르면 2014년부터 2019년에 이...
    Date2016.03.22 CategoryIT KNOWLEDGE
    Read More
  18. 모바일IP 이론

    * Mobile IP (모바일 IP) : 모바일 IP 에 대해서 알아본다. 1. Mobile IP 정의 Mobile IP는 IETF 표준 통신 프로토콜로, 이동 기기 사용자로 하여금 한...
    Date2016.03.14 CategoryIT KNOWLEDGE
    Read More
  19. TLS 전송계층보안

    인터넷에서의 정보를 암호화해서 송수신하는 프로토콜. 넷스케이프 커뮤니케이션스사가 개발한 SSL(Secure Sockets Layer)에서 기반한 기술로, 국제 인터넷 표준화 기구에서 표준으로 인정받은 프로토콜이...
    Date2016.02.04 CategoryIT KNOWLEDGE
    Read More
  20. 시스코 스위치 이더채널

    Etherchannel, 이더채널 - 두 스위치간에 연결된 복수개의 포트를 하나의 포트처럼 동작시키는 것을 말한다 이더채널을 구성할 때 사용되는 프로토콜은 시스코에서 만든 PAgP(Port Aggregation Protocol)와...
    Date2015.12.28 CategoryIT KNOWLEDGE
    Read More
Board Pagination Prev 1 2 3 4 5 6 7 Next
/ 7