DNS란 무엇입니까? 도메인 이름 시스템 소개

컴퓨터 앞에 앉아 있으면 인터넷이 단순해 보입니다. 브라우저를 열고 도메인 이름을 입력하면 화면에 웹사이트가 표시됩니다. 그러나 GUI(그래픽 사용자 인터페이스) 아래에는 DNS(Domain Name System)로 알려진 광범위한 소프트웨어 및 서버 네트워크가 있습니다. 그러나 DNS는 무엇이며 장치에서 웹을 보는 데 어떻게 도움이 됩니까?

이에 대한 대답은 복잡하고 많은 수의 움직이는 부품이 관련되어 있기 때문입니다. 체인의 거의 모든 링크가 서버를 사용한다는 것을 알게 될 것입니다. 또한 빠른 페이지 로딩 속도를 저해할 수 있는 병목 현상을 줄이는 데 도움이 되는 기술이 있습니다.

이 게시물에서는 DNS를 가장 직관적으로 이해할 수 있도록 도와드리겠습니다. 이 기사에서 다룰 내용을 요약해 보겠습니다.

인터넷이 서버에서 브라우저로 웹 페이지를 가져오는 방법

요약하자면, DNS는 읽을 수 있는 도메인 이름을 그것이 나타내는 결과 인터넷 프로토콜(IP) 주소로 변환하는 방식입니다. 이것은 표면적으로는 간단한 작업처럼 보이지만 실제와는 거리가 멉니다.

각 웹 사이트는 서버에 있으며 각 서버(및 실제로 컴퓨터)에는 IP 주소가 있습니다. DNS는 IP 주소를 도메인 이름에 매핑하는 시스템이므로 사용자 친화적인 브라우징을 즐길 수 있습니다. 비유로, 거리 이름과 집 주소가 실제로 지도 좌표의 집합이라는 것을 생각해 보십시오. 우리는 위치의 경도와 위도를 단순화하기 위해 주소를 사용합니다.

IP 주소를 도메인 이름으로 변환할 때(또는 그 반대로) 이것이 'DNS 확인'입니다. 이 체인에는 여러 하드웨어 구성 요소, 특히 4가지 다른 유형의 서버가 있습니다. 이것들은 다음에 논의합시다.

웹 페이지를 가져오고 로드하는 4개의 DNS 서버

모든 DNS 요청 및 확인은 4개의 서버를 거칩니다. 간단히 말해서 다음과 같습니다.

• DNS 재귀. 이것은 전체 DNS에 대한 '워터 캐리어'입니다. 브라우저에서 웹사이트를 요청할 때 재귀에게 DNS에서 사이트를 찾아 찾도록(또는 '조회') 지시합니다.
• 루트 네임서버. 많은 사이트를 포함하는 웹 서버를 고려한다면 루트 네임서버가 전체를 나타냅니다. IP 주소의 일반적인 위치입니다.
• 최상위 도메인(TLD) 네임서버. 웹 사이트는 루트 이름 서버 내에 있지만 TLD 이름 서버는 IP 주소의 마지막 부분인 호스트 이름의 끝 부분을 파냅니다. .com, .net 또는 무수히 많은 다른 사이트가 될 수 있습니다.
• 권위 있는 네임서버. 이 복잡한 서버를 단순하게 만들기 위해 IP 주소에 대한 참조 라이브러리입니다. 이 서버는 전체 IP 주소를 다시 브라우저에 표시하는 반복자에게 보냅니다.

DNS 쿼리는 쿼리가 해결되기 전에 이러한 모든 단계를 여러 번 거칩니다. 따라서 체인에는 쿼리 실패를 유발할 수 있는 많은 지점이 있습니다. 따라서 HTTP 오류가 발생합니다.

하지만 이 사슬의 앞과 뒤를 더 자세히 파헤쳐 볼 가치가 있습니다. 다음은 이 작업을 수행해 보겠습니다.

DNS 반복자와 권한 있는 네임서버의 차이점

재귀는 쿼리 결과를 가져오고 전체 DNS 프로세스의 시작이라는 것을 이해하게 될 것입니다. 차례로, 권한 있는 네임서버가 이 프로세스의 결과를 재귀에게 다시 전달한다는 것도 알게 될 것입니다. 그러나 둘 다 알아야 할 더 많은 차이점이 있습니다.

