Chapter 2
|
D.M.Z
CONTENT
PRE
NEXT
2.1 Networking Interface
2.2 IP Address
2.3 Address Resolution
2.4 IP Routing
2.5 The Internet Control Message Protocol
2.6 The Domain Name System
이제 우리는 IP 주소와, hostname, 그리고 때때로 routing issue와 관련되어 있는 TCP/IP 네트웍에 당신의 리눅스 머신을 연결할 때에 수반되는 세부사항에 관해 기술하고자 한다. 이번 장에서는 setup할 필요가 있는 것들을 이해하기 위한 배경을 제시하고, 다음 장에서 그와 관련된 툴에 관해 살펴볼 것이다.
네트웍 환경에서 사용되는 장비의 다양성을 표면화시키지 않기 위하여 TCP/IP는 하드웨어를 접근할 수 있는 추상적인 인터페이스(interface)를 정의한다. 이 인터페이스는 기본적으로 패킷을 주고 받으며 모든 종류의 하드웨어에 동일한 작업셋을 제공한다.
네트워킹을 위해 사용하고자 하는 각각의 주변장치에서는 상응하는 인터페이스가 커널에 존재한다. 예를 들어 리눅스에서 이더넷 인터페이스는 eth0와 eth1이고 SLIP 인터페이스는 sl0,sl1등이다. 이 인터페이스의 이름은 물리적 디바이스를 커널에게 이름지워 주려할 때의 설정 목적 이외의 다른 의미는 없다.
TCP/IP를 사용하기 위해선 다른 세계와 통신할 때 인터페이스에 그것을 식별할 수 있는 IP 주소를 반드시 지정해야 한다. 이 주소는 위에서 말한 인터페이스 명과는 별개의 것으로, 인터페이스를 문으로 비유한다면 IP 주소는 그 문에 달린 문패라 할 수 있다.
물론, 설정해야 하는 여타의 디바이스 파라미터도 존재한다. 이들 중 한 가지는 특정 하드웨어가 처리할 수 있는 데이터그램의 최대크기, 흔히 MTU(Maximum Transfer Unit)라고 불리는 것이다. 또 다른 특성은 차후에 소개할 것이다.
지난 장에서 언급되었듯, IP 네트워킹 프로토콜이 이해할 수 있는 것은 32비트 수이다. 모든 머신은 네트웍 환경에서 유일한 수를 지정해야 한다. 만약 로컬 네트웍에서 TCP/IP를 사용하여 다른 네트웍과 연결하지 않는다면 이 숫자들은 당신 마음대로 지정할 수 있으나, 그렇지 않고 인터넷의 사이트로서 존재하고자 한다면 이 숫자들은 NIC(Network Information Center)에서 지정할 것이다.
보다 읽기 쉽도록 IP 주소는 옥텟(octet)이라 불리는 8비트 수로 나누어져 있다. 예를 들어 quark.physics.groucho.edu는 0x954C0C04라는 IP 주소를 가지고 있는데, 149.76.12.4라고 쓰여진다. 이러한 양식을 dotted quad notation이라고 부른다.
이에대한 다른 이유는 IP주소가 네트웍 번호(network number)를 분할하기 때문으로, 이것은 앞부분의 옥텟에 포함되어 있고, 그 나머지가 host number이다. NIC에 IP 주소를 요청할 때엔 사용하고자 하는 하나의 호스트 주소만을 부여받을 수는 없다. 대신 network number를 받음으로써 당신의 네트웍 내에 존재하는 호스트에 사용가능한 모든 IP 주소를 당신 마음대로 배당할 수 있다.
네트웍의 크기에 따라 IP 주소의 host part는 작아지거나 커진다. 서로다른 요구를 상충시키기 위해서 IP 주소를 다른 방식으로 나누는 네트웍의 클래스가 몇가지 존재한다.
| Class A | Class A는 1.0.0.0에서 127.0.0.0의 네트웍을 구성한다. 네트웍 번호는 첫번째 옥텟에 포함되어 있으며, 이것은 24비트의 host part를 제공함으로써 대략 160만여개의 호스트를 쓰는 것이 가능하다.
. |
| Class B | Class B는 128.0.0.0에서 191.255.0.0까지의 네트웍을 포함한다. 네트웍 번호는 처음의 두 옥텟에 포함되어 있고, 이는 65024개의 호스트를 각각 지닐 수 있는 16320개의 넷을 허용한다.
. |
| Class C | Class C의 네트웍 범위는 192.0.0.0에서 233.255.255.0까지로, 처음의 세 옥텟이 네트웍 번호를 포함하며, 이는 254개의 호스트를 지닐수 있는 200만여개의 네트웍을 지정할 수 있다.
. |
| Class D,E,F | 224.0.0.0에서 254.0.0.0의 범위에 있는 주소는 시험적인 용도 또는 미래를 위해 보존된 것으로, 어떠한 네트웍에도 해당되지 않는다.
. |
지난 장의 예제로 되돌아가 보면 149.76.12.4라는 quakr의 주소는 Class B 네트웍, 149.76.0.0에 있는 12.4인 호스트인 것이다.
위의 리스트에서, host part 각각의 옥텟의 모든 값이 사용 가능하진 않다는 것을 눈치챘을 것이다. 이것은 각 옥텟의 0과 255값이 특정한 목적을 위해 보존되어 있기 때문이다. 모든 host part가 0인 주소는 네트웍을 지시하고, 1인 것은 broadcast 주소라 불린다. 이것은 특정 네트웍내의 모든 호스트를 동시에 지시한다. 그리고 149.76.255.255는 적절한 호스트 주소가 아니라 149.76.0.0의 모든 호스트를 지시한다.
역시나 예약된 두 주소는 0.0.0.0과 127.0.0.0이다. 전자는 기본 루트(default route)이며, 후자는 루프백 주소(lookback)이다. 기본 루트는 아래에 다룰, IP가 데이터그램을 라우팅하는 방법과 관련이 있다.
네트웍 127.0.0.0는 당신의 호스트로의 IP traffic을 위해 예약되었다. 보편적으로 127.0.0.1이란 주소는 당신 호스트의 인터페이스, 즉 폐쇠회로처럼 동작하는 루프백 인터페이스(loopback interface)를 지정한다. TCP나 UCP에서 넘겨진 어떤 IP 패킷은 마치 다른 네트웍에서 온 것처럼 되돌아 올 것이다. 이것은 네트워킹 소프트웨어를 "진짜" 네트웍을 사용하지 않고서도 개발 혹은 시험할 수 있도록 한다. 이것은 standalone 호스트에서 네트웍 소프트웨어를 사용하고자 할 때 유용하다. 이 말은 말 자체처럼 비 상식적인 것은 아니다. 예를 들어, IP 연결이 되지 않은 다수의 UUCP 사이트에서도 INN news 시스템을 리눅스에서 사용하길 원한다면, 완벽한 프로그램 수행을 위해 INN은 루프백 인터페이스를 필요로 한다.
이제, IP 주소가 어떻게 만들어 지는지 보았으나, 이더넷 상에서 각기 다른 호스트에 어떻게 주소를 부여하는지 의문을 품고 있을 것이다. 결국, 6개의 옥텟으로 호스트를 식별하는 이더넷과 IP 주소는 잘 어울리진 않지 않은가?
그렇다. 그것이 바로 IP 주소를 이더넷 주소로 바꾸는 메카니즘이 필요한 이유로, 그 메카니즘을 ARP(Address Resolution Protocol)라 부른다. 사실상 ARP는 이더넷에만 국한되는 것이 아니라, ham radio같은 타 종류의 네트웍에도 사용된다. ARP에 깔린 아이디어는 Mr.X를 찾아야 할 때 대부분의 사람들이 쓰는 방식이다. 그들은 그의 이름을 부르며 돌아다니면 그가 그 곳에 있다고 대답할 것이라 한다.
ARP가 주어진 IP 주소와 일치하는 이더넷 주소를 찾고자 할 때, 그것은 네트웍상의 모든 곳으로 동시에 보내지는 데이터그램인 "broadcasting"이라는 것을 사용한다. ARP가 보내는 broadcast 데이터그램엔 IP 주소에 대한 질의가 포함되어 있다. 이것을 받은 각각의 호스트는 자신의 IP와 비교하고, 만약 맞다면 질의를 보낸 호스트로 ARP reply를 되돌려 준다. 질의한 호스트는 이제 reply에서 이를 보낸 호스트의 이더넷 주소를 풀이한다.
물론, 어떻게 1조여개에 달하는 이더넷을 통하여 원하는 호스트를 어떻게 찾을 수 있는지, 그리고 왜 이더넷이어야만 하는지에 대해 의아해 할 것이다. 이 질문은 라우팅이라는 (이름처럼 네트웍에서 호스트의 물리적 위치를 찾아내는)것을 모두 의미한다. 이것이 다음 절의 주제이다.
잠깐동안, ARP에 대해 짧으나마 얘기해 보자. 호스트가 이더넷 주소를 발견하면, 그 호스트는 그것을 ARP 캐쉬에 저장하고, 다음번에 그 호스트에 데이터그램을 보내고자 할 때, ARP를 질의할 필요가 없다. 그러나, 이 정보를 영원히 지니는 것은 현명치 못하다. 예를 들어, 리모트 호스트의 이더넷 카드는 기술적인 이유상으로 교체될 수 있는 것이다. 그러므로 그 ARP 엔트리는 쓸모없게 되며, IP 주소를 또다시 질의하기 위해서 ARP 캐쉬의 엔트리는 얼마간의 시간후에 파기된다.
때때로, 주어진 이더넷 주소의 IP 주소를 찾을 필요도 있는데, 이런 것은 네트웍상의 디스크 없는 머신이 서버로부터 부팅하고자 할 때 일어나며 LAN 상에서는 꽤 흔한 일이다. 그러나 디스크 없는 클라이언트는 자체에 대한 정보를 일체 가지고 있지 않다. - 단, 자신의 이더넷 주소를 제외하고! 그러므로 그것이 기본적으로 하는 것은 서버에게 자신의 IP 주소를 알려달라는 간청을 포함한 메시지를 broadcast하는 것이다. 이를 위해 RARP(Reverse Address Resolution Protocol)이라 불리는 또다른 프로토콜이 존재한다. BOOTP 프로토콜에 따라, 그것은 네트웍 너머의 디스크 없는 클라이언트의 부트 스크랩(bootscrap: 예정된 ruleset에 따라 프로그램을 load하는 방법 - 역자주)을 위한 프로시저를 제공한다.
2.4.1 IP Networks
IP 네트웍은 비슷한 방법으로 구성되었다. 전체 네트웍은 자동화 시스템(autonomous system)이라 불리는 다수의 소규모 네트웍으로 구성된다. 각각의 시스템은 자기 멤버들 간의 라우팅을 수행하여, 목적 호스트의 네트웍으로의 길을 찾기 위하여 데이터를 보내는데 대한 부담을 줄인다. 이는 특정 네트웍에 있는 '어떤' 호스트에 데이터그램이 넘겨지는 즉시, 차후의 프로세싱은 네트웍 자신에 의해 독점적으로 수행됨을 의미한다.
2.4.2 Subnetworks
이 구조는 위에서 설명한 것처럼, IP 주소가 호스트와 네트웍 부분으로 나누어진 것을 반영한다. 기본값으로 목적지 네트웍은 IP 주소의 네트웍 부분으로부터 얻어진다. 그리하여, 동일한 IP 네트웍 번호를 가진 호스트가 발견되거나 혹은 그 반대의 경우이다.
네트웍이, 이더넷과 같은 물리적 네트웍등의 최소단위의 유닛에 일치하는 수백여개의 소규모 네트웍의 모음으로 구성되어 있으므로, 네트웍 내부에서도 동일한 구조를 지니는게 정상이다. 고로, IP를 몇개의 서브넷(subnet)으로 분할하는 것 역시 가능하다.
서브넷은, 그것이 속한 IP 네트웍으로부터 일정범위의 IP 주소로 데이터그램을 보내야하는 의무가 있다. Class A,B,C와 같이, IP 주소의 네트웍 부분이 그 실별의 수단이 된다. 그러나 그 네트웍 부분은 호스트 부분으로 몇비트 더 연장된다. 이 비트수는 subnet mask로 부터 얻어지는 서브넷 번호처럼 해석된다. 이것은 역시나 32비트 수이며, IP 주소의 네트웍 부분에대한 bit mask를 지정한다.
|
||||
|
||||
|
||||
|
그림 2.1: Class B 네트웍의 서브넷화
Groucho Marx University의 교내 네트웍도 그런 네트웍 중의 한가지 일례이다. 그것은 149.76.0.0이라는 Class B 네트웍이고 넷 매스크는 255.255.0.0이다.
내부적으로, GMU의 교내 네트웍은 여러학과의 LAN과 같은 몇개의 소규모 네트웍으로 구성되어 있다. 그러므로 IP 주소의 범위는 254개의 서브넷, 즉 149.76.254.0까지로 나누어진다. 일례로 이론 물리학(Theoritical Physics)과는 149.76.12.0로 설정되어 있는 것이다.
campus backbone은 그 자체로 네트웍이고 149.76.1.0의 주소가 주어져 있다. 이러한 서브넷들은 3번째 옥텟이 서로 다르지만 같은 IP 네트웍 번호를 똑같이 가지고 있기도 하다. 그러므로 이들 모두 255.255.255.0의 서브넷 매스크를 사용한다.
그림 2.1은 quark의 주소, 149.76.12.4가 평범한 Class B 네트웍으로 다루어질 때와 서브넷으로 사용될 때 어떻게 다르게 해석되는지 보여준다.
서브네팅(subnetting:서브넷을 이루는 기술)은 단지 네트웍의 내부적 분할일 뿐이다. 서브넷은 네트웍 소유자(또는 관리자)가 만든다. 종종, 서브넷은 존재하는 (두 이더넷 사이의) 물리적, (양 분과 사이의) 관리적, 또는 지리적인 경계를 반영하여 만들어지고, 이런 서브넷에대한 권한은 그에 가까이 있는 이에게 위임한다. 그러나 이 구조는 단지 네트웍의 내부적 성향에 영향을 줄 뿐이고 완벽하게 외부세계에 보이지 않도록 차단되어 있다.
2.4.3 Gateways
서브네팅은 조직적인 이득일 뿐 아니라, 하드웨어 범위의 자연스런 결과물이기도 하다. 이더넷과 같은 물리적 네트웍 상의 호스트의 시점은 아주 제한적이다. 즉, 호스트가 직접적으로 대화할 수 있는 것은 그 네트웍 내에 있는 것들 뿐이다. 그 외의 모든 호스트들에는 게이트웨이(gateway)라는 것을 통해서만 접근할 수 있다. 게이트웨이는 둘 또는 그 이상의 물리적 네트웍에 동시에 연결되어 있고, 그들간에 패킷을 교환하도록 설정된 것이다.
호스트가 로컬의 물리적 네트웍에 있는지 IP가 쉽게 인식할 수 있도록, 다른 물리적 네트웍은 서로다른 IP 네트웍에 속해 있어야 한다. 예를 들어, 149.76.4.0라는 네트웍 번호는 수학과 LAN의 호스트를 위해 예약되어 있다. quark로 데이터그램을 보낼 때, erdos의 네트웍 소프트웨어는 IP 주소, 149.76.12.4를 보고 목적지 호스트가 다른 물리적 네트웍 상에 있다는 것, 즉 게이트웨이(기본값으로 sophus)를 통해서만 도달 가능하단 것을 알게된다.
sophus 자체는 두개의 서로다른 서브넷에 연결되어 있다. 즉, 수학과와 campus backbone이 그것이다. 그것은 그 둘을 서로다른 인터페이스, 즉 eth0와 fddi0로써 각각 접근한다. 이제 어떤 IP를 그것에 설정해야 하는가? 서브넷 149.76.1.0 중의 하나인가? 아님 149.76.4.0 의 것을 줘야 하는 것일까?
그 답은 둘다이다. 수학과 LAN과 교신할 때 sophus는 149.76.4.1의 IP 주소를 사용하고, backbone과 대화할 때 149.76.1.4를 쓴다.
그리하여, 게이트웨이는 그것이 물려있는 네트웍당 하나씩의 IP 주소를 배정받는다. 이러한 주소(동일한 넷 매스크에 따른)는 서브넷이 그것을 통해 접근하는 인터페이스에 묶여있다. 고로, 인터페이스의 매핑과 sophus의 주소는 다음과 같다.
| iface | address | netmask |
|---|---|---|
|
eth0 fddi0 lo |
149.76.4.1 149.76.1.4 127.0.0.1 |
255.255.255.0 255.255.255.0 255.0.0.0 |
그림 2.2는 Groucho Marx University(GMU) 네트웍의 토폴로지(topology: 번역하자면... '위상 또는 형상' 정도 - 역자주)을 보여준다. 두 서브넷간에 동시연결된 호스트들은 모두 두개의 주소를 갖고 있다.
그림 2.2: GMU 넷 토폴로지의 일부분
일반적으로 주소를 호스트에 배속하는 것인가, 혹은 인터페이스에 배속하는 것인지에 대한 미묘한 차이는 무시할 수 있다. 즉, erdos와 같이 하나의 네트웍에 물려있는 호스트의 경우에선, 엄격히 말하자면 이더넷 인터페이스가 이 주소를 지니는 것이지만, 보편적으로 호스트가 IP 주소를 가진다고 말한다. 그러나 게이트웨이를 논할 때 이 차이는 정말로 중요한 것이다.
2.4.4 The Routing Table
이제, 리모트 네트웍으로 데이터그램을 보낼때, 어떻게 IP가 게이트웨이를 선별하는지 살펴보자.
우리는 일전에, erdos가 quark에게 데이터그램을 보낼 때, 목적지 IP 주소를 검사하여 로컬 네트웍상에 존재하지 않음을 알아내는 것을 본 적이 있다. 그리하여 그것은 기본 게이트웨이인 sophus에게로 그것을 보내게 되는데, sophus 역시 기본적으로 똑같은 일을 하게 된다. sophus는 quark가 직접연결된 호스트가 아니라는 것을 알게되고, 다시금 그것을 포워드 시켜줄 다른 게이트웨이를 찾아야한다. 알맞은 선택은 물리학과의 게이트웨이인 niels일 것이다. 그리고 sophus는 목적지 네트웍의 적절한 게이트웨이를 찾기위해 몇가지 정보를 필요로 한다.
IP가 이를 위해 사용하는 라우팅 정보는, 단순히 네트웍을 그와 접하는 게이트웨이와 링크시키는 테이블이다. 일반적으로 잡동사니 정보(기본 루트:default route)도 역시 제공되는데, 이는 네트웍 0.0.0.0에 관련된 게이트웨이이다. 알수 없는(unknown:테이블 내에 존재하지 않는) 네트웍에로의 모든 패킷은 기본 루트로 보내진다. sophus의 테이블은 다음과 같다.
| Network | address | Interface |
|---|---|---|
|
149.76.1.0 149.76.2.0 149.76.3.0 149.76.4.0 149.76.5.0 . . . 0.0.0.0 |
- 149.76.1.2 149.76.1.3 - 149.76.1.5 . . . 149.76.1.2 |
fddi0 fddi0 fddi0 eth0 fddi0 . . . fddi0 |
sophus가 직접 연결할 수 있는 네트웍에의 루트는 게이트웨이를 필요로하지 않으며, 목록에 "-"로 되어 있다.
라우팅 페이블은 여러 의미에서 만들어질 수 있다. 소규모 LAN의 경우, 부팅시에(5장을 보라) IP가 route 커맨드를 사용하도록 구성해 놓는 것이 대부분의 경우 가장 효과적이다. 보다 큰 규모의 네트웍에서는 run-time에 라우팅 데몬(routing daemon)이 그것을 구성하고 조정한다. 라우팅 데몬은 네트웍의 중앙호스트에서 돌아가고, 각 네트웍 구성원 간의 "최적의" 루트를 산출하기 위해 라우팅 정보를 교환한다.
네트웍의 규모에 따라, 다른 라우팅 프로토콜이 사용된다. 자동화 시스템(Groucho Marx Campus와 같은)내에서의 라우팅의 경우, 내부 라우팅 프로토콜(internal routing protocol)이 사용된다. 그 대표적인 것이 RIP(Routing Information Protocol)로, BSD routed 데몬에의해 사용된다. 자동화 시스템간의 외부 라우팅 프로토콜(external routing protocol)에는 EGP(External Gateway Protocol)이 사용된다. 이들은 (RIP 처럼) Cornell 대학의 gated 데몬이 사용한다.
2.4.5 Metric Values
RIP기반의 동적 라우팅은 목적지 호스트 또는 "hops"의 수에 기반한 네트웍으로의 최상의 루트를 선택한다. 즉, 실제연결전에 먼저 데이터그램은 게이트웨이를 통과해야한다. 가장 짧은 루트는 RIP율이 높은 것이다. 16 또는 그 이상의 hops를 갖는 아주 긴 루트는 사용 불가능하다고 간주되어, 곧 폐기된다.
당신의 로컬 네트웍 내부의 라우팅정보를 관리하기 위해서 RIP를 사용하고자 한다면 모든 호스트에 gated를 돌려야한다. 부팅시에, gated는 작동중인 모든 인터페이스를 체크하여 만약 하나 이상의 인터페이스(루프백 인터페이스는 계산하지 않는다.)가 발견되면 그것은 그 호스트가 몇몇 네트웍간에 패킷을 교환한다고 가정하고, 실제로 라우팅 정보를 교환하며 broadcast한다. 그렇지 않을 경우, 그것은 단지 RIP 업데이트를 수동적으로 받아 로컬 라우팅 테이블을 업데이트 한다.
로컬 라우팅 테이블의 정보를 broadcast할 때, gated는 라우팅 테이블 엔트리와 관련된 메트릭 값(metric value)이라는 것에서 루트의 길이를 산출한다. 이 메트릭 값은 시스템 관리자가 루트를 설정할 때, 그것을 사용함에 있어 발생하는 부담을 감안하여 설정된다. 거기다, 호스트가 직접연결되어 있는 서브넷으로의 루트가 가지는 메트릭 값은 언제나 zero이며, 두개의 게이트웨이를 통하는 루트는 그의 메트릭 값을 가질 것이다. 그러나, RIP나 gated를 사용하지 않을 계획이라면 메트릭이라는 것에 신경을 꺼도 된다는 사실을 강조하고 싶다.
2.5 The Internet Control Message Protocol
IP에겐, 우리가 아직 논하지 않았던 동료 프로토콜이 있다. 이것은 바로 ICMP이며, 커널의 네트워킹 코드가 다른 호스트와 에러 메세지 같은 것을 교환할 때 사용된다. 다시금 erdos를 사용한다는 가정하에, quark의 12345번 포트로 telnet를 시도하나, 그 포트에는 listening 프로세스가 없다. 그렇다면 처음 TCP 패킷이 quark의 포트로 접근할 때, 네트워킹 레이어(layer)는 이것을 감지하여 즉시 "Port Unreachable"이라는 ICMP 메시지를 되돌릴 것이다.
ICMP가 이해하는 메시지는 꽤 되는데, 대부분의 것들은 에러상태와 관계있는 것이다. 그러나 아주 재미있는 메시지가 하나 존재하는데, 그것은 바로 Redirecting 메시지라 불리는 것으로, 라우팅 모듈이 보다 짧은 루트가 존재하는데도 자신을 게이트웨이로 사용하는게 감지될 때 그 메시지를 발생시킨다. 예를들자면 부팅 후, 수학과 네트웍을 포함하여, sophus의 FDDI backbone으로의 라우팅 테이블은 불완전할 수도 있다. 그리고 기본 루트는 Groucho Computing Center의 게이트웨이(gcc1)를 가리키고 있다. 그러므로 어떤 패킷이 물리학과의 게이트웨이인 niels로 보내지지 않고 gcc1에게 보내질 수도 있다는 것이다. 이런 데이터그램을 받으면 gcc1은 이것이 바보같은 루트 선택이라고 알고, 그 패킷을 niels에게 포워드 할 것이다. 그와 동시에 sophus에게는 ICMP redirecting 메시지가 최적의 루트를 전하러 되돌아 올 것이다.
이제, 기본 루트마저도 수동으로 설정하지 않는 것이 현명한 것처럼 보인다. 그러나, 동적인 라우팅 체계에만 의존하는 것, RIP 또는 ICMP Redirecting 메시지는 언제나 좋은게 아니라는 것에 주의하자. ICMP Redirec와 RIP에는 어떤 라우팅 정보가 정말로 믿을만한 것인가에대한 확신이 거의 없다. 이것은 심술궂게 아무런 이득없이 네트웍을 혼란시키거나 악영향(삽질)을 줄 수도 있다. 이러한 이유에서, 리눅스 네트워킹 코드의 어떤 버전은 네트웍 루트에 영향을 주는 Redirecting 메시지를 단지 호스트의 루트에만 적용되는 Redirect로 취급한다.
2.6.1 Hostname Resolution
앞서 기술한 것처럼, TCP/IP 네트웍의 주소는 32비트 수이다. 그러나, 이것을 일일히 외우기란 여간 힘든 일이 아니다. 그리하여 호스트는 "통상적인" 이름, 즉 gauss 또는 strange같은 이름으로 알려진다. 이제 이 이름에 상응하는 IP 주소를 찾아내는 것이 어플리케이션의 관건이다. 이러한 프로세스를 호스트명 분석(hostname resolution)이라 한다.
주어진 호스트명의 IP 주소를 찾기 원하는 어플리케이션은 그에 대한 루틴을 따로 필요로 하지 않고, 대신에 이를 쉽게 하기 위해 gethostbyname(3)과 gethostbyaddr(3)같은 다수의 라이브러리 함수에 의존한다. 전통적으로, 이들과 관계된 여러 프로시저들은 resolver library라는 것으로 따로 묶여져 있다. 리눅스에서 이것들은 표준 libc의 일부분이며, 구어체로 이러한 함수의 모음을 "the resolver"라 한다.
이제, 이더넷같은 소규모 네트웍, 또는 그에대한 작은 조각이라도 호스트명을 주소로 매핑하는 테이블을 유지하기 어렵지 않다. 이 정보는 주로 /etc/hosts 파일에 보존된다. 호스트를 더하고 삭제하고 주소를 재지정할 때 해야하는 일은 단지 hosts파일을 업데이트하는 일 뿐이다.틀림없이, 이것은 소량의 머신에서는 모르지만 그 수가 많으면 많을 수록 짐스러운 것이 된다.
이러한 문제점을 해결하는 한가지 해결안이 Sun Microsystems에서 개발한 NIS(Network Information System)이며, 통상적으로 YP(Yellow Page)라 부른다. NIS는 hosts 파일(그리고 또 다른 정보)을 마스터 호스트의 데이터베이스에 저장하고 클라이언트로 하여금, 필요할 때 얻어 쓸 수 있도록 한다. 그러나 아직, 이러한 접근방식은 LAN과 같은 중간규모의 네트웍에서나 적당한데, 왜냐 하면 hosts 데이터베이스를 중앙 집중적으로 유지하고 모든 서버에게 그것을 보급하기 때문이다.
인터넷에서, 주소정보는 HOSTS.TXT DB에 내부적으로 역시 저장된다. 이 파일은 NIC에서 관리하고 관계 사이틀에의해 다운로드되어 설치된다. 네트웍이 성장할 수록 이런체계에는 몇가지 문제점이 나타나는데, 그것은 정기적인 HOSTS.TXT의 설치에 따르는 관리 비용이다. 즉, 그것을 배포하는 서버의 부담이 커진다는 것이다. 그 외에 더 큰 문제점은, NIC에 등록되는 이름은 중복되지 않아야 한다는 것이다.
이것이 바로 1984년 새로운 호스트명 분석체계인 Domain Name System이 채택된 이유이다. DNS는 Paul Mokapetris가 디자인한 것으로 두 문제점을 해결한다.
DNS는 호스트명을 도메인(domain)의 계층구조로 구성한다. 도메인은 더떤 관념에 연관된 사이트의 모음이다. - 그들이 고유한 네트웍(즉, 교내의, 또는 BITNET의 모든 머신)을 구성하므로 그렇다. 왜냐 하면 그들은 모두 특정한 조직(미 합중국 정부와 같은)에 속해 있거나, 단순히 지리상으로 가까이 있기 때문인데, 예를 들어 대학교는 edu 도메인으로 묶이고, 각 대학 또는 단과대학은 그들 호스트가 포괄된 서브도메인(subdomain)으로 나뉜다. Groucho Marx University는 groucho.edu라는 도메인을 얻는다. 그리고 수학과의 LAN은 maths.groucho.edu로 지정된다. 분야별 네트웍의 호스트는 이 도메인명에 그 호스트명이 첨가된다. 그러므로 erdos는 erdos.maths.groucho.edu로 불리게 되는 것이다. 이를 일컬어 fully qualified domain name또는 FQDN이라 하고, 이는 호스트명을 전세계적으로 유일한 것으로 만든다.
그림 2.3: name space의 일부분
그림 2.3은 name space의 일부분을 보여준다. 점 하나로 지시되는 이 트리(tree)의 근원을 root 도메인이라 부르고, 다른 모든 도메인을 포괄한다. 호스트명이 로컬 도메인과 연관된 (절대적인) 이름이 아니라, FQDN일 때, 그것은 끝에 점이 붙는다. 이는 이름의 마지막 요소가 루트 도메인이라는 것을 인식토록 한다.
계층구조내의 위치에 따라, 도메인은 top-level, second-level, third-level로 각각 불릴 수 있다. 물론 더 분할 될 수 있으나 드문일이다. 다음의 것들이 흔히볼 수 있는 top-level 도메인이다.
| edu | (대부분 US) 대학과 같은 교육기관 등. |
|---|---|
| com | 상업조직, 회사. |
| org | 비 영리단체, 주로 개인 UUCP 네트웍이 이런 도메인에 속한다. |
| net | 게이트웨이와 네트웍 관리 호스트 |
| mil | US 군 기관 |
| gov | US 정부기관 |
| uucp | 공식적으로, 이전에 도메인 없이 UUCP명으로 사용되던 사이트들이 옮겨진 도메인 |
기술적으로, 처음의 4개는 인터넷에서 미국이 차지하는 부분이다. 그러나 이러한 도메인 내에서 미국 사이트가 아닌 것들도 있다. net 도메인의 경우 이렇지만 mil과 gov는 독점적으로 미국에서만 쓰인다.
미국 이외의 각 국가들은 일반적으로 자신의 고유명 뒤에, ISO-3166으로 정의된 2글자의 국가코드가 첨부된다. 예를 들어 핀란드는 fi 도메인을, 프랑스는 fr, de는 독일이, au는 오스트레일리아가, 그리고 한국은 kr을 사용하는 식이다. top-level 도메인하의 각 국가의 NIC가 호스트명을 어떠헥 조직하는가는 자유롭다. 오스트레일리아의 경우를 예로 들면, second-level 도메인이 국제적인 top-level도메인과 비슷하다. 즉, com.au, edu.au 등의 식이다. 반면, 독일의 경우 이러한 별도의 level을 사용하지 않고, 약간 긴 듯한 이름으로 특정도메인을 운영하는 조직을 직접 언급한다. 즉, ftp.infomatik.unierlangen.de라는 이름이 비 정상적이지 않다는 것이다. 독일식의 능률성을 탓하라.
물론, 이러한 국가별 도메인 하에 존재하는 도메인이 그 국가에 실제로 위치한다는 것을 의미하진 않는다. 즉, 그것은 단지 그 국가의 NIC에 도메인을 요청했다는 것만을 의미할 뿐이다. 이를테면 오스트레일리아에 지사를 낸 스웨덴 회사의 모든 호스트는 여전히 se top-level 도메인에 요청된다는 것이다.
이제, name space를 계층화함으로써 고유성이란 문제를 해결할 수 있게 되었다. 다시 말해, DNS는 하나의 도메인 내에서 고유한 호스트명이 세계적으로도 다른 호스트들과 차별되게 한다. 게다가 FQDN은 외우기도 쉽다. 이것들이 큰 도메인을 소규모의 서브넷으로 나누는 까닭이다.
그러나 DNS에는 이외에도 또 다른 역할이 있는데, 그것은 서브도메인에대한 권한을 그 관리자에게 위임할 수 있게 하는 것이다. 예로, Groucho Computer Center는 각 학과마다 서브도메인을 만들 수 있다. (이미 우리는 위에서 maths와 physics 서브도메인을 본 적이 있다.) 물리학과의 네트웍이 만약 외부에서 관리하기에 너무 크거나 혼란스럽다면(물리학자들은 무질서한 사람들의 무리라고 알려져 있다.), 단순히 physics.groucho.edu 도메인의 관리자에게 통제권을 넘겨주면 된다. 이렇게 되면 외부의 간섭없이 어떤 호스트명을 쓰건, 자기 네트웍 내에 허용된 어떤 IP 주소를 지정하건 자유롭다.
name space는 각 도메인마다 그에 근원을 둔 zone으로 분할된다. zone과 도메인의 미묘한 차이점에 대해 보자면, groucho.edu라는 도메인은 GMU의 모든 호스트를 포괄하나, groucho.edu라는 zone은 단지 Computing Center에서 직접 운영하는 호스트만을 포함한다. 예를 들자면 수학과의 호스트들이 그에 해당한다 하겠다. 그리고 물리학과는 또 다른 zone인 physics.groucho.edu에 속한다. 그림 2.3에서 zone의 시작점에는 도메인명 오른쪽에 작은 동그라미 표시가 되어 있다.
처음 흘깃보면, 모든 도메인과 zone이 어떻구 법석떠는 것이 도메인명 분석을 위해 엄청나고 복잡한 일을 하는 듯이 보이나, 결국 호스트명이 어떻게 지정되었는지에 대한 중앙적인 통제가 없다면 하찮은 어플리케이션이 어떻게 알 수 있을까?!
이제, DNS의 독창적인 면을 보자. erdos의 IP 주소를 찾기 원할 때 DNS는 그것을 관리하는 사람에게 물어보면 알려줄 것이라 할 것이다.
사실상 DNS는 대규모의 분산 데이터베이스이며, 도메인 또는 도메인의 무리에 정보를 공급하는 네임서버(name server)의 의미로 사용된다. 각 zone마다, 적어도 두개의 네임서버가 있으며, 이는 그 zone내의 호스트에 관한 모든 권위적인 정보를 가진다. erdos의 IP 주소를 얻기 위해서는 단지, groucho.edu zone의 네임서버에 접촉하기만 하면 된다. 그러면 그것은 원하는 데이터를 돌려줄 것이다.
말이야 쉽다고 생각할 수도 있다. 그러면 어떻게 GMU의 네임서버에 연락하는지 난 어떻게 알 수 있을까? 당신의 컴퓨터에 주소분석 신탁소(oracle)가 없다는 것에 대해 DNS는 역시나 대비한다. 당신의 어플리케이션이 erdos의 정보를 검색하고자 할 때, 반복질의(iterative query)를 수행하는 로컬 네임서버에 접촉한다. 그리고 로컬네임서버는 root 도메인의 네임서버에 질의를 보냄으로써 erdos.maths.groucho.edu의 주소를 묻는다. 그러면 root 네임서버는 이 이름이 자신의 zone에 속하지 않고 edu도메인의 하위에 존재한다는 것을 알게되어, 당신에게 더 세부적인 정보를 위해 edu 도메인에 접촉하길 권하며 모든 edu 네임서버의 주소가 담긴 목록을 넘겨준다. 그러면 이제 당신의 로컬 네임서버는 그들 중 하나, 예를 들자면 a.isi.edu에 질의를 보내고, root 네임서버와 같은 양식에서 a.isi.edu는 groucho.edu라는 zone이 있다는 것을 알고 그것의 서버를 지정해 줄 것이다. 그러면 로컬 네임서버는, erdos에 대한 질의를 그 이름이 자신의 zone에 속해있다는 것을 인식하는, 이들중 하나에 보낼 것이고, 그에 상응하는 IP 주소가 되돌아 올 것이다.
이것은 시시한 IP 주소를 위해 무수한 traffic을 발생시키는 것 처럼 보이나, HOSTS.TXT를 고수할 때 이동하는 데이터 량에 비교한다면 정말 극소량일 뿐이다. 그러나 이러한 구조에도 개선의 여지가 남아있다.
질의에 걸리는 시간을 개선하기 위해서, 네임서버는 얻어진 정보를 로컬 캐쉬(local cache)에 담아둔다. 그리하여 다음에 어떤이가 groucho.edu 도메인을 검색한다면, 당신의 네임서버는 모든 프로세스를 다시 거치지 않고 직접 groucho.edu 네임서버에 갈 것이다.
물론, 이 네임서버는 이 정보를 영원히 유지하진 않고, 일정시간 경과후에 그것을 파기하는데, 이러한 기한 만료의 간격을 time to live(TTL)이라 한다. DNS DB내의 각 자료는 zone의 관리자에 의해 TTL 같은 것이 지정된다.
zone 내의 호스트에 대한 모든 정보를 가지는 네임서버들은 zone에 대한 권한을 가지고 있다고 하고, 때때로 마스터 네임서버라 지칭되기도 한다. 이 zone 내의 호스트에 대한 질의는 결국 마스터 네임서버 중 하나에게 올 것이다.
zone에 대한 논리적인 그림을 제시하기 위해, 마스터 서버는 동기화(syncronized)되어야 하는데, 이는 그들중 하나를 데이터파일에서 zone 정보를 읽어내는 주(primary) 서버로, 그리고 그것에서 또 하나를 일정간격으로 zone 데이터를 전송받는 보조(secondary) 서버를 만듦으로써 이루어진다.
몇개의 네임서버가 있는 이유는 하중을 할당하기 위한 것이 한가지 이유이고, 또 다른 이유는 여분을 위한 것이다. 한 서버가 네트웍의 붕괴 또는 실추같은 것으로 인해 죽어 있다면 모든 질의는 다른 서버로 돌려진다. 물론, 이런 구조가 잘못된 reply를 모든 DNS request에 대해 보내는 서버의 오동작을 (예를 들면, 서버프로그램의 버그에 의한) 방지해 주진 않는다.
물론 어느 도메인에게서도 인증받지 않은 네임서버의 경우도 생각할 수 있다. 이런 종류의 서버도 로컬 네트웍에서 실행되는 어플리케이션을 위해 DNS 질의를 역시나 수행하고, 정보를 캐쉬할 수 있다는 점에서 유용한데, 이를 일컬어 caching-only server라 한다.
우리는 앞서, DNS가 단지 호스트의 IP 주소만을 다루진 않는다는 것을 보았다. 즉, 네임서버의 정보를 교환하기도 하는 것이다. 이제 DNS 데이터베이스의 서로다른 부류를 보도록 하자.
DNS 데이터베이스의 단일 정보를 일컬어 resource record, 짧게는 RR이라 한다. 각 레코드는 DNS 데이터베이스가 제공하는 데이터의 성질을 묘사하는데 관련된 타입(type)을 지니고, 클래스(class)는 그것이 적용되는 네트웍을 특정화한다. 후자는 IP 주소와 같은 (IN 클래스)나 Hesiod 네트웍(MIT에서 사용된)의 주소 등과 같은 서로다른 주소체계의 필요성을 수용한다. 초기적인 RR 타입은 IP 주소와 FQDN만을 가지는 A 레코드이다.
물론, 호스트는 여러개의 이름을 가질 수 있다. 그러나 이들 중 하나만이 공식적인(canonical host name: 인가된 호스트명) 것으로 인정받을 수 있고, 그외의 것들은 그에대한 alias로 존재한다. 그 차이점은 canonical 호스트명만이 유일하게 A 레코드와 관련되어 있고, 나머지는 그 canonical 호스트명을 가리키는 CNAME 타입의 레코드를 가진다는 것이다.
여기서 모든 레코드 타입을 살펴보진 않고 차후의 장을 위해 남겨두나, 간단한 예제정도는 살펴보자. 그림 2.4는 physics.groucho.edu zone의 네임서버에 의해 읽혀지는 도메인 DB의 일부분이다.
;
; Authoritative Information on physics.groucho.edu
@ IN SOA {
niels.physics.groucho.edu.
hostmaster.niels.physics.groucho.edu.
1034 ; serial no
360000 ; refresh
3600 ; retry
3600000 ; expire
3600 ; defalut ttl
}
;
; Name servers
IN NS niels
IN NS gauss.maths.groucho.edu.
gauss.maths.groucho.edu. IN A 149.76.4.73
;
; Theoretical Physics (subnet 12)
niels IN A 149.76.12.1
IN A 149.76.1.12
nameserver IN CNAME niels
otto IN A 149.76.12.2
quark IN A 149.76.12.4
down IN A 149.76.12.5
strange IN A 149.76.12.6
...
; Collider Lab. (subnet 14)
boson IN A 149.76.14.1
muon IN A 149.76.14.7
bogon IN A 149.76.14.12
...
|
A와 CNAME과는 별도로, 파일의 최상단에 몇줄 적힌 특수 레코드가 보이는데, 이것은 SOA(Start of Authority)타입의 RR로, 서버가 인증하는 zone상의 일반적 정보를 안고있다. 예를 들어, 이것은 모든 레코드의 TTL 기본값을 포함한다.
예제 파일에서 점으로 끝나지 않는 이름은 groucho.edu 도메인 내의 것으로 해석된다. SOA 레코드의 특수명 "@"은 도메인명 자체를 가리킨다. 우리는 앞서 groucho.edu 도메인의 네임서브들이 물리학과의 네임서버에 질의를 보내려면, physics zone에 대해 알아야 한다는 것을 보았다. 이는 레코드 쌍에 의해 이루어진다. 즉, NS 레코드는 서버의 FQDN을, 그리고 A 레코드는 그 이름의 주소를 제공한다. 이러한 레코드가 name space를 같이 지니는 것이기 때문에 흔히 glue 레코드라 불린다. 그것들은 단지 하위 zone의 호스트에 대한 정보를 실제로 가지는 상위 레코드의 실례일 뿐이다. 그림 2.5에서 보듯 glue 레코드는 physics.groucho.edu의 네임서버를 지칭한다.
;
; Zone data for the groucho.edu zone.
@ IN SOA {
vax12.gcc.groucho.edu.
hostmaster.vax12.gcc.groucho.edu.
233 ; serial no
360000 ; refresh
3600 ; retry
3600000 ; expire
3600 ; default ttl
}
....
;
; Glue records for the physics.groucho.edu zone
physics IN NS inels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics IN A 149.76.12.1
gauss.maths IN A 149.76.4.23
...
|
한 호스트에 배속된 IP 주소를 검색하는데 있어, 그 주소에 상응하는 canonical 호스트명을 찾을 필요가 때때로 있다. 이를 가리켜 reverse mapping이라 부르고 클라이언트의 신원을 확인하는 목적으로 몇몇 네트웍 서비스에서 사용된다. 단일한 hosts 파일을 사용한다면, 역방향 검색(reverse lookup)은 단순히 파일에서 질의한 IP를 가지는 호스트를 찾을 것이다. DNS의 경우, name space에 대한 소모적인 검색이란 말할 필요도 없이 불가능한 것이다. 그 대신, 특수한 도메인인 in-addr.arpa는 dotted-quad notation을 IP 주소 149.76.12.4는 4.12.76.149.in-arpa.arpa라는 이름과 동일하다. 이러한 이름을 그것의 canonical 호스트명으로 연결하는 RR 타입이 바로 PTR이다.
권한구역(authoritative zone)을 생성하는 것은 그 관리자에게 호스트명에 주소를 부여하는 권한을 전임했음을 의미한다. 보통 하나또는 그 이상의 IP 네트웍 또는 서브넷이 그들 손에 주어져 있고, DNS zone과 IP 주소 사이에는 하나 또는 그 이상의 매핑이 존재한다. 물리학과를 예로 들면, 서브넷 149.76.8.0, 149.76.12.0, 그리고 149.76.12.0을 포함한다.
결과적으로 in-addr.arpa 도메인의 새로운 zone은 physics zone을 따라 생성되어야 하고, 그 네트웍의 관리자에게 위임해야 한다. 즉, 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa, 그리고 14.76.149.in-addr.arpa같은 것들이 되겠다. 반면, Collider Lab에 새 호스트를 설치하려면 in-addr.arpa zone 파일에 새 주소를 넣기 위해 그 상위 도메인을 접촉해야 한다.
서브넷 12의 zone DB를 그림 2.6에서 보여준다. 상위 zone DB내의 동일한 glue 레코드는 그림 2.7에 있다.
;
; the 12.76.149.in-addr.arpa domain
@ IN SOA {
niels.physics.groucho.edu.
hostmaster.niels.physics.groucho.edu.
233 360000 3600 3600000 3600
}
2 IN PTR otto.physics.groucho.edu.
4 IN PTR quark.physics.groucho.edu.
5 IN PTR down.physics.groucho.edu.
6 IN PTR strange.physics.groucho.edu.
|
이것의 한가지 중요한 결과물은 zone이 IP 네트웍의 superset으로써만 생성될 수 있는 것이다. 그리고 더 심한 것은 이들 네트웍의 netmask는 byte 범위어야 한다는 것이다. 각 서브넷마다 in-addr.arpa zone이 생성될 수 있는바, 모든 GMU의 서브넷은 255.255.255.0의 netmask를 지닌다. 그러나 만약, 그 대신 netmask가 255.255.255.128이면 서브넷 149.76.12.128의 zone을 생성하는 것은 불가능하다. 왜냐하면 DNS에게 12.76.149.in-addr.arpa 도메인이 1에서 127, 그리고 128에서 255까지의 범위를 가지는 2개의 권한 구역으로 분할됨을 알릴 수 없기 때문이다.
;
; the76.149.in-addr.arpa domain.
@ IN SOA {
vax12.gcc.groucho.edu.
hostmaster.vax12.gcc.groucho.edu.
233 360000 3600 3600000 3600
}
...
; subnet 4: Mathematics Dept.
1.4 IN PTR sophus.maths.groucho.edu.
17.4 IN PTR erdos.maths.groucho.edu.
23.4 IN PTR gauss.maths.groucho.edu.
...
; subnet 12: Physics Dept, separate zone
12 IN NS niels.physics.groucho.edu.
IN NS gauss.maths.groucho.edu.
niels.physics.groucho.edu. IN A 149.76.12.1
gauss.maths.groucho.edu. IN A 149.76.4.23
...
|
1. Introduction to Networking
2. Issues of TCP/IP Networking
3. Configuring the Networking Hardware
4. Setting up the Serial Hardware
5. Configuring TCP/IP Networking
6. Nake Service and Resolver Configuration
7. Serial Line IP
8. The Point-to-Point Protocol
9. Various Network Applications
10. The Network Information System
11. The Network File System
12. Managing Taylor UUCP
13. Electronic Mail
14. Getting smail Up and Running
15. Sendmail+IDA
16. Netnews
17. C News
18. A Description of NNTP
19. Newsreader Configuration
A. A Null Printer Cable for PLIP
B. Sample smail Configuration Files
C. The GNU General Public License