dig +trace란 무엇인가요?

dig +trace는 해당 도메인의 위임 체인을 모두 추적합니다. 루트 네임 서버에서 최상위 도메인(TLD) 서버 및 권한 있는 이름 서버까지 추적할 수 있습니다. dig +trace는 팀이 DNS 확인 문제를 해결하는 데 도움이 됩니다.

가장 즉각적으로 드러나는 문제는 장애 알림 화면에서 알 수 있듯이 특정 도메인 또는 하위 도메인과의 연결에 완전히 실패하는 것입니다. 또 다른 유형의 DNS 확인 문제는 지연 시간으로, 일반적인 인내심을 넘어 쿼리 시간이 길어질 수 있습니다.

평균 DNS 조회 시간은 밀리초(MSEC) 단위로 측정되며, 보통 20MSEC에서 120MSEC 사이로 떨어지는 경향이 있습니다. 최적화를 통해 이러한 쿼리 시간을 더욱 단축할 수 있습니다.

일반적인 dig 명령에서는 인터넷 서비스 제공업체(ISP)의 확인자 역할을 하는 DNS 서버가 재귀 요청을 실행하고 로컬 캐시에서 만료되지 않은 최신 DNS 레코드가 있는지 확인합니다. 하지만 이는 모든 것이 정상적으로 작동하는 이상적인 상황에서 일어나는 일입니다. 

관리자는 '내부적으로' 확인해야 할 때 dig +trace를 사용합니다. 일반적으로 문제가 발생했기 때문에 일반적인 쿼리 프로세스를 우회해야 합니다. 라우팅 체인의 일부가 제대로 작동하지 않는 경우가 있습니다. 따라서 관리자는 해당 체인의 일부와 다양한 연결 고리를 분석하고 연구하여 무엇이 제대로 작동하지 않는지 파악할 수 있어야 합니다.

팀은 dig + trace를 사용하면 이전에 캐시된 내용을 효과적으로 무시할 수 있으므로 오래되고 더 이상 사용되지 않는 경로로 라우팅되지 않고 새로운 반복 쿼리를 실행할 수 있습니다.

dig +trace는 DNS 확인이 중단되는 위치를 확인할 수 있으므로 문제 해결에 유용합니다. 문제는 루트, TLD 또는 권한 수준에서 발생할 수 있습니다. 또한 도메인의 이름 서버 레코드가 올바른지 확인하고 변경 후 DNS 전파를 확인할 수 있습니다.

발굴+추적 과정은 사실 네 단계로 요약됩니다.

사용자가 이전에 해당 도메인 이름을 입력했고 컴퓨터가 해당 IP 주소를 캐시한 경우 명령 프롬프트(CMD)는 필요한 IP 주소를 즉시 검색합니다. 시스템이 요청된 콘텐츠에 액세스하여 다운로드하면 쿼리 프로세스는 그 자리에서 종료됩니다. 

그러나 도메인 이름이 새롭고 해당 장치에서 알 수 없는 경우 나머지 단계가 실행됩니다.

dig 명령은 조사 대상 도메인의 최상위 도메인(TLD)과 연결된 이름 서버(NS) 레코드에 대한 루트 네임 서버를 찾습니다.

dig 명령은 TLD 이름 서버를 조사하여 특정 도메인에 대한 권한 있는 이름 서버를 찾습니다.

그런 다음 dig 명령은 권한 있는 이름 서버를 쿼리하여 요청된 DNS 레코드에 액세스합니다. 예를 들어, 'A 레코드'는 사람에게 친숙한 도메인 네임을 IPv4 또는 IPv6 주소와 연결하는 리소스 레코드입니다. 한편 권한 시작(SOA) 레코드에는 DNS 영역에 필요한 관리 데이터가 보관됩니다.

제공되는 DNS 응답에는 원래 쿼리에 성공적으로 응답할 수 있는 리소스 레코드인 '응답 섹션'('질문 섹션'이라고도 함)이 포함됩니다.

또한 응답에는 권한 있는 이름 서버를 나열하는 권한 섹션과 추가 정보가 포함된 '추가 섹션'이 있을 수도 있습니다. 관리자는 메일 서버(MX 레코드) 또는 이름 서버(NS 레코드) 등 원하는 레코드 유형을 정확하게 선택할 수 있습니다.