• DNS 재귀. 이 서버는 DNS 쿼리 요청에 응답합니다. 체인을 따라 DNS 레코드를 추적한다는 점에서 활성입니다. 재귀에 대한 일반적인 접근 방식은 다른 서버에 여러 요청을 보내는 것이지만 캐싱을 사용하면 이 시간을 줄일 수 있습니다. 이에 대해서는 나중에 더 이야기하겠습니다.
• 권위 있는 네임서버. 이 서버는 모든 DNS 레코드를 보유합니다. 재귀를 포함하여 체인의 다른 서버로부터 받은 정보를 기반으로 요청에 응답하는 것이 작업입니다. 브라우저가 웹사이트를 표시할 수 있게 하는 것은 이 서버입니다. 신뢰할 수 있기 때문에 쿼리의 유효성을 검사하기 위해 다른 소스를 참조할 필요가 없습니다. 바로 소스입니다.

그러나 권한 있는 네임서버가 DNS 요청의 끝점이지만 항상 그런 것은 아닙니다. 요청에 따라 이 시점 이후에 추가 네임서버를 찾을 수도 있습니다.

DNS 쿼리가 하위 도메인(예: shop.example.com)에 대한 경우 권한 있는 이름 서버 다음에 추가 이름 서버가 있음을 알 수 있습니다. 이것은 해당 하위 도메인에 대한 CNAME 레코드를 저장합니다.

이론적으로 쿼리가 요청하는 추가 네임서버의 수에는 제한이 없습니다. 그러나 대부분의 경우 하나의 추가 네임서버만 있을 것입니다.

DNS 조회 작동 방식

DNS 조회 및 쿼리를 처리하는 4개의 서버가 있지만 체인에는 쿼리를 전달하고 결과를 가져오는 많은 단계가 있습니다. 조회 프로세스가 작동하는 방식은 다음과 같습니다.

• 브라우저에 도메인 이름을 입력합니다. Enter 를 클릭하면 쿼리가 브라우저와 운영 체제(OS)에서 DNS 재귀가 수신하는 인터넷으로 이동합니다.
• 재귀는 이 쿼리를 루트 네임서버에 전달하고 자체 쿼리를 수행합니다.
• 이 쿼리의 결과는 TLD 네임서버가 되며, 이 네임서버는 재귀로 반환됩니다.
• 이번에는 재귀가 TLD 이름 서버를 쿼리하고 도메인의 권한 있는 이름 서버의 IP 주소로 응답합니다.
• 재귀는 권한 있는 네임서버에 또 다른 쿼리를 보내고, 이 네임서버는 초기 도메인 요청에 대한 IP 주소로 응답합니다.

여기에서 재귀는 작업 결과를 웹 브라우저로 다시 보냅니다. 이것은 DNS 프로세스를 완료하고 재귀는 몇 밀리초 동안 휴식할 수 있습니다! 그런 다음 브라우저는 브라우저에 사이트를 표시하기 위해 HTTP 요청을 처리합니다.

서버가 달성할 수 있는 것에 비해 복잡하고 노동 집약적인 단계가 많이 있으며 이는 전 세계적으로 초당 수십억 번 발생합니다. 그럼에도 불구하고 조회 내에서 발생하는 쿼리는 세 번뿐입니다.

DNS 조회에서 찾을 수 있는 쿼리

DNS 클라이언트와 서버 간에 이러한 각 쿼리 내에는 관계가 있습니다. 이것들은 일반적인 용어이지만 설명에서 구체적인 사항을 기록할 것입니다.

• 재귀 쿼리. 이 쿼리에서 클라이언트는 DNS 재귀가 요청된 DNS 레코드나 오류 메시지로 응답하도록 요청합니다.
• 반복 쿼리. 이 쿼리는 반환되는 내용으로 '최상의 추측'을 할 수 있는 무료 라이선스를 재귀에 제공합니다. 쿼리에 대해 일치하는 항목이 없으면 이 '경로'가 소진될 때까지 결과는 더 낮은 수준의 권한 있는 서버에 대한 참조가 됩니다.
• 비재귀 쿼리. DNS 레코드가 캐시에 있거나 재귀에 레코드에 대한 권한 있는 액세스 권한이 있는 경우 이 쿼리가 발생한다는 것을 알 수 있습니다. 우리는 기사의 끝 부분에서 캐싱에 대해 이야기할 것입니다.

