우리 회사는 자체 공용 DNS를 배포하고 유지하기를 기대하고 있습니다. 배포 활동의 개요를 설명하고 있지만 회사 도메인 이름을 등록할 위치와 공용 DNS를 매핑하는 방법은 거의 혼동되지 않습니다. 교통 흐름에 대해 설명해 주세요.
답변1
저는 도메인 레지스트리에서 일했고 IETF DNS 작업 그룹의 일원이었으므로 입문서를 알려드리겠습니다.
도메인 이름 시스템은 계층 구조로 설계되었습니다. 도메인 이름에 대한 데이터를 조회할 때 일반적으로 맨 위로 이동하여 아래로 이동합니다.
맨 위에는 루트가 있습니다. 루트 이름 서버는 모든 질문이 항상 시작되는 전 세계에 퍼져 있는 여러 서버입니다. 데이터가 캐시되지 않는 한 이에 대해서는 나중에 설명하겠습니다. 일반 사용자는 도메인 이름에서 이를 볼 수 없지만 거기에 있습니다.
다음은 최상위 도메인입니다. 이는 일반 최상위 도메인(예: .com, .net 또는 .movie)과 국가 코드 최상위 도메인(예: 미국의 경우 .us, 노르웨이의 경우 .no, 중국의 경우 .cn)으로 구분됩니다.
그 다음에는 두 번째 수준 도메인이 있습니다. 이는 일반적으로 최종 고객으로 구매하는 제품입니다. 예를 들어, example.com을 소유하고 싶다면 등록 기관으로 이동하여 example.com을 사용할 수 있는지 확인하고, 사용 가능한 경우 장바구니에 추가하고 결제를 누르세요. 그런 다음 등록 대행자나 다른 호스팅 회사가 귀하의 DNS를 실행하도록 하거나, 귀하가 자체 DNS 서버를 설정하고 등록 대행자가 귀하에게 도메인을 위임하도록 할 수 있습니다. 위임이란 귀하의 DNS 서버가 이 도메인을 담당한다는 데이터를 등록한다는 의미입니다.
도메인을 소유한 후에는 3차 도메인 또는 하위 도메인을 설정할 수도 있습니다. 이렇게 하면 DNS 서버에 또 다른 계층 구조가 추가됩니다. 일반 사용자에게 정확히 똑같은 호스트 이름을 설정할 수도 있습니다.
그럼, 평균적인 DNS 조회를 살펴보겠습니다.
당신이 가고 싶다고 가정 해 봅시다www.example.com. DNS 서버가 가장 먼저 할 일은 루트 서버로 이동하여 .com을 담당하는 사람을 찾는 것입니다. DNS 서버에는 이미 루트 서버의 주소가 내장되어 있으므로 일반적으로 해당 주소를 조회할 필요가 없습니다. 대신 .com에 대한 정보를 찾습니다.
여기서는 "dig" 프로그램을 사용하겠습니다. 하지만 가독성을 위해 출력을 높이 평가하겠습니다.
먼저 com에 대한 이름 서버(ns)를 요청합니다. 우리는 DNS 시스템의 루트 서버 중 하나인 a.root-servers.net 서버에서 직접 이를 요청합니다.
$ dig ns com. @a.root-servers.net.
출력은 다음과 같습니다(다시 축약됨).
;; QUESTION SECTION:
;com. IN NS
;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
QUESTION SECTION은 우리가 요구하는 내용을 보여줍니다. 이 경우 com에 대한 NS 레코드입니다.
AUTHORITY 섹션은 루트 서버가 .com에 대한 책임이 없음을 보여주지만, 누가 .com인지 알려줍니다. 이 경우 a.gtld-servers.net이 책임이 있음을 알려줍니다.
또한 a.gtld-servers.net에 대한 주소 레코드(IPv4의 경우 A, IPv6의 경우 AAAA)가 포함된 추가 섹션도 제공합니다. 이 주소는 글루(glue)라고 불리며 신뢰할 수 있는 답변으로 간주되지는 않지만 이것이 시스템에 나열된 주소임을 알려주는 힌트입니다. 글루 레코드는 DNS 조회를 통해서만 접근할 수 있는 서버의 IP 주소가 필요할 때 필요하며, 이를 위해서는 네임서버의 IP 주소가 필요합니다. 그것은 모두 약간 재귀적입니다.
어쨌든, 계속해서 example.com의 네임서버를 찾아보겠습니다. 이제 실제 DNS에서 말하는 내용과 약간 다르지만 이는 예시이므로 예시 데이터를 사용하겠습니다.
$ dig ns example.com. @192.5.6.30
우리는 위에서 얻은 a.gtld-servers.net의 IP 주소를 묻고 있습니다. 이는 .com 도메인에 대한 권한이 있으므로 example.com의 네임서버가 무엇인지 알려줄 수 있어야 합니다.
;; QUESTION SECTION:
;example.com. IN NS
;; AUTHORITY SECTION:
example.com. 172800 IN NS ns2.example.com.
example.com. 172800 IN NS ns1.example.com.
;; ADDITIONAL SECTION:
ns2.example.com. 172800 IN A 192.0.2.4
ns1.example.com. 172800 IN A 192.0.2.5
이제 접착제가 중요한 이유가 여기에 있습니다. example.com의 네임서버는 example.com 아래에 있으므로 example.com 아래의 네임서버에서 관리됩니다. 본질적으로, Bob만이 Bob의 전화번호가 무엇인지 알고 있기 때문에 Bob에게 전화하여 Bob의 전화번호를 확인하라는 지시를 받습니다. 접착제는 힌트입니다. Bob이 번호를 변경했을 수도 있지만 이는 .com의 네임서버가 알고 있는 정보입니다.
이제 example.com 네임서버의 주소를 알았으므로 마침내 호스트 이름을 물어볼 수 있습니다.
$ dig a www.example.com. @192.0.2.4
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 300 IN A 192.0.2.10
드디어 주소록이 나왔습니다www.example.com호스트 이름. 이 쿼리에는 ADDITIONAL SECTION이 필요하지 않기 때문에 여기에 ADDITIONAL SECTION이 없다는 점에 유의하세요. 우리는 간단한 질문을 하고 해당 도메인에 대해 권한이 있는 서버로부터 정확한 답변을 받고 있습니다.
이제 이 모든 조회를 항상 수행하는 것은 약간의 시간과 리소스 낭비이므로 일반적으로 수행되는 작업은 로컬 DNS 서버가 캐시 역할을 하는 것입니다. 모든 DNS 레코드가 어떻게 보이는지 보셨나요? DNS 레코드의 필드는 다음과 같습니다. 도메인, TTL(Time To Live), 클래스(이 경우 인터넷의 경우 IN), 유형(주소의 경우 A, 이름 서버의 경우 NS 등) 및 데이터(예: IP 주소) 기록).
DNS 레코드의 TTL은 캐시가 데이터를 저장할 수 있는 기간을 나타냅니다. 변경되지 않을 것으로 예상되거나 거의 변경되지 않는 레코드의 TTL은 길다. 예를 들어 우리가 살펴본 처음 몇 개의 레코드에서 172800초 TTL이 있었습니다. 갑작스럽게 업데이트될 수 있는 레코드의 TTL은 300초 TTL과 같이 낮습니다.www.example.com.
DNS 조회를 할 때마다 이미 찾고 있는 데이터가 캐시되어 있으면 루트 서버까지 갈 필요가 없습니다. 우리는 일반적으로 항상 .com 도메인에 액세스하므로 데이터는 거의 항상 로컬 DNS 서버에 캐시됩니다. 그러나 이는 DNS 데이터를 변경할 때마다 변경 사항이 전파되는 데 시간이 걸릴 수 있음을 의미합니다. 실질적으로 이는 TTL을 미리 변경하거나 변경 사항이 완전히 적용되는 데 시간이 걸릴 것이라고 상사에게 알려야 함을 의미합니다.
도메인을 등록하려면 일반적으로 등록하려는 최상위 도메인의 등록 기관으로 이동해야 합니다. 대부분의 호스팅 회사와 도메인 등록 기관은 다양한 최상위 도메인에 도메인을 등록할 수 있으므로 그 중 하나를 선택할 수 있습니다.
등록기관은 등록소의 재판매자입니다. 레지스트리는 문제의 최상위 도메인을 실제로 운영하는 회사 또는 조직이지만 최종 사용자로서 처리해야 할 것은 등록기관 또는 호스팅 회사뿐입니다.
대부분의 등록 기관에는 위임 및 DNS 레코드에 대한 많은 기술적 세부 사항을 처리하는 웹 인터페이스가 있지만, 그럼에도 불구하고 등록 기관의 웹 인터페이스에 의존하더라도 DNS의 기본 사항을 이해하면 작업이 훨씬 쉬워집니다.
DNS에 대해 더 자세히 알고 싶고 IT 분야에서 일하고 있다면 DNS가 어떻게 작동하는지 알아야 합니다. 왜냐하면 DNS는 수많은 잠재적인 문제의 원인이기 때문입니다. 저는 O'Reilly의 DNS and Bind 책을 추천합니다. 매우 포괄적이며 DNS 전문가가 될 것입니다. 자신만의 DNS 서버를 운영하고 싶다면 이 책을 꼭 읽어보시길 권합니다. Bind DNS 서버 소프트웨어도 다루지만, 모든 DNS 서버 소프트웨어에도 동일한 원칙이 적용됩니다.