해당 경로의 각 조사 단계에서 관리자는 각 단계의 상태와 진행 상황이 의도한 대로 진행되고 있는지 알려주는 출력 메시지를 받습니다.

예를 들어, 관리자에게는 이 테스트 단계에서 인시던트가 없음을 알리는 '오류 없음' 메시지가 표시됩니다. (참고: 이 메시지는 전반적인 운영 성공 또는 실패를 나타내지 않으므로 잘못 해석해서는 안 됩니다. 유용하지만 전달되는 정보는 제한적입니다.)

흥미로운 점은 DNS 인프라가 DNS 계층 구조를 지원하고 독창적인 조회 시스템을 사용하여 조회 프로세스를 지원한다는 점입니다. 이러한 방식으로 한 서버가 쿼리를 완료할 수 없는 경우 기본적으로 쿼리를 다른 서버로 안내하여 쿼리의 진행을 돕고 여정을 확장합니다. 

인터넷에서 사용되는 도메인 이름 시스템은 다양한 수준에서 작동하는 여러 루트 이름 서버로 구성되어 있습니다. 가장 중요한 것은 최상위 수준에서 작동하는 13개의 논리적 루트 이름 서버로, 알파벳의 처음 13개 문자로 이름이 지정됩니다.

이 13개의 논리적 루트 이름 서버는 각각 단일 컴퓨터나 운영 체제를 가리키는 것이 아니라 모든 인터넷 DNS 쿼리 트래픽의 1/13을 관리하는 지정된 기관을 나타냅니다. 따라서 '서버 A'는 개별 DNS 서버를 무제한으로 포함할 수 있는 서버 A 지정을 의미합니다.

또한 13개의 루트 이름 서버가 대학 및 군 기관과 혼합된 다양한 영리 기업 등 다양한 단체에 위임되어 있다는 점도 주목할 필요가 있습니다. 원래 대부분의 물리적 서버의 위치가 미국에 집중되어 있었던 것은 사실이지만, 시간이 지남에 따라 그 균형이 재조정되고 있습니다. 이제 물리적 서버는 전 세계에 걸쳐 있습니다.

다음은 13개의 서로 다른 root-servers.net 지정을 실행하는 책임이 있는 그룹입니다.

• 서버 A(.root-servers.net): 운영 기관: VeriSign, Inc. 전 세계에 인터넷 인프라 및 도메인 이름 레지스트리 서비스를 제공합니다.

• 서버 B(b.root-servers.net): 운영자: 서던 캘리포니아 대학교(ISI). USC의 Information Sciences Institute는 고급 컴퓨터 및 통신 기술을 연구합니다.

• 서버 C(c.root-servers.net): 운영 기관: Cogent Communications. 대규모 광섬유 네트워크를 운영하며 코로케이션 서비스를 제공하는 국제 ISP입니다.

• 서버 D(d.root-servers.net): 운영 기관: 메릴랜드 대학교(University of Maryland). 산하 첨단 사이버 인프라 및 글로벌 인터넷 서비스(ACIGS) 그룹이 관리합니다.

• 서버 E(e.root-servers.net): 운영 기관: NASA. 보다 구체적으로는 미국 우주항공국의 네트워크 및 통신 서비스(NaTS) 조직이 운영합니다. 

• 서버 F(f.root-servers.net): 운영 기관: Internet Systems Consortium, Inc. 다양한 소프트웨어와 프로토콜을 제공하며 인터넷을 지원하는 비영리 기관입니다.

• 서버 G(g.root-servers.net): 운영 기관: 미국 국방부 네트워크 정보 센터(DoD NIC). 국방부의 IPv6 주소 계획 관리도 담당하고 있습니다.

• 서버 H(h.root-servers.net): 운영 기관: 미국 육군 연구소(ARL). 과거에는 탄도 연구소(BRL)로 알려져 있었습니다.

• 서버 I(i.root-servers.net): 운영 기관: Netnod. 북유럽 지역의 상호 연결 서비스를 중심으로 활동하는 스웨덴의 비영리 인터넷 인프라 기관입니다.