많은 경우 재귀 및 비재귀 쿼리가 가장 일반적이라는 것을 알게 될 것입니다. 이것이 오류 메시지가 표시되는 이유와 조회 프로세스가 복잡할 수 있는 이유입니다.

DNS 캐싱에 대한 입문서

비재귀 쿼리를 처리할 때 레코드는 DNS 레코드 전용 캐시에 상주할 수 있습니다. 캐싱에 대해 알고 있다면 정기적으로 액세스하는 파일이 캐싱에 포함된다는 것을 알게 될 것입니다. 로컬 앱이 이 작업을 수행할 수 있지만 사이트의 캐시가 가장 좋은 예입니다.

이렇게 하면 사이트 파일에 대한 기록이 유지되므로 HTTP 요청 수를 줄일 수 있습니다. DNS 레코드에서도 마찬가지입니다. 이렇게 하면 관련 레코드가 컴퓨터 위치에 더 가깝게 유지되므로 일반적으로 수행하는 것보다 빠르게 IP 주소를 가져올 수 있습니다.

웹 개발자의 경우 GET 요청은 브라우저에서 발행하는 것입니다. 캐시를 사용하면 재귀는 체인의 다른 서버를 잘라내고 권한 있는 네임서버로 바로 이동하거나 추가 쿼리 없이 이를 호출합니다. 만들 수 있는 가장 일반적인 비재귀 쿼리입니다.

실제로 ISP(인터넷 서비스 공급자), 라우터 및 로컬 컴퓨터와 같은 여러 기술에서 DNS 캐시를 찾을 수 있습니다.

브라우저 캐시는 DNS 레코드를 찾는 재귀 호출의 첫 번째 포트이며, 따라서 브라우저는 종종 기본 설정으로 레코드를 캐시합니다. OS에도 DNS 확인자가 있으며 이것은 DNS 레코드에 대한 캐시도 확인합니다.

다시 말하지만, OS가 캐시 내에 레코드를 포함하지 않으면 처리를 위해 쿼리를 ISP 재귀로 보냅니다. 이 두 재귀는 전체 조회 프로세스가 발생하기 전에 도메인의 A 및 NS 레코드와 함께 작동하여 쿼리를 시도하고 해결합니다.

DNS 레코드 변경: '전파'

말하자면 레지스트라를 통해 A , NS 또는 CNAME 레코드를 변경할 수 있습니다. 많은 경우 이러한 변경 사항이 모두 등록되기까지 총 72시간이 소요됩니다.

이것은 DNS 전파이며 완료하는 데 걸리는 시간은 여러 요인, 즉 연결된 레코드의 TTL(Time To Live) 값에 따라 다릅니다.

간단히 말해서 특정 DNS 레코드에 대해 변경 사항이 적용되는 속도를 결정합니다. 일반적인 TTL은 약 4시간이며 값이 높을수록 이 전파 시간이 더 오래 걸립니다.

등록 대행자는 종종 귀하의 네임서버에 대한 TTL을 설정하므로 귀하 또는 다른 사람은 변경할 수 없습니다. 이것이 종종 전파가 완료될 때까지 기다려야 하는 이유이며 What's My DNS?와 같은 사이트를 지속적으로 확인하는 이유입니다. 진행 상황을 측정하기 위해:

해결책은 DNS 레코드를 변경하기로 결정하기 전에 TTL을 최대한 설정하는 것입니다. 물론 레지스트라는 네임서버에 대한 책임이 있지만 전파 시간을 줄이기 위해 최선을 다했을 것입니다.

결론

웹 페이지에 액세스하는 것이 간단하다고 생각한다면 다시 생각해 보십시오. 최종 사용자의 경우 프로세스는 기본적으로 간단합니다. 그러나 내부적으로는 훨씬 더 복잡하고 많은 추가 서버가 필요합니다.

이 게시물은 인터넷이 도메인 이름을 가져와 IP 주소로 확인하는 방식인 DNS를 살펴보았습니다. 거기에서 브라우저로 돌아가서 웹 페이지로 렌더링할 수 있습니다. 그러나 전파 및 캐싱과 같은 다른 많은 프로세스도 발생한다는 것을 알게 될 것입니다. 결합하면 빠르고 (대부분) 문제 없는 브라우징이 가능합니다.

이 기사가 "DNS란 무엇입니까?"라는 질문에 대한 답이라고 생각하십니까? 그렇지 않은 경우 더 많은 질문이 있습니까? 그렇다면 아래 의견 섹션에서 질문하십시오!