기본 재귀 캐싱 DNS 서버 설정 및 도메인 영역 구성

우리가 매일 사용하는 모든 웹사이트의 IP 주소를 기억해야 한다면 어떨지 상상해 보세요. 우리가 엄청난 기억력을 가지고 있다 하더라도 웹사이트를 탐색하는 과정은 터무니없이 느리고 시간이 많이 걸립니다.

그리고 여러 웹사이트를 방문해야 하거나 동일한 시스템이나 가상 호스트에 있는 여러 애플리케이션을 사용해야 한다면 어떨까요? 이는 제가 생각할 수 있는 최악의 골칫거리 중 하나입니다. 웹사이트나 애플리케이션과 관련된 IP 주소가 사전 통지 없이 변경될 수 있다는 가능성은 말할 것도 없습니다.

생각만으로도 잠시 후 인터넷이나 내부 네트워크 사용을 중단할 충분한 이유가 될 것입니다.

이것이 바로 도메인 이름 시스템(DNS라고도 함)이 없는 세상이 될 것입니다. 다행스럽게도 이 서비스는 IP 주소와 이름 간의 관계가 변경되더라도 위에서 언급한 모든 문제를 해결합니다.

이러한 이유로 이 기사에서는 도메인 이름을 IP 주소로 또는 그 반대로 변환할 수 있는 서비스인 간단한 DNS 서버를 구성하고 사용하는 방법을 알아봅니다.

DNS 이름 확인 소개

자주 변경되지 않는 소규모 네트워크의 경우 /etc/hosts 파일을 도메인 이름과 IP 주소 확인의 기본적인 방법으로 사용할 수 있습니다.

매우 간단한 구문을 사용하여 이 파일을 사용하면 다음과 같이 이름(및/또는 별칭)을 IP 주소와 연결할 수 있습니다.

[IP address] [name] [alias(es)]

예를 들어,

192.168.0.1 gateway gateway.mydomain.com
192.168.0.2 web web.mydomain.com

따라서 이름, web.mydomain.com 별칭 또는 IP 주소를 통해 웹 시스템에 연결할 수 있습니다.

대규모 네트워크나 자주 변경되는 네트워크의 경우 /etc/hosts 파일을 사용하여 도메인 이름을 IP 주소로 확인하는 것은 허용되는 솔루션이 아닙니다. 바로 여기서 전용 서비스가 필요합니다.

내부적으로 DNS 서버는 루트 (“. ”) 영역에서 시작하는 트리 형태의 대규모 데이터베이스를 쿼리합니다.

다음 이미지는 설명하는 데 도움이 됩니다.

위 이미지에서 루트 (.) 영역에는 com, edu 및 net 도메인이 포함되어 있습니다. 이러한 각 도메인은 대규모 중앙 조직에 의존하지 않기 위해 여러 조직에서 관리하거나 관리할 수 있습니다. 이를 통해 요청을 계층적 방식으로 적절하게 배포할 수 있습니다.

내부적으로 무슨 일이 일어나는지 살펴보겠습니다.

1. 클라이언트가 web1.sales.me.com에 대한 DNS 서버에 쿼리를 보내면 서버는 해당 쿼리를 최상위(루트) DNS 서버로 보냅니다. .com 영역에 있는 이름 서버에 대한 쿼리를 가리킵니다.

그러면 쿼리가 다음 레벨 이름 서버(me.com 영역)로 전송된 다음 sales.me.com으로 전송됩니다. 이 프로세스는 FQDN(이 예에서는 정규화된 도메인 이름, web1.sales.me.com)이 나올 때까지 필요한 만큼 반복됩니다. 그것이 속한 영역의 이름 서버에 의해 반환됩니다.

2. 이 예에서 sales.me.com.의 이름 서버는 web1.sales.me.com 주소에 응답하고 반환합니다. 원하는 도메인 이름-IP 연결 및 기타 정보(그렇게 구성한 경우)

이 모든 정보는 원래 DNS 서버로 전송된 다음 처음에 이를 요청한 클라이언트에게 다시 전달됩니다. 향후 동일한 쿼리에 대해 동일한 단계를 반복하지 않도록 쿼리 결과는 DNS 서버에 저장됩니다.

이러한 종류의 설정이 일반적으로 재귀적 캐싱 DNS 서버로 알려진 이유는 다음과 같습니다.