• 서버 J (j.root-servers.net): 운영자: VeriSign, Inc. (서버 A 참조). 

• 서버 K(k.root-servers.net): 운영 기관: RIPE NCC(Reseaux IP Europeens Network Coordination Centre). 유럽, 중동, 아시아 지역을 담당하는 비영리 지역 인터넷 레지스트리(RIR)입니다.

• 서버 L(l.root-servers.net): 운영 기관: ICANN(Internet Corporation for Assigned Names and Numbers). 미국 정부 계약을 통해 출범했으며, 현재는 독립적인 글로벌 비영리 조직으로 운영되고 있습니다.

• 서버 M(m.root-servers.net): 운영 기관: WIDE 프로젝트(Widely Integrated Distributed Environment). 일본의 3개 대학 간 협력으로 시작된 인터넷 프로젝트입니다. 

쿼리 트래픽은 13개의 서버에 고르게 분산되며, 어떤 서버도 다른 서버보다 더 많은 트래픽을 처리하지 않습니다. 지역적 요인에 따라 사용자가 가장 많이 접속하는 서버에 영향을 미칠 수 있지만, 전반적으로 트래픽은 비슷하며 대부분 ISP 주소 요청과 관련이 있습니다.

DNS 쿼리 트래픽을 관리하는 데 13개 기관이 필요한 이유는 매년 수조 개의 DNS 쿼리가 생성되기 때문입니다. 일부 추산에 따르면 총 100조 개가 넘을 것으로 예상되지만 이 수치는 추측에 불과합니다. 실제로는 계산할 수 없을 정도로 큰 숫자입니다.

이와 밀접하게 관련된 몇 가지 문제도 해결해야 합니다.

• DNS의 활용도를 높이는 한 가지 방법은 DNS용 확장 메커니즘(EDNS)을 사용하는 것입니다. EDNS는 DNS 프로토콜을 위한 향상된 기능 모음입니다. 관리자가 더 큰 DNS 메시지 페이로드를 마주하면 EDNS는 이러한 대용량 데이터 패키지를 처리하도록 조정합니다. 더 큰 메시지를 수용하는 것 외에도 EDNS는 종종 지연 문제의 영향을 받는 애플리케이션의 성능 수준을 향상시키는 EDNS 클라이언트 서브넷(ECS)과 같은 옵션도 제공합니다.

• OPT 의사 섹션은 EDNS에서 시작한 고유한 유형의 DNS 레코드입니다. 유용한 트랜잭션 정보는 전달하지만 표준 DNS 데이터는 전달하지 않습니다. OPT 의사 섹션은 DNS 메시지의 '추가 데이터' 섹션에 포함되어 있습니다. 일반적으로 사용되는 쿼리 형식인 사용자 데이터그램 프로토콜(UDP)의 EDNS 버전, 플래그 및 최대 패킷 크기와 같은 세부 정보를 제공합니다. 

• Linux 운영 체제 및 특정 유닉스 계열 시스템은 etc/resolv.conf 구성 파일을 사용하여 해당 호스트 이름의 IP 주소를 찾기 위해 확인자 루틴을 활성화하도록 시스템에 알립니다. 이 파일의 내용에는 DNS 서버의 IP 주소, 검색할 도메인 목록, 로컬 도메인 이름 및 확인자 작업을 결정할 수 있는 옵션이 포함됩니다. 이러한 작업에는 관리자가 단독으로 적용할 수 있는 설정인 전역 옵션이 포함될 수 있습니다. 

• DNS를 실제로 사용하지 않는 유닉스 계열 시스템에는 매뉴얼 페이지(또는 '맨 페이지')가 있는 경우가 많습니다. 이 페이지는 특정 명령 파일, 시스템 호출 또는 구성 파일에 대해 정의된 데이터를 간략하게 설명하는 문서 역할을 합니다. 매뉴얼 페이지는 명령어 또는 프로그램 이름, 개요, 설명, 옵션 등의 정보를 중심으로 시스템 파일 및 도구에 대한 일반적인 맥락을 제공합니다.