이 장에서는 여러분의 리눅스 머신을 TCP/IP 네트워크로 연결할 때, 부딪치게 될 세부사 항들과 IP 어드레스, 호스트 네임, 라우팅의 유래에 관해 알아본다. 그리고, 필요한 설정작업을 이 해하기 위해서 알아야 되는 기본적인 개념들과, 이러한 설정작업에 필요한 도구들을 다루어 보기로 하자.
네트워킹 환경에서 사용되는 설비의 다양성을 감추기 위해서, TCP/IP는 하드웨어를 제어하 기 위 한 하나의 추상적인 interface를 정의해 두고 있다. 이 인터페이스는 한 쌍의 연산자를 제공한다. 그리고, 그것은 모든 종류의 하드웨어를 같은 형태로 두고, 패킷을 보내고 받는 작업을 한 다.
네트워크에 사용되는 각 주변장치들은 그에 해당하는 인터페이스가 커널에 표시되어 있어 야 한다. 예를 들어, 리눅스에서 사용하는 Ethernet 인터페이스는 eth0 그리고, eth1 로 표시되어 있고, SLIP 인터페이스는 sl0, sl1 등등으로 표시되어 있다. 이들 인터페이스의 이름은 여러분이 커널에 특별한 물리적인 장치의 이름을 매기고 싶을 때, 구성 목적으로 사용한다. 그것들이 꼭 특별한 의미를 가지고 있는 것은 아니다.
TCP/IP 네트워킹을 사용 가능하게 하기 위해서, 하나의 IP 어드레스에 하나의 인터페이스 를 할당해야 한다. IP 어드레스는 전세계에서 통신을 할 경우, 자신의 신분을 밝혀주는 유일한 수단 이 된다. 이 어드레스는 위에서 언급한 인터페이스의 이름과는 다르다. ; 만약 여러분이 인 터페이 스를 문에 비유한다면, 어드레스는 그 문에 붙어 있는 문패와 같다.
여러분이 설정해야 하는 또 다른 장치 인수들이 있다. 이것들중 하나로써 데이터 그램의 최 대 크기를 설정하는 부분이 있다. 이것으로 하드웨어의 특별한 부분들을 처리할 수 있다. 이것을 MTU 또는 Maximum Transfer Unit라고 부른다. 다른 속성들은 다음에 소개하기로 하자.
1 장에서 언급한대로, IP 네트워킹 프로토콜이 이해할 수 있는 어드레스수는 32비트이다. 네트워 킹 환경에 있는 모든 기계들은 이 수의 범위내에서 할당할 수 있다. 만약 여러분이 다른 네트워 크와의 TCP/IP 교환이 이루어지지 않는 일반적인 지역 네트워크를 운영하고 있다면, 여 러분의 개인 취향에 따라 이들 번호들을 할당할 수 있을 것이다. 그러나, 인터넷에 있는 모든 사이 트들은 중앙기관 즉, NIC - Network Information Center - 대개, 프로바이더들이 여러분에게 IP address를 할당하며, 여러분은 그것을 사야한다. 또는 여러분들이 원하는 IP address를 직접 NIC에 연락해서 구할 수도 있다. 연락 주소는 다음과 같다. hostmaster@internic.net에 의해 그 번호들을 할당 받을 것이다.
IP address를 쉽게 읽기 위해서, octet라고 부르는 네 개의 8비트 수로 나누어 놓았다. 예를 들 어, 0x954C0C04의 IP address를 가지는 quark.physics.groucho.edu는 실제로 149.76.12.4로 쓰여져 있다. 이러한 형태를 dotted quad notation이라 부른다.
이 표기법을 쓰는 또 다른 이유로써, IP address는 맨 앞쪽 옥텟을 network 숫자로, 나머지 부 분을 host 숫자로 구분해 놓고 있다. 여러분이 NIC에게 IP address를 요청할 때, 여러분이 계획한 대로 할당해 주진 않는다. 대신에, 여러분이 하나의 네트워크 숫자를 받았다면, 그 네트워크 범위 내에서 여러분의 선호도에 따라, 모든 유효한 IP address를 할당할 수는 있다.
호스트 부분은 네트워크 규모에 의존하기 때문에 더욱더 작아지거나, 크게될 필요가 있다. 그 러한 여러 가지 필요성을 충족시켜주기 위해 네트워크에도 여러 클래스가 있으며, 이것은 또 다 른 관점에서 IP address를 분할해 놓고 있다.
Class A는 1.0.0.0에서 127.0.0.0까지의 네트워크를 포함하고 있다. 이 네트워크 숫자는 첫 번째 옥텟에 포함되어 있다. 그리고 이것은 24 비트 호스트 부분 즉, 대략 160만 개의 호스트를 허용할 수 있다.
Class B는 128.0.0.0에서 191.255.0.0까지의 네트워크를 포함하고 있 다. ; 네트워크 숫자는 첫 두 옥텟에 포함되어 있다. 그리고 이것은 16320개의 네트워크를 허용하고 있으며, 각 65024개의 호스트를 가지고 있다.
Class B는 192.0.0.0에서 223.255.255.0까지의 네트워크를 포함하고 있다. 네트워크 숫자는 첫 세 옥텟에 포함되어 있다. 그리고 이것은 거의 2백만개의 네트워크를 허용하고 있으며, 최고 254개의 호스트를 가질 수 있다.
224.0.0.0에서 254.0.0.0의 범위내에 있는 주소들은 실험용이거나 미래를 위해 예약되어 있기 때문에, 어떤 네트워크도 명시하지 않는다.
1장에서 보인 것을 예로 든다면,quark의 주소인 149.76.12.4는 Class B에 해당하 는 네트워크 149.76.0.0는 호스트 12.4를 가진다고 말할 수 있다.
위애서 보인 글에서 여러분은 호스트 부분에 있는 각 옥텟이 가능한 모든 값들을 허용하지 않 는다는 사실을 어쩌면 알아차렸을 지도 모른다. 왜냐하면, 모든 0과, 모든 255를 가지는 호스트 숫자들은 특별한 목적을 위해 이미 예약되어 있기 때문이다. 모든 호스트 부분에 있는 주소 비트 들이 0인것은 네트워크를 나타내고, 그 부분이 1인 것은 브로드캐스트 주소라고 부르고, 이것은 네트워크에 명시되어 있는 모든 호스트를 나타낸다. 그래서, 149.76.255.255는 사용할 수 있는 호스트 주소가 아니라, 네트워크 149.76.0.0에 있는 모든 호스트를 나타낸다.
특별히 예약되어 있는 두 개의 네트워크 주소 즉, 0.0.0.0과 127.0.0.0가 있다. 첫 번째 주소는 다른 말로 default route라고 부르고, 그 다음 것은 loopback address라고 부른다. 디폴트 라우트는 IP의 경로 배정 방법에 관한 정보를 포함하고 있으며, 그 내용은 다음에 설명할 것이다.
Network 127.0.0.0 is reserved for IP traffic local to your host.번역을 못한 부분
대개, 어드레스 127.0.0.1은 여러분의 호스트에 loopback interface라고 부르는 특별한 인터페
이스로
할당될 것이며, 그것은 마치 폐쇄회로와 같이 작동한다. TCP 또는 UDP에서 건너온 IP
패킷들은 마치 어떤 네트워크로 도착되고 있는 것과 같이 루프백 인터페이스로 되돌려질
것이다. 이러한 방법으로 여러분이 실제 네트워크를 사용하지 않고도 네트워킹 소프트웨어
를
개발하고 시험할 수 있다. 여러분이 독립형 호스트상에서 네트워킹 소프트웨어를 사용하고
자
할 때, 유용하게 쓰일 수 있는 또 다른 어플리케이션이 있다.
이것이 꼭 특별한 것만은 아니다. 이를테면, 많은 UUCP 사이트들이 IP와의 연결을 가지는
것은 아니지만, 그럼에도 불구하고, 여전히 INN 뉴스 시스템을 실행하고 싶어한다.
리눅스에서 적절한 운영을 할려면, INN은 루프백 인터페이스를 필요로 한다.
이제까지 여러분은 IP address가 어떻게 만들어지는지 보아왔다. 여러분은 그것들이 각각 다른 호스트에 있는 Ethernet상에서 어떻게 사용되는지 궁금할지도 모른다. 결국, Ethernet 프로 토콜은 여섯 개의 옥텟숫자로 호스트를 증명하는데, 그것은 일반적인 하나의 IP address를 가지는 것은 아니다. 그렇지 않은가?
그렇다. 그것은 Ethernet address위에 IP address를 대응시키기 위한 메카니즘이 필요한 이 유 이다. 이것을 다른말로, Address Resolution Protocol 또는 ARP라고 부른다. ARP는 Ethernet를 전혀 제한하지는 않지만, ham radio와 같은 또 다른 형태의 네트워크에서도 사용된다. ARP 에 기 초를 두고 있는 생각으로서, 150여명의 군중속에서 Mr. X. Ample를 찾아야 할 때, 대부분 의 사람 들은 어떻게 할까? ; 주위를 둘러 보면서 그의 이름을 부르면, 그가 대답할 것이다.
ARP가 주어진 IP address와 일치하는 Ethernet address를 찾고자 할 때, Ethernet의 특징중 의 하나인 "브로드캐스팅"을 사용한다. 그것은 네트워크에 있는 모든 지역에 자료를 동시에 보내는 형태이다. ARP가 보내는 브로드캐스트 자료는 IP address를 위한 하나의 질의를 포함하고 있다. 그 자료를 받는 각 호스트는 그 자체의 IP address와 그것을 비교해서, 만약 그것이 일치 한다면, 조회중인 호스트는 그 대답을 ARP로 보낸다. 그 조회중인 호스트는 대답을 보낼 송신자의 Ether net address를 알아낼 수 있다.
물론 여러분은 전세계에 퍼져 있는 무수히 많는 Ethernet을 그 호스트가 어떻게 찾을지, 또 왜 꼭 Ethernet이어야 하는지 궁금할 것이다. 이러한 질문속에는 라우팅이라는 것이 무엇인지 도 포함 하게 된다. 즉, 라우팅은 네트워크에 있는 호스트의 물리적인 위치를 알아내는 것이다. 이것 에 대 해서는 다음 절에서 자세하게 다룰 것이다.
잠깐동안, ARP에 관한 이야기는 접어두기로 하자. 한때, 호스트가 Ethernet address를 발견 해 서, 그것을 ARP 캐쉬에 저장했다. 그래서, 다음번에 자료를 호스트로 보내고자 할 경우, 그것을 위한 질의는 가지고 있지 않았다. 아무리 그러하더라도, 이 정보를 영원히 보존하고자 하는 생각 은 현명하지 못한 것이다. 이를테면, 기술적인 문제로 인해 리모트 호스트의 Ethernet 카드 를 대 신할 수도 있다. 그래서, ARP는 그다지 쓸모가 없게 되었다. IP address를 위한 또 다른 질의를 추출해내기 위해서, ARP 캐쉬에 있는 개체들을 언젠가는 버리게 된다.
때때로, 주어진 Ethernet address와 관련되어 있는 IP address를 발견하는 것도 필요하다.
이
것은 디스트없는 기계가 네트워크에 있는 서버로부터 부트하고자 할 경우에 발생한다. 랜
에서는
이러한 현상이 결코 드물지만은 않다. 그러나 디스트없는 클라이언트는 가상적으로 그 자체
에 관
한 어떠한 정보도 가지고 있지 않다. - Ethernet address를 제외하고! So what it basically does is broadcast a message containing a plea for boot servers to tell it its IP address. 이것을 위한 또 다른 프로토콜 즉, Reverse Address Resolution Protocol
또는 RARP가 있다. BOOTP 프로토콜과 함께, 이것은 네트워크를 통해 디스크없는 클라이
언트를
부트스트랩핑하기 위해 정의해 놓은 절차를 제공한다.
여러분이 누군가에게 편지를 보낼 때, 대개 여러분은 우편봉투에 국가, 시(군), 우편번호 등 등, 완 벽한 주소를 기입할 것이다. 여러분이 그것을 우편함에 넣으면, 우편업무를 하는 우체부 아 저씨가 그것을 목적 주소로 가져갈 것이다; 그것은 핀지봉투에 명시되어 있는 국가 또는 시(군)으 로 보내 질 것이다. 그러면, 그곳에 있는 우체국에서는 그 편지를 목적지로 보낼 것이다. 계층적 구성은 오히려 분명하다; 여러분이 편지나 소포를 어디에서 부치던간에, 그 지역 우체국장은 그 편지(소 포)가 가야할 곳을 대략 알 것이다. 그러나, 그 편지가 목적주소로 어떻게 가는지는 알 필요 가 없 을 것이다.
IP 네트워크도 이와 유사한 형태로 되어있다. 전체 인터넷은 automonous systems라 고 불리우 는 몇 개의 네트워크로 이루어져 있다. 각 시스템은 내부적으로 각 구성 호스트사이에서 라우팅 을 수행한다. 그래서, 목적 호스트의 네트워크으로 가는 경로를 발견함으로써, 데이터그램을 운반 하는 작업의 양을 줄일 수 있다. 이것은 데이터 그램이 특별한 네트워크에 있는 어떤 호 스트로 옮겨지자 마자, 오로지 네트워크 그 자체에 의해서, 그것을 처리한다는 의미를 담고 있다.
위에서 설명한 것과 같이, IP address를 호스트 부분과 네트워크 부분으로 나눔으로써, 이 구조를 나타낼 수 있다. 목적 네트워크는 IP address의 네트워크 부분에서 유래한 것이다. 그래서, 동일 한 IP 네트워크 번호를 가진 호스트들은 같은 네트워크에서 발견된다. - Autonomous 시스템들 이 조금더 일반적이다. 그것들은 여러개의 IP 네트워크를 포함할 지도 모른다.
그것이 수백개의 더욱더 작은 네트워크 집합과 Ethernet와 같은 물리적인 네트워크로 이루 어 진 가장 작은단위들로 이루어진 후로는, 네트워크에서 inside라고 하는 유사한 스키마 를 제공하는 것도 이치에 맞는 말이다. 그러므로, IP는 하나의 IP 네트워크로 세분화되고, 그것이 여러개의 subnet으로 나누어진다.
IP 네트워크 부분에서 특정 IP address 범위로 데이터 그램을 배달하는 일을 하나의 IP 서 브 넷이 맡고 있다. 클래스 A, B, 또는 C와 같이 그것도 IP address의 네트워크 부분으로 화 인되었 다. 그러나 요즘에는 호스트 부분에 몇 비트를 포함시킴으로써, 네트워크 부분을 확장시킨 다. 서 브넷 번호로 해석되는 비트들의 번호는 subnet mask 또는 netmask에 의해 주 어진다. 이것은 32 비트로 이루어진 숫자들이며, IP address의 네트워크 부분을 위한 비트 마스크를 표시한다.
Figure 2.1: Subnetting a class B network
그러한 네트워크의 한 예로써, Groucho Marx University의 네트워크를 들 수 있다. 그것은
클
래스 B에 해당하는 네트워크 번호 149.76.0.0을 가지며, 그것의 넷 마스트는
255.255.0.0이 된다.
내부적으로 GMU 대학의 네트워크는 여러개의 작은 네트워크로 이루어져 있다. 그래서, IP 주 소의 범위가 254개의 서브넷 즉, 149.76.1.0에서 149.76.254.0으로 분해되었다. 예를 들어, Theoretical Physics 부는 149.76.12.0으로 할당되었다. 그리고 campus backbone은 그자체의 네트워크를 가지며, 149.76.1.0을 할당받았다. 이러한 서브넷들은 같은 IP 네트워크 번호를 공유하고 있다. 반면에 세 번째 옥텟은 그것들 사이에서 구분되어 사용된다. 그리하여 그것들은 255.255.255.0이라는 하나의 서브넷 마스크를 사용할 것이다.
그림 2.1은 quark의 주소인 149.76.12.4가 어떤 식으로 해석되는지를 보여준다. 그 주소가 어떻게 클래스 B 네트워크에 속하게 되는지 또, 어떻게 서브네팅을 사용하는지도 보여준다.
서브네팅 (기술적인 용어로 서브넷을 이렇게도 부른다.)이 오직 네트워크에서 internal division 으로서만 가치있는 것은 아니다. 보통 네트워크 관리자가 이 서브넷을 관리하게 되는데, 대 개 현 존하는 경계를 나타내기 위해 서브넷을 만든다. 그것들은 물리적 (두개의 Ethernet 사이에 서)이고, 관리적 (두 department사이에서) 이며, 또한 지리적이며, 이러한 서브넷들을 능가하는 권한 이 몇 몇 사람들에게 주어진다. 하지만 이 구조는 오직 네트워크의 내부적인 활동에 영향을 미칠 수 있 으며, 바깥 세계에서는 그 모습이 나타나지 않는다.
서브넷팅을 함으로써, 관리상의 이점만을 얻는 것은 아니다. 그것은 자주 하드웨어 한계의 중요성 을 우리에게 인식시켜 주기도 한다. Ethernet와 같이 물리적인 네트워크에 있는 호스트 관 점에서 본다면, 매우 제한되어 있다. 그 제한사항이라는 것은 직접적으로 통신할 수 있는 호스트는 오직 해당 네트워크상에 있어야 한다는 점이다. 다른 모든 호스트들은 gateways라는 것을 통해 서 연결 될 수 있다. 게이트웨이는 두 개이상의 물리적인 네트워크에 동시에 연결되어 있는 하나의 호스 트이다. 그리고 그것은 그것들 사이에서 패킷을 교환하는 작업을 구성해 준다.
만약 호스트가 논리적인 물리 네트워크에 있다면, IP를 쉽게 인식시키기 위해서, 다른 물리 적 네트워크는 또 다른 IP 네트워크에 속해 있어야 한다. 예를 들어, 네트워크 번호 149.76.4.0이 mathematics LAN에 있는 호스트로 예약되어 있는 경우, 그 데이터 그램 을 quark로 보내고자 할 때, erdos상에 있는 네트워크 소프트웨어는 즉시 IP address, 149.76.12.4를 나타내어 준다. 그리고, 그 자료는 게이트웨이 (초기값으로는 sophus로 되어 있다.)를 거쳐서, 목적 호스트에 도착할 것이다.
sophus 그 자체는 두 개의 전혀 다른 서브넷에 연결되어 있다. : Mathematics Department, 그리고 campus backbone. 그것은 eth0와 fddi0라고 하는 각각 다른 인터페이스를 거쳐서 접근한다. 지금 현재, 우리가 할당할 IP address는 무엇일 까? 그리고 서브넷 149.76.1.0 또는 149.76.1.4 중에 어디에 그것을 할당해 주어야 할 까?
답은 둘다이다. Maths LAN에 있는 호스트와 통신을 하고자 할 때, sophus는 IP address 149.76.4.1를 사용해야 하고, 백본에 있는 호스트와 통신을 하고자 할 경우에는 149.76.1.4를 사용해야 한다.
그리하여, 게이트웨이는 네트워크당 하나의 IP address를 할당받는다. 이러한 address들은 각 해당하는 인터페이스와 일치되어 있으며, 게이트웨이를 거쳐서, 서브넷에 연결된다. 다음 표에서 는 sophus에서 일치하는 인터페이스와 어드레스를 보여주고 있다.
마지막에 보이는 개체는 루프백 인터페이스인 lo이다. 이것은 2.2절에서 소개가 되었 다.
그림 2.2는 Groucho Marx University (GMU)에 있는 네트워크 토폴로지의 단면을 보여주고 있다. 두 개의 서브넷에 있는 호스트들은 양쪽으로 물려있는 address를 보여주고 있다.
Figure 2.2: A part of the net topology at Groucho Marx Univ.
일반적으로, 여러분은 호스트나 인터페이스에 어드레스를 추가시키는 방법의 차이점에 대해 서 는 무시해 버려도 상관없다. erdos와 같이 하나의 네트워크에 있는 호스트들을 위해 서, i 엄밀히 말해 여러분은 이곳저곳의 IP address를 가지고 있는 호스트를 조회해 볼 것이다. 하지만, 여러분이 게이트웨이를 참조할 때, 이 차이점이 매우 중요한 작용을 할 수도 있다.
여기서는 데이터 그램을 리모트 네트워크로 넘겨줄 때, 어떻게 IP가 사용할 게이트웨이를 선택하 는지에 초점을 맞출 것이다.
quark로 데이터 그램을 보내줄 때, erdos는 목적 주소를 검사하고, 지역 네트워크 에 그것이 실제로 존재하는지를 확인하였다. 이 작업과 erdos가 디폴트 게이트웨이인 sophus로 자료를 보내는 작업은 같은 맥락이라고 볼 수 있다. sophus는 quark가 어떤 네트워크와도 직접적으로 연결되어 있지 않다는 것을 인식한다. 그래서, sophus 는 다음에 거치게 될 다른 게이트웨이를 찾아내게 될 것이다. 정확하게 선택했다면, 그것은 Physics Department로 가는 게이트웨이인 niels일 것이다. sophus는 적합한 게이트웨이를 가진 목적 네트워크와 교신하기 위한 몇몇 정보를 필요로 하게 된다.
이것을 사용하는 라우팅 정보 IP는 기본적으로 게이트웨이에 연결되어 있는 네트워크 테이 블 을 의미한다. 일반적으로 다목적용 개체를 제공해야 하며, 이것은 네트워크 0.0.0.0과 관련되어 있는 게이트웨이이다. 알려지지 않은 네트워크로 모든 패킷들은 디폴트 라우트를 거쳐서 보내지게 된다. sophus상에서, 이 테이블은 다음과 같이 보일 것이다.
sophus가 직접적으로 연결되어 있는 네트워크에서의 라우트는 게이트웨이를 필요로 하지 않 는다. 이러한 경우의 게이트웨이 개체는 "-"로 표시되어 있다.
라우팅 테이블은 여러 가지 의미로 해석할 수 있다. 규모가 작은 LAN을 위해서는 부트시간 때 에 수동으로 route 명령어를 입력해서 그것들을 IP로 피드백하고, 구성하는 것이 가장 효과 적이 다. (5장을 참조하라). 이것보다 조금 더 큰 네트워크를 위해서는 실행시간에 routing daemons를 조절해 주어야 한다. 이것들은 네트워크의 중앙 호스트에서 실행되며, 네트워크 사이에서 최적의 라우트를 설정해 주기 위해서 라우팅 정보를 교환할 것이다.
네트워크의 규모에 의존하는 또 다른 라우팅 프로토콜을 사용할 것이다. Groucho Marx campus와 같은 자발적인 시스템에서 라우팅을 하기 위해서는 internal routing protocols을 사용 한다. 가장 두드러지게 사용하는 것중 하나가 바로 RIP, Routing Information Protocol 이며, 그것은 BSD routed 데몬에 의해 실행된다. 자발적인 시스템에서 라우팅을 하기 위해서는 EGP (Ext ernal Gateway Protocol) 또는 BGP (Border Gateway Protocol) 과 같은 external routing protocols를 사용해야 한다. RIP 뿐만 아니라 이러한 것들도 Cornell's 대학의 gated 데몬에 의해 실행되고 있다. - 많은 사람들이 routed가 불안정하다고 생 각한다. gated가 RIP를 지원하는 이후로는 routed대신에 gated를 사용하는 편이 더 낫다.
RIP를 기본으로 하고 있는 동적 라우팅은 어떤 목적 호스트나 "hops" 번호에 기초를 두고 있는 네트워크를 위해 최고의 라우트를 선택한다. 그리고 데이터 그램은 도착하기 전에 게이트 웨이를 거쳐야 한다. 단거리 라우트는 RIP보다 전송률이 더 좋다. 16이상의 홉(라우팅 경로에서 차 지하는 하나의 포지션)을 거치는 장거리 라우트는 쓸모 없는 것으로 간주되며, 폐기 처리된다. 다시 말해 서 접속이 안된다는 의미이다.
여러분의 지역 네트워크에 있는 라우팅 정보를 관리하고, RIP를 사용하기 위해서는 모든 호 스 트에 gated를 실행시켜야 한다. 부트시간에 gated는 네트워크 인터페이스에서 일어나는 모 든 활 들을 검사한다. 활동하고 있는 인터페이스가 하나 이상이라면 (여기서 루프백 인터페이스는 계산 하지 않는다.) 호스트가 여러 네트워크 사이에서 패킷들과 라우팅 정보를 활발히 교환하고 제공한 다고 말할 수 있다. 그렇지 않다면, 즉 다시말해 활동하고 있는 인터페이스가 없다면, RIP에 관한 최신 정보를 받거나 지역 라우팅 테이블을 갱신하는 작업이 소극적으로 이루어지고 있다고 말할 수 있다.
지역 라우팅 테이블로부터 정보를 제공할 때, gated는 라우팅 테이블 엔트리와 관련되어 있 는 metric value 로 라우트 길이를 계산한다. 라우트를 구성할 때, 시스템 관리자가 이 미터값 을 계 산하며, 이 라우트를 사용하는 실제 비용을 곰곰히 생각해 보아야 한다. 그러므로 호스트와 직접 적으로 연결되어 있는 서브넷의 미터값은 항상 0이 되어야 한다. 반면에, 두 개의 게이트웨 이를 거치는 하나의 라우트는 미터값이 두자리가 되어야 한다. 하지만, 여러분이 RIP나 gated를 사용 하지 않을 때는 미터값에 대해서 걱정하지 않아도 된다.
IP는 우리가 아직 언급하지 못한 companion protocol을 가지고 있다. 이것은 다름아닌 Internet Control Message Protocol (ICMP) 이며, 다른 호스트와의 메시지 교류시 발생하는 에러를 교환하기 위해 커널 네트워킹 코드를 사용한다. 이를테면, 여러분이 현재 erdos상에 있고, quark에 있는 12345 포트로 원격 접속하고자 하며, 그 포트에서는 어떤 프로세스 listening도 하지 않고 있다고 가정한다. 이 포트를 위한 첫 번째 TCP 패킷이 quark에 도착할 때, TCP의 네트워킹층은 도착한 패킷을 인식할 것이고, 즉시 "Port Unreachable" 상태의 ICMP 메시지를 erdos로 되돌려 줄 것이다.
이해할 수 있는 ICMP 메시지는 수 없이 많으며, 그 중에는 에러 상태를 취급하는 메시지도 있다. 그 중에 Redirect message라 불리우는 매우 흥미로운 메시지가 하나 있다. 비록 더욱더 짧은 경로가 있다하더라도, 그것은 라우팅 모듈에 의해 운영되며, 다른 호스트가 게이트웨이를 통해서 그것을 사용할 때 감지된다. 예를 들어, 부팅한 후에 sophus의 라우팅 테이블이 불완전한 상태가 될 수도 있고, Mathematics 네트워크와 FDDI 백본에 경로가 포함되어 있을 수도 있으며, Groucho Computing Center's gateway (gccl)에 있는 라우트 포인팅이 초기값으로 설정되어 있을 수도 있다. 그래서 quark에 있는 패킷들이 Physics Department에 물려있는 게이트웨이인 niels보다 오히려 gccl로 보내질 것이다. 형편없는 경로 배정으로 어떤 데이터 그램을 전송받을 때, gccl은 그 패킷들을 niels로 다시 전송할것이고, 동시에 최상의 경로 배정을 지시하는 ICMP Redirect 메시지를 sophus로 전송할 것이다.
지금하게될 내용이 가장 기본적인 설정작업을 수동으로 해야하는 번거로움을 피하기 위한 좋 은 방법처럼 보일수도 있지만 RIP나 ICMP Redirect messages가 동적 라우팅 구성에 의 존하고 있다하더라도 이것이 항상 좋은 생각만은 아니다. ICMP Redirect 와 RIP는 몇몇 라우팅 정보가 실제로 믿을 만한 것인지를 검증하기 위한 어떤 선택사항도 제공해 주지 않는다. 이것이 혹 여러 분의 전체 네트워크 트래픽을 분열시키기 위해 고의로 쓸데 없는 작업을 허용하고 있는지도 모른 다. 이러한 이유 때문에, 그것들이 마치 호스트의 경로를 재 발송하는 것처럼, 네트워크 라 우트에 영향을 미치는 Redirect messages들을 치료하기 위한 몇몇 Linux 네트워킹 코드가 있다.
위에서 기술한 대로, TCP/IP 네트워킹에서 어드레싱은 32비트 숫자들로 운영된다. 하지만, 여러 분들은 이 숫자들을 기억하는데 많은 어려움을 느낄 것이다. 그래서, 호스트는 일반적으로 gauss 또는 strange와 같은 정규 이름을 가지고 있다. 이 이름과 일치하는 IP 어드레스를 찾는 것 이 어 플리케이션의 의무이다. 이러한 과정을 host name resolution이라고 부른다.
주어진 호스트명의 IP 어드레스를 찾아야 하는 어플리케이션은 호스트와 IP 어드레스를 찾 기 위해 자체적으로 어떤 체계를 가지고 있진 않다. Instead, it relies on number of library functions that do this transparently, called gethostbyname(3) and gethostbyaddr(3). 전통적으로, 이러한 것들과 그 절차에 연관되어 있는 숫자는 resolver library라고 하는 여러개의 라이브러리로 그룹화되어 있다; 리눅스 상에서 이러한 것들은 표준 libc에 한 부분이다. 일상적으로, 기능들의 모음들을 "the resolver"라고 부른다.
현재 Ethernet과 같은 조그마한 네트워크에서나 심지어 그것들의 클러스터에서도 호스트명 을 어드레스에 대입시키는 테이블을 유지하기란 정말 힘든 작업이다. 이러한 정보들은 대개 파 일명 이 /etc/hosts라고 하는 곳에서 유지되고 있다. 호스트를 추가하거나 삭제할 때, 또는 어드레스들을 반환할 때, 여러분은 모든 호스트에 있는 hosts파일을 갱신해 주어야 한 다. 분명히 이것은 몇대의 컴퓨터로 네트워크를 구성하는 것보다 더 귀찮은 작업일지도 모른다.
Sun Microsystems가 개발한 NIS, Network Information System에서 이러한 문제를 해결하기 위한 하나의 방편으로 YP 즉, 옐로우 페이지라는 것을 내 놓았다. NIS는 마스터 호스트에 있는 데이터 베이스에 hosts 파일과 또 다른 정보들을 저장해 놓는다. 그러면 클라이언트는 필요 한 정 보를 데이터 베이스에서 검색할 수 있다. 이러한 방법은 아직 LAN과 같은 중급 네트워크에 적합 한 방법이다. 왜냐하면, 전체 hosts 데이터 베이스를 유지하고, 그것을 모든 서버에 분배해 주어야 하기 때문이다.
인터넷 상에서, 어드레스 정보는 기본적으로 HOSTS.TXT라고 하는 데이터베이스에 저장되어 있다. 이 파일은 Network Information Center 또는 NIC에 의해 유지되고 있으며, 이 것은 모든 참 여 사이트에 전송되고 설치되어야 한다. 네트워크가 계속해서 성장할 때, 이러한 구성에는 몇가지 문제점들이 발생한다. 게다가 관리상의 문제점으로써, 정규적으로 HOSTS.TXT파일을 설치 해야 하고, 그 파일을 서버에 정기적으로 분배해야 하는 문제점도 포함하고 있다. 심지어 NIC에 등록 되어야 하는 모든 이름에 심각한 문제점들이 발생할 수도 있으며, 이름을 가지고 있지 않은 것이 밖으로 유출되는지를 확인해 보기도 해야 한다.
1984년, 이러한 이유로써, 새로운 이름 해결 방법 즉, Domain Name System이라는 것이 채택 되었다. DNS는 Paul Mockapetris가 개발하였고, 그와 동시에 주소와 관련된 모든 문제들을 해결 했다.
DNS는 도메인과 호스트명을 계층적으로 구성하고 있다. 도메인은 어떤 의미와 연관되어 있는 사이트들의 집합이다. -- 도메인이 적절한 네트워크 형태 (예를 들어 대학에 있는 모든 기 계들, 또는 BITNET에 있는 모든 호스트들)로 되어 있기도 하고, 특정 기구 (미국 정부) 또는 지 리적으 로 묶여 있기도 하다. 이를 테면, 대학들은 edu 도메인으로 그룹화되어 있고, 각 종합대학과 단과대학은 다시 그것들의 호스트를 포함하고 있는 여러개의 subdomain을 사용한다. Groucho Marx University는 groucho.edu 도메인을 부여받았을 것이고, Mathematics Department의 LAN은 maths.groucho.edu를 할당받았을 것이다. 부문 네트워크에 있는 호스트들은 그 자체의 호스트명을 도메인명으로 사용할 것이다; 그래서 erdos가 erdos.maths.groucho.edu로 알려져 있는것인 지도 모른다. 이것을 fully qualified domain name 또는 FQDN이라 부르며, 이것으로 인해 특정 호스트가 전세계에서 유일 무이하게 입증될 수 있다.
Figure 2.3: A part of the domain name space
그림 2.3은 도메인 네임 영역을 보여주고 있다. 이 트리에서 루트에 있는 개체는 하나의 점-도트- (이것을 root domain이라 부른다.) 으로 표시한다. 그리고 다른 모든 도메인을 포 함 하고 있다. 호스트명을 어떤 함축적인 의미를 가진 지역 도메인명을 사용하기 보다 오히려 fully qualified domain name으로 표시하기 위해, 때때로 그것은 trailing dot로 쓰여진다. 이것은 그 이름의 마지막 요소가 루트 도메인이라는 것을 의미한다.
이름 개체에 의존하고 있는 하나의 도메인은 top-level, second-level, 또는 third-level이 라고 부르기도 한다. 그리고 많은 레벨들이 세분화되고 있지만, 그렇게 많은 것은 아니다. 다음에 여러 분이 자주 볼수 있는 top-level에 관해 설명해 놓았다.
(대개 미국에서 사용함) 교육기관, 예 : 대학
영리단체 예 : 회사(company)
비 영리단체. 개인 UUCP 네트워크도 종종 이 도메인을 사용한다.
게이트웨이와 네트워크에서 관리를 목적으로 하는 호스트
미국 국방성 기구
미국 정부 기관
이전에 도메인없이 UUCP 이름만을 사용하던 모든 사이트 명이 공식적으로 이 도 메인을 사용하게 되었다.
인터넷에서는 법적으로 네 개의 도메인 (edu, net, mil, gov)을 미국에서만 사용할 수 있게 하고 있으나 미국에 속해있지 않은 나라에서도 이들 도메인을 사용하는 경우가 있다. 그 중 특수하게, net 도메인을 들수가 있지만, mill과 gov는 오로지 미국에서만 사용할 수 있다.
미국 이외의 나라에서는 일반적으로 ISO-3166에 정의되어 있는 두 개의 문자로 각 나라의 top-level 도메인을 나타낸다. 이를테면, 필란드는 fi 도메인을 사용하고, 프랑스는 fr을, 독일은 de, 그리고 호주는 au를 top-level 도메인으로 사용한다. top-level 도메인 다음에오는 호스트 명은 각나라의 NIC에서 자유롭게 구성할 수 있다. 예를 들어, 호주에서 second-level 도메인을 국제적으로 사용하는 top-level 도메인과 유사하게 즉, com.au 또는 edu.au처럼 사용할 수 있다. 독일과 같은 나라에서는 특별한 도메인을 써서 특정 기구를 직접적으로 언급하기 위해 약간은 긴 이 름을 사용하기도 한다. 예를 들어, ftp.information.unierlangen.de 와 같은 호스트명을 사용하는 것이 보기 드문 것만은 아니다. 독일과 같은 능력있는 나라에서는 보통 사용하는 호스트명과 완전히 다른 것을 사용하기도 한다.
물론, 이러한 국제적인 도메인이 아래에서 설명하게될 호스트를 의미하는 것은 아니다. 그 도 메인은 실제로 그 나라에 위치하고 있다; 오직 그 나라의 호스트는 그 나라의 NIC에서 등 록시키 고 있다. 스웨덴의 회사가 호주에 지사를 둘 경우, 그 지사에 있는 모든 호스트들은 그들의 top-level 도메인을 se 로 등록시킨다.
현재, 네임 영역에 있는 도메임 네임을 계층적으로 구성하게 되면, 그 이름들이 중복되는 문 제를 말끔히 해결할 수 있다. ; DNS와 호스트의 이름은 전세계에서 오직 하나이어야 한다. 게다 가, fully qualified name들은 기억하기 쉬워야 한다. 그리고 이미 거대한 하나의 도메인을 여 러 서브 도메인으로 나누기 위한 좋은 방법들이 나와있다.
그리고 DNS는 심지어 관리자를 거쳐서 해야하는 작업 즉, 서브도메인을 만들 수 있는 권한 을 여러분에게 위임해주는 것보다 더 한 것을 허가해 주기도 한다. 예를 들어, Groucho Computing Center에 있는 유지자(maintainer)가 각 부(department)를 위한 서브 도메인을 만들 수도 있다. 이미 위에서 maths와 physics라는 서브도메인을 보았다. 만약 Physics Department에 있는 네트 워크가 엉망진창인 상태로 발견이 된다면, 이 네트워크 관리자에게 physics.groucho.edu 도 메인 을 관리하게끔 할지도 모른다. 어쩌면 이 사람들은 그들이 좋아하는 호스트명을 사용할 수 도 있 고, 유행에 따라 네트워크를 관리할 수도 있으며, 외부 간섭을 전혀받지 않은 상태에서 IP 주소를 할당할 수도 있다.
이런식으로 일어날 수 있는 현상들 때문에, 네임 영역은 zone으로 나누어지게 되며, 각 네임 영 역은 하나의 도메인으로 뿌리를 내리게 된 것이다. 여기서 zone과 domain사이에는 아주 민감한 차이가 있다는 것을 주의하라; domain groucho.edu는 Groucho Marx University에 있는 모든 호스트를 둘러싸고 있는 반면에 zone groucho.edu는 Computing Center가 직접적으로 관리 하는 호스트 예를 들어 수학부 (Mathematics Department)만을 포함하고 있다. Physics Department에 있는 호스트들은 다른 zone 즉, physics.groucho.edu에 속해 있다. 그림 2.3에서, 하나의 zone의 시작이 작은 원으로 표시되어 있고, 그 원의 왼쪽에는 도메인이 있다.
잠깐 보아서 이러한 모든 도메인과 존(zone)은 대단히 복잡한 작업에 대한 하나의 해결방 안처럼 보인다. 결국, 호스트명을 할당할 수 있는 중심 권한이 없다면, 보잘 것 없는 어플리케이션 이라도 어떻게 안다고 가정할 수 있겠는가?
여기 DNS에 관해 정말 소박하게 답변해 놓은 것이 있다. 만약 여러분이 erdos의 IP 주소 를 찾고 싶다면, DNS는 그것을 관리하고 있는 사람에게 물어보라고 말할 것이다. 그러면 그 관리자 가 여러분이 알고 싶어 하는 정보를 알려줄 것이다.
사실, DNS는 거대하게 분포되어 있는 데이터베이스이다. 이것은 네임 서버의 의미로써 수 행 되는데 주어진 도메인과 도메인 집합에 관한 정보를 제공한다. 각 존(zone)을 위해서, 적어 도 두 개의 네임 서버가 있으며, 그 네임 서버는 그 존(zone)에 있는 호스트에 관한 모든 정보를 가지고 있다. erdos의 IP 주소를 구하기 위해서는, groucho.edu zone을 위한 네임 서버에 접속해 서, 바 라는 정보를 얻어야 한다.
여러분이 생각하는 것보다 어쩌면 더 쉬울 지도 모른다. 내가 Groucho Marx University에 있 는 네임 서버에 어떻게 도달할 수 있는가? 또, 여러분의 컴퓨터가 address-resolving oracle 도 갖 추어 놓지 않은 경우에도 DNS는 또한 그러한 것을 제공해 준다. 여러분의 어플리케이션이 erdos 에 관한 정보를 찾아내고자 할 경우, 로컬 네임서버에 접속해서, 이른바 interative query를 수행 한다. 여러분의 로컬 네임서버는 루트 도메인을 위한 네임서버에게 질의를 보냄으로써 작업 을 시 작하게 된다. 그리고 그것은 네임서버에게 erdos.maths.groucho.edu의 주소를 요청한다. 루트 네임서버는 이 이름이 루트권한에 속하지 않는다는 것을 인식하게 되며, 오히려 edu 도메인 에 그 러한 권한이 있다고 판단한다. 그래서, 루트 네임서버는 더 자세한 정보를 알고 싶다면, edu zone 네임서버로 접속하라고 말해줄 것이며, 그들의 주소와 함께 모든 edu 네임서버 목록을 폐쇄 한다. 그러면, 여러분의 로컬 네임 서버는 edu 네임 서버중의 하나, 이를테면 a.isi.edu에게 질의 를 보 내게된다. 루트 네임 서버와 유사한 방법으로써, a.isi.edu는 groucho.edu가 있는 지역을 알 아차 리고, 여러분에게 그 서버가 있는 위치를 가르쳐 준다. 그러면 로컬 네임 서버는 erdos에게 질의 를 보내게 되며, 마지막으로 그것은 그 주소가 있는 지역을 알아차리게 되고, 일치하는 IP 주소를 그 어플리케이션으로 보내게 된다.
지금까지 설명한 것에서 보면, 단순하게 IP 주소를 찾는데에 엄청나게 많은 트래픽이 걸리 는 것처럼 보인다. 하지만 HOSTS.TXT에서 보게될 엄청나게 많은 양의 문서를 읽는 것보다는 간단 한 작업이다. 그러나 이러한 과정속에서도 개선되어야 할 많은 문제점들이 있다.
미래에는 질의를 하는동안 그 응답시간을 줄이기 위해, 네임서버는 로컬 cache에다가 구한 정 보를 저장할 것이다. 그래서 다음에 여러분의 로컬 네트워크에서 누구나가 groucho.edu에 있는 호스트의 주소를 찾고자 할 경우, 여러분의 네임서버는 전체 과정을 또 다시 거치지 않고 직접적 으로 groucho.edu에 접속하게 될 것이다. - 만약 그렇지 않다면, DNS가 다른 것과 같이 안좋은 방법일지도 모른다. 왜냐하면, 각 질의가 루트 네임 서버를 필요로 하기 때문이다.
물론, 네임서버가 영원히 이 정보를 간직하고 있지는 않을 것이다. 오히려 약간의 기간이 지 나 면, 그것을 폐기 처분할 것이다. 이러한 만료시간을 time to live 또는 TTL이라고 부 른다. 한 지 역을 책임지는 관리자가 DNS 데이터 베이스에 있는 각 자료에 이 TTL을 할당한다.
네임서버들은 authoritative로 불리는 지역안에 있는 호스트에 관한 정보를 가지고 있다. 그 래서, 때때로 그것은 master name servers라고 하기도 한다. 이 지역에 있는 호스트에게 보내는 어떠 한 질의조차도 마지막에는 이러한 마스터 네임 서버에서 끝나게 된다.
한 지역의 간섭화면을 제공하기 위해서는 그것의 마스터 서버가 더 잘 표시해 줄 것이다. 데 이터 파일로부터 얻은 정보를 그 지역에 적재시키는 마스터 서버중에 하나인 primary 서버 를 만 들고, 규칙적인 간격으로 primary 서버에서 자료를 그 지엑에 전송해 주는 또 다른 secondary 서 버들을 만들어 줌으로써 이러한 작업을 이루어 낼 수 있다.
여러 네임서버를 가지는 이유중에 하나로는 적재 작업을 분산시키기 위해서이고, 또 다른 이 유로는 과다한 작업양을 여러 네임서버에 분배하기 위해서이다. 하나의 네임 서버 머신이 충돌이 나 손실과 같은 현상으로 인해 네트워크 연결에 실패했다면, 다른 서버로 모든 질의를 요청 할 것 이다. 물론, 이러한 구성이 여러분을 서버고장 (모든 DNS 요청에 대해 잘못된 결과를 산출 해내는 경우, 예를 들어 서버 프로그램으로 인해 소프트웨어 버그가 발생되는 경우)으로부터 보호 해 주지 는 못한다.
물론 여러분은 또한 실행하고 있는 네임 서버에서 제공되는 어떤 도메인도 믿지 못할 것 이 다. - 어쩌면 거의 그럴지도 모른다. 적어도 네임서버는 localhost를 위한 네임 서비스 와 127.0.0.1에 해당하는 룩업을 예약해 주어야 한다. 그럼에도 불구하고 이러한 서버 형태가 유용한 경우도 있다. 이것은 여전히 로컬 네트워크 에서 실행하고 있는 어플리케이션을 위한 DNS 질의들을 처리하고 그 정보를 저장할 수 있 다. 이 러한 형태를 caching-only 서버라고 부른다.
우리는 위에서 DNS가 호스트의 IP 주소를 처리하는 것 뿐만 아니라 네임서버에서 정보를 교환하는 일도 한다는 것을 알았다. 사실 DNS 데이터베이스는 많은 다른 형태의 엔트리를 가지고 있 다.
DNS 데이터 베이스에 있는 하나의 정보 조각들을 resource record 줄여서 RR이라고 부른다. 각 레코드는 그것과 관련되어 있는 형태를 가지고 있고, 그것을 표현하는 데이터층을 기술 해 주 고 있으며, 하나의 클래스는 그것을 사용하는 네트워크 형태를 명시해 주고 있다. 후자는 IP 주소 들 (the IN class) 또는 MIT에서 사용되는 Hesiod 네트워크의 주소와 같은 또 다른 어드레 싱 방 법의 필요를 수용시키고 있다. 기본적인 resource record 형태는 하나의 IP 주소와 함께 하나의 fully qualified domain name과 관련되어 있는 하나의 레코드를 말한다.
물론, 호스트가 여러개의 이름을 가질 수도 있다. 하지만 이러한 이름들중 하나는 꼭 공식적 으 로 확인될 수 있는 canonical host name 이어야 한다. 반면에 다른 이름들은 단순히 전자에 서 언 급하고 있는 가명들이다. 이 두가지 형태에서 차이점을 말한다면, canonical 호스트명은 관 련되어 있는 레코드가 오직 하나밖에 없지만, 다른 호스트명은 canonical 호스트명을 가리키고 있는 CN- AME형태의 레코드를 가지고 있다.
우리가 여기서 모든 형태의 레코드를 다룰 수는 없지만, 다음장에서 몇 개를 설명해 놓았으 며, 여기 믿을 만한 예제를 들어 놓았다. 그림 2.4는 physics.groucho.edu 지역(zone)을 위한 네 임서 버로 적재되는 도메인 데이터베이스의 한 부분을 보여주고 있다.
Figure 2.4: An excerpt from the named.hosts file for the Physics Department
A와 CNAME은 일단 제쳐놓고, 여러분은 파일의 제일 윗 부분에서 특별한 레코드를 볼수 있 다. 이것은 SOA (Start of Authority) 리소스 레코드이다. 이것은 그 지역에 있는 일반적인 정보 를 가지고 있다. 이를 테면, 이것은 모든 레코드를 위한 time-to-live의 초기값을 포함하고 있다.
예제 파일에서 도트(.)로 끝나지 않는 모든 이름은 groucho.edu 도메인과 연관되어 해석된 다 는 것을 명심하라. SOA 리소스에서 사용되는 특별한 이름인 "@"은 그 자체의 도메인 네임 을 나 타낸다.
우리는 위에서 groucho.edu 도메인을 위한 네임서버들이 어쨋든 간에 physics 지역(zone) 에 관한 정보를 알고 있고, 그래서 그들의 네임서버로 질의를 요청할 수 있는 것을 보아왔다. 이것은 대개 한쌍의 레코드에 의해 수행된다 ; NS 레코드는 서버의 FQDN을 가지고 있고, 하나의 레코 드는 그 이름과 관련되어 있는 주소를 가지고 있다. 이러한 레코드가 네임 영역에 함께 저 장되는 이래로, 그것들을 자주 glue records라고 부르기도 한다. 이것들은 부 지역(parent zone)이 실제로 종속 지역에 있는 호스트에 관한 정보를 가지고 있는 레코드들의 대표적인 예이다. glue 레코드 는 그림 2.5에서 보는 것과 같이 physics.groucho.edu를 위한 네임서버를 가리키고 있다.
Figure 2.5: An excerpt fro the named.hosts file for GMU.
호스트에 속해 있는 IP-주소를 찾는 것 이외에도 주소에 해당하는 찾는 것이 때때로 더 바람하다. 이것을 reverse mapping라 부르고 신분을 검증하기 위
해서 여러 네트워크 서비스에 의해 사용된다. 단독 hosts 파일을 사용할 때, reverse lookups는 단순히 그 질 의에 해당하는 IP 주소를 가지는 호스트를 위한 파일을 찾아준다. DNS를 가지고 네임 영역 을 철 저하게 찾는 작업은 물론 질의와는 상관없는 작업이다. 대신에, 지금까지 만들어 지고 있는 특별 한 도메인인 in-addr.arpa은 dotted-quad 표기법으로 모든 호스트의 IP 주소를 포함하고 있다. 이를 테면, 149.76.12.4라는 IP 주소는 4.12.76.149.in-addr.arpa라는 이름과 일치한다. 이러한 이름들을 그것들의 canonical 호스트명과 연결시킨 리소스 레코드를 PTR이라고 부른다.
어떤 권한을 가지는 지역을 만들어 내는 것은 대개 그 지역을 관리하는 사람이 IP 주소를 호 스트명에 할당하는 모든 작업을 완전하게 통제할 수 있다는 것을 의미한다. 그들은 대개 수동으 로 설정할 수 있는 하나이상의 IP 네트워크와 서브넷을 가진 이래로, DNS 지역(zone)과 IP 네트 워크를 1 대 ? (one-to-many)로 매핑하는 경향이 있다. 이를테면, 물리부(Physics Department)는 서브넷 149.76.8.0, 149.76.12.0 그리고 149.76.14.0를 포함하고 있다.
그 결과, in-addr.arpa 도메인에 있는 새로운 지역은 physics 지역에 따라 만들어 져야 하고, 그 부(department)에 있는 네트워크 관리자에게 권한을 위임받아야 한다; 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa 그리고, 14.76.149.in-addr.arpa. 그렇지 않고, Collider Lab에 다가 새로운 호스트를 설치하는 경우, 그들의 in-addr.arpa 지 역 (zone) 파일에 입력되어 있는 새로운 주소를 가지기 위해서 그들의 부(parent) 도메인에 접속할 필요가 있을 것이다.
서브넷 12를 위한 지역(zone) 데이터베이스가 그림 2.6에 나타나 있다. 그들의 부 지역 (parent zone)의 데이터 베이스와 일치하는 glue 레코드들은 그림 2.7에 나타나 있다.
Figure 2.6: An excerpt from the named.rev file for subnet 12
Figure 2.7: An excerpt from the named.rev file for network 149.76.
이것들중 가장 중요한 결과를 들자면, 지역(zone)은 단지 IP 네트워크의 superset으로 만들 어 질 수 있고, 이러한 네트워크의 넷마스크는 바이트를 경계로 해야 한다. Groucho Marx 대학에 있는 모든 서브넷들은 255.255.255.0인 넷마스크를 가지며, 어쨋든 in-addr.arpa 지역은 각 서브넷을 위해 만들어 질 수 있었다. 그러나, 대신에 넷마스크를 255.255.255.128 로 준다면, 서브넷 149.76.12.128을 위한 지역을 절대 만들어 질 수 없다. 왜냐하면, 12.76.149.in-addr.arpa 도메인이 권한을 가지는 두 개의 지역 (각각 호스트명이 하나는 1에서 127까지, 또 하나는 128에서 255까지의 지역)으로 나누어져 있다고 DNS에게 말할 수 있는 방법이 없기 때문이다.