DevOps 6일차 - DNS(예습)

DNS

https://www.cloudflare.com/ko-kr/learning/dns/what-is-dns/

DNS 조회의 단계

• 사용자가 웹 브라우저에 'example.com'을 입력하면, 쿼리가 인터넷으로 이동하고 DNS 재귀 확인자가 이를 수신합니다.
• 이어서 확인자가 DNS 루트 이름 서버(.)를 쿼리합니다.
• 다음으로, 루트 서버가, 도메인에 대한 정보를 저장하는 최상위 도메인(TLD) DNS 서버(예: .com 또는 .net)의 주소로 확인자에 응답합니다. example.com을 검색할 경우의 요청은 .com TLD를 가리킵니다.
• 이제, 확인자가 .com TLD에 요청합니다.
• 이어서, TLD 서버가 도메인 이름 서버(example.com)의 IP 주소로 응답합니다.
• 마지막으로, 재귀 확인자가 도메인의 이름 서버로 쿼리를 보냅니다.
• 이제, example.com의 IP 주소가 이름 서버에서 확인자에게 반환됩니다.
• 이어서, DNS 확인자가, 처음 요청한 도메인의 IP 주소로 웹 브라우저에 응답합니다.
• DNS 조회의 8단계를 거쳐 example.com의 IP 주소가 반환되면, 이제 브라우저가 웹 페이지를 요청할 수 있습니다.
• 브라우저가 IP 주소로 HTTP 요청을 보냅니다.
• 해당 IP의 서버가 브라우저에서 렌더링할 웹 페이지를 반환합니다(10단계).
  

DNS 서버

• DNS 리졸버 - 리졸버 도서관의 어딘가에서 특정한 책을 찾아달라고 요청받는 사서로 생각할 수 있습니다. DNS 리졸버 웹 브라우저 등의 애플리케이션을 통해 클라이언트 컴퓨터로부터 쿼리를 받도록 고안된 서버입니다. 일반적으로, 리졸버 클라이언트의 DNS 쿼리를 충족시키기 위해 추가 요청을 수행합니다.
• 루트 이름 서버 - 루트 서버는 사람이 읽을 수 있는 호스트 이름을 IP 주소로 변환(확인)하는 첫 번째 단계입니다. 도서관에서 책장 위치를 가리키는 색인으로 생각할 수 있으며, 일반적으로 다른 더욱 특정한 위치에 대한 참조로 사용됩니다.
• TLD 이름 서버 - TLD(최상위 도메인) 서버는 도서관의 특정 책장으로 생각할 수 있습니다. 이 이름 서버는 특정 IP 주소 검색의 다음 단계이며 호스트 이름의 마지막 부분을 호스팅합니다(example.com에서 TLD 서버는 “com”입니다).
• 권한 있는 이름 서버 - 최종 이름 서버로서, 책장에 있는 사전처럼 특정 이름을 해당 정의로 변환합니다. 권한있는 이름 서버는 이름 서버 쿼리의 종착점입니다. 권한있는 이름 서버가 요청한 레코드에 대한 액세스 권한이 있다면, 요청한 호스트 이름의 IP 주소를 초기 요청을 한 DNS 리커서(사서)에게 돌려 보냅니다.

DNS 확인자

DNS 확인자는 DNS 조회의 첫 번째 중단점이며, 최초 요청을 한 클라이언트 처리를 담당합니다. 확인자는 URL이 궁극적으로 필요한 IP 주소로 변환되도록 하는 일련의 쿼리를 시작합니다.

참고: 캐시되지 않은 일반적인 DNS 조회에는 재귀 쿼리와 반복 쿼리가 모두 포함됩니다.

재귀 DNS 쿼리와 재귀 DNS 확인자를 구분하는 것이 중요합니다. 쿼리는 쿼리 확인을 요구하는 DNS 확인자에게 하는 요청을 의미합니다. DNS 재귀 확인자는 재귀 쿼리를 수락하고 필요한 요청을 수행하는 방식으로 응답을 처리하는 컴퓨터입니다.

DNS 쿼리 유형

• 재귀 쿼리 - 재귀 쿼리에서는, 확인자가 레코드를 찾을 수 없는 경우, DNS 클라이언트는 DNS 서버(일반적으로 DNS 재귀 확인자)가, 요청한 자원 레코드 또는 오류 메시지를 사용하여 클라이언트에 응답하도록 요구합니다.
• 반복 쿼리 - 이 경우, DNS 클라이언트는 DNS 서버가 가능한 최상의 응답을 반환하도록 합니다. 쿼리한 DNS 서버가 쿼리 이름과 일치하는 이름을 갖고 있지 않은 경우, 하위 수준의 도메인 네임스페이스에 대해 권한 있는 DNS 서버에 대한 참조를 반환합니다. 그러면 DNS 클라이언트가 참조 주소를 쿼리합니다. 이 프로세스는 오류 또는 제한 시간 초과가 발생할 때까지 추가 DNS 서버가 쿼리 체인을 중단한 상태로 계속됩니다.
• 비재귀 쿼리 - 일반적으로, DNS 확인자 클라이언트의 쿼리를 받은 DNS 서버가 해당 레코드에 대한 권한이 있거나 캐시 내부에 해당 레코드를 갖고 있어, DNS 서버가 액세스 권한을 갖고 있는 레코드를 쿼리할 때 발생합니다. 일반적으로, DNS 서버는 추가 대역폭 소비 및 업스트림 서버의 부하를 방지하기 위해 DNS 레코드를 캐시합니다.

DNS 캐싱

캐싱의 목적은 데이터를 임시 저장하여, 데이터 요청에 대해 성능과 신뢰성을 높이는 것입니다. DNS 캐싱은 요청하는 클라이언트와 가까운 곳에 데이터를 저장함으로써, DNS 쿼리를 조기에 확인할 수 있고 DNS 조회 체인의 추가 쿼리를 피할 수 있으므로, 로드 시간이 향상되고 대역폭/CPU 소비가 줄어듭니다. DNS 데이터는 다양한 위치에 캐시될 수 있으며, 각 위치는 TTL(Time-To-Live)에 의해 정의된 설정 시간 동안 DNS 레코드를 저장합니다.