DNS는 도메인 이름 시스템을 나타냅니다. DNS는 TCP/IP 네트워크에서 이름 해상도에 사용됩니다. DNS가 무엇인지, 어디에서 왔는지 이해하기 전에 DNS가 개발되기 전에 이름 해상도가 어떻게 발생했는지 먼저 이해해야합니다.
인터넷이 방금 시작되었고 수백 개의 컴퓨터 만 연결되었을 때 이름 해상도는 매우 간단하고 유지 관리가 쉬웠습니다. 원래 TCP/IP 사양은 HOSTS
라는 특수 텍스트 파일을 사용하여 이름 해상도를 구현했습니다. 이 파일의 사본은 인터넷의 모든 컴퓨터 시스템에 저장되었습니다.
HOSTS
파일에는 해당 시스템 이름에 매핑 된 인터넷의 모든 컴퓨터에 대한 IP 주소 목록이 포함되어 있습니다. 중앙 HOSTS
파일이 매일 업데이트되고 배포되었습니다. 이것은 인터넷에 연결된 수천 개의 시스템이있을 때까지 상당히 잘 작동했습니다. TCP/IP 시스템에는 여전히 컴퓨터에 HOSTS
파일이 있지만 HOSTS
파일은 더 이상 이름 해상도의 기본 소스가 아닙니다.
원래 이름 해상도를위한 중앙 슈퍼 컴퓨터를 갖는 개념은 고려되었지만이 솔루션은 한계에 도달하여 실용적이지 않았습니다. 이름 해결 프로세스를 위임한다는 아이디어는 제한 프로세스의 우려를 완화시킬 것입니다. DNS 계층 구조는 태어 났으며 오늘날까지도 여전히 성장하고 크기가 커지고 있습니다.
root
도메인은 전 세계 13 개의 DNS 시스템으로 구성되며, DNS 루트 서버로 공동으로 알려져 있습니다. 이러한 시스템을 나타내는 13 개의 IP 주소가 있지만 실제로 13 개 이상의 서버가 있습니다.
일부 IP 주소는 실제로로드 균형 가상 IP이므로 일부 IP 주소를 공유하는 두 개 이상의 DNS 서버가있을 수 있습니다. 호스트 이름의 13 개의 루트 서버 목록은 다음과 같습니다.
DNS 서버 | IP 주소 |
---|---|
a.root-servers.net |
198.41.0.4 |
b.root-servers.net |
192.228.79.201 |
c.root-servers.net |
192.33.4.12 |
d.root-servers.net |
128.8.10.90 |
e.root-servers.net |
192.203.230.10 |
f.root-servers.net |
192.5.5.241 |
g.root-servers.net |
192.112.36.4 |
h.root-servers.net |
128.63.2.53 |
i.root-servers.net |
192.36.148.17 |
j.root-servers.net |
192.58.128.30 |
k.root-servers.net |
193.0.14.129 |
l.root-servers.net |
199.7.83.42 |
m.root-servers.net |
202.12.27.33 |
DNS 루트 서버는 계층 구조를 설정하지만 대부분의 이름 해상도 프로세스는 다른 DNS 서버에 위임됩니다. 계층 구조의 DNS 루트 바로 아래 에는 최상위 도메인 서버가 있습니다. 이 최상위 DNS 서버는 com
, net
, org
, edu
, gov
, mil
등과 같은 최상위 도메인을 처리합니다.
최상위 DNS 서버는 수천 개의 2 단계 DNS 서버를 위임합니다. 2 단계 도메인 이름은 회사 및 기타 조직에 판매됩니다. 이 구조의 두 번째 수준은 수백만 개의 도메인 이름으로 구성됩니다. 두 번째 수준의 DNS 서버는 영역을 추가로 위임 할 수 있지만 가장 일반적으로 가장 일반적인 호스트 레코드는 가장 일반적인 호스트 레코드 www
와 같은 도메인 이름에 저장합니다.
예를 들어, corp.com
도메인에는 IP 주소가 192.168.0.1 인 www
라는 DNS 별칭이있는 서버가 있습니다. corp.com
도메인을 제어하는 DNS 서버 만 호스트 레코드 www.corp.com
의 실제 IP 주소를 저장합니다. corp.com
영역을 저장하지 않는 다른 DNS 시스템에는이 정보가 없습니다.
DNS 시스템은이 영역을 호스팅하는 DNS 서버에 도달 할 때까지 Resolver (DNS 요청을 작성하는 클라이언트)에 추천을 제공합니다. 이 영역을 호스팅하는 DNS 서버가 Resolver로부터 쿼리를 수신하면 쿼리에 대한 답변으로 Resolver를 보냅니다.
DNS 네임 스페이스
DNS 네임 스페이스는 컴퓨터 파일 시스템의 작동 방식과 유사한 방식으로 작동합니다. DNS 네임 스페이스는 DNS 도메인의 계층 구조이며 트리와 같은 구조로 구성된 개별 호스트 이름입니다.
각 도메인은 폴더와 유사합니다. 일반적인 폴더 구조와 마찬가지로 폴더에는 폴더 나 문서가 포함될 수 있습니다. DNS에서 도메인에는 다른 도메인 또는 레코드가 포함될 수 있습니다.
자원 기록
2 단계 DNS 서버에서 일반적으로 리소스 레코드를 찾습니다. 리소스 레코드 레코드 맵 서비스 및 호스트 이름을 IP 주소로 표시합니다. 예를 들어, 가장 일반적인 리소스 레코드는 호스트 (a) 레코드입니다. 호스트 이름은 단순히 이름을 IP 주소에 맵핑합니다. 가장 일반적인 호스트 이름은 www
레코드입니다. 경우에 따라 다른 호스트 레코드를 가리키기 위해 별칭 ( CNAME
) 레코드를 사용하는 것이 바람직합니다.
예를 들어 서버에 서버와 관련된 여러 이름이있는 경우 Server1이라는 호스트 (a) 레코드를 작성하고 컴퓨터의 IP 주소에 매핑 할 수 있습니다. 그런 다음 www
, ftp
, mail
과 같은 여러 별칭 ( CNAME
) 레코드를 동일한 호스트 이름에 다시 작성하십시오. 다음은 영역 내에서 사용되는 가장 일반적인 DNS 레코드 목록입니다.
설명 | 유형 | 목적 |
---|---|---|
표준 이름 | CNAME |
호스트 이름에 별명 |
주최자 | A |
호스트 이름을 IP 주소로지도합니다 |
이름 서버 | NS |
지도 이름 서버 이름을 IP 주소로지도합니다 |
우편 교환기 | MX |
Mail Exchange Server DNS 이름을지도합니다 |
권위의 시작 | SOA |
영역 구성 |
이름 해결 프로세스
DNS가 처음 설계된 이후 이름 해상도 프로세스는 크게 변경되지 않았습니다. DNS Resolver (DNS Client)가 리소스에 액세스하려면 호스트 이름을 해결 해야하는 경우 먼저 DNS 서버에 연락해야합니다.
IT 연락처 DNS 서버는 클라이언트 TCP/IP 구성에 따라 다릅니다. DNS 클라이언트 구성이 DHCP 구성에 포함되거나 클라이언트 설정에서 수동으로 구성되어야합니다.
개인 네트워크 내의 컴퓨터의 경우 내부 DNS 서버를 가리 키도록 구성하는 것이 좋습니다. 인터넷의 시스템의 경우 ISP의 DNS 서버 또는 Google의 공개 서버 ( 8.8.4.4
및/또는 8.8.8.8
)와 같은 인터넷의 많은 공개 DNS 서버 중 하나를 가리 키도록 구성 할 수 있습니다.
위에 표시된 그래픽에서 이름 해상도 프로세스는 DNS 클라이언트에서 호스트 이름을 해결하기 위해 취해야하는 8 단계를 나타냅니다. 이 그래픽을 사용하여 일반적인 예를 자세히 설명 할 수 있습니다.
다음 예에서는 DNS 클라이언트가 인터넷에서 웹 서버에 액세스하려고합니다. 클라이언트가 웹 서버와 통신하기 전에 웹 서버의 호스트 이름을 IP 주소로 해결해야합니다.
- 1 단계 : DNS Client Queries ISP DNS Server를 쿼리하여 호스트 이름
www.domain.com
을 해결합니다. - 2 단계 : ISP 웹 서버는 DNS 캐시 및 로컬 영역을 확인합니다. 일치하지 않으면 DNS 서버가 루트 DNS 서버를 쿼리합니다.
- 3 단계 : 루트 DNS 서버는 요청을
.COM
DNS 서버로 전송할 수 있도록 추천을 통해 ISP DNS 서버로 다시 응답합니다. - 4 단계 : ISP DNS 서버는 쿼리를
.COM
DNS 서버로 보냅니다. - 5 단계 :
.COM
DNS 서버는 요청을DOMAIN.COM
DNS 서버로 전송할 수 있도록 추천을 통해 ISP DNS 서버로 다시 응답합니다. - 6 단계 : ISP DNS 서버는 쿼리를
DOMAIN.COM
DNS 서버로 보냅니다. - 7 단계 :
DOMAIN.COM
DNS 서버는www.domain.com
의 쿼리에 대한 답변으로 ISP DNS 서버에 다시 응답합니다. - 8 단계 : ISP DNS 서버는 답을 캐시하고 답변을 리졸버로 다시 보냅니다.
Resolver (DNS Client)에 웹 서버의 IP 주소가 있기 때문에 Resolver는 이제 웹 서버와 직접 통신을 시작할 수 있습니다. 또한 DNS 서버는이 프로세스 동안받은 정보를 캐시 합니다.
따라서 미래의 요청이 캐시 된 레코드의 TTL (To-Live) 기간 내에있는 한이 호스트 이름에 대한 향후 요청은 전체 프로세스를 처음부터 끝까지 수행하지 않고 캐시에서 해결할 수 있습니다.