Today Keys : DNS, Domain, 동작방식, 도메인, 53, tld, 질의, 쿼리, 소개, 루트, root
본 포스팅은 'IT 엔지니어를 위한 네트워크 입문' [길벗] 서적에 포함된 '7.2 DNS'장의 내용 중 소개 및 7.2.3장과 7.2.2장의 내용입니다
7.2.3 DNS 동작 방식
도메인을 IP 주소로 변환하려면 DNS 서버에 도메인 쿼리하는 과정을 거쳐야 합니다. 하지만 DNS 서버없이 로컬에 도메인과 IP 주소를 직접 설정해 사용할 수도 있습니다. 로컬에서 도메인과 IP 주소를 관리하는 파일을 hosts 파일이라고 합니다. hosts 파일에 도메인과 IP 주소를 설정 해두면 해당 도메인 리스트는 항상 DNS 캐시에 저장됩니다.
도메인을 쿼리하면 DNS 서버에 쿼리를 하기 전 로컬에 있는 DNS 캐시 정보를 먼저 확인합니다.
동일한 도메인을 매번 질의하지 않고 캐시를 통해 성능을 향상시키기 위해서입니다. 이런 DNS 캐시 정보에는 기존 DNS 조회를 통해 확인한 동적 DNS 캐시와 함께 hosts 파일에 저장되어 있는 정적 DNS 캐시가 함께 저장되어 있습니다. DNS 캐시 정보에 필요한 도메인 정보가 없으면 DNS 서버로 쿼리를 수행하고 DNS 서버로부터 응답을 받으면 그 결과를 캐시에 먼저 저장합니다. 전에 쿼리를 한 번 수행한 DNS 정보는 캐시부터 조회하므로 DNS 서버에 별도로 쿼리하지
않고 캐시 정보를 사용합니다.
그림 7-16은 윈도에서 DNS 캐시를 확인한 결과입니다. 윈도에서 DNS 캐시를 확인하려면 명령 창에서 ‘ipconfig /displaydns’ 명령을 사용합니다.
인터넷이 상용화되기 전에는 인터넷에 연결된 단말이 많지 않았습니다. 스마트폰에 각자의 전화번호부를 저장하듯 각 단말에 hosts 파일을 넣어두고 그 안에 호스트 이름과 IP를 매핑하는 테이블이 있었습니다. hosts 파일이 정적 테이블이어서 단순하게 그 정보를 검색하면 간단히 주소 변환이 가능해 캐시 개념이 필요없었습니다. 인터넷이 상용화된 후 폭증하는 단말들을 중앙화된 체계로 수용하기 위해 DNS 체계가 만들어졌습니다. 기존 hosts 관리가 어려웠던 문제를 해결하기 위해 중앙집중식 시스템을 구성했고 폭증한 단말을 수용하기 위해 hosts처럼 플랫이 아닌 계층 구조를 채택했습니다. 기존 hosts 체계와 새로운 DNS 체계가 결합하면서 복잡해보이는 도메인 이름 쿼리 프로세스가 만들어졌습니다.
캐시와 DNS를 이용해 도메인 이름 쿼리를 하는 예제입니다.
그림 7-17은 zigispace.net 이라는 도메인을 쿼리하기 위해 먼저 로컬 캐시를 조회하고 로컬 캐시에 없으면 DNS 서버로 다시 쿼리해 도메인 쿼리를 수행합니다.
지금까지 클라이언트 관점에서 DNS 질의 과정을 설명했다면 지금부터는 반대로 DNS 시스템 관점에서 도메인에 대한 결괏값을 클라이언트에 보내주는 과정을 살펴보겠습니다.
전 세계 도메인 정보를 DNS 서버 하나에 저장할 수는 없습니다. 데이터 자체도 방대하지만 인터넷에 엄청나게 많은 사용자가 등록하고 삭제하는 도메인 리스트를 실시간으로 업데이트할 수 없기 때문입니다. 그래서 DNS는 분산된 데이터베이스로 서로 도와주도록 설계되었는데 자신이 가진 도메인 정보가 아니면 다른 DNS에 질의해 결과를 받을 수 있습니다. DNS 기능을 서버에 올리면 DNS 서버는 기본적으로 루트 DNS 관련 정보를 가지고 있습니다. 클라이언트의 쿼리가 자신에게 없는 정보라면 루트 DNS에 쿼리하고 루트 DNS에서는 쿼리한 도메인의 TLD 값을 확인해 해당 TLD 값을 관리하는 DNS가 어디인지 응답합니다.
예를 들어 zigispace.net이라는 도메인을 클라이언트가 DNS 서버에 쿼리했다면 DNS 서버는 루트 DNS에 다시 쿼리하고 루트 DNS는 .net에 대한 정보를 관리하는 DNS 주소 정보를 DNS 서버에 응답합니다. 이 응답을 받은 DNS 서버는 .net을 관리하는 DNS 서버에 zigispace.net에 대해 쿼리합니다. .net을 관리하는 DNS 서버는 다시 zigispace.net을 관리하는 DNS 관련 정보를처음 DNS 서버에 응답합니다. DNS 서버는 마지막으로 zigispace.net을 관리하는 DNS에 쿼리하고 zigispace.net에 대한 최종 결괏값을 받게 됩니다. 처음 쿼리를 받은(클라이언트에 DNS 서버로 설정된) DNS 서버는 이 정보를 클라이언트에 응답합니다.
전체 과정을 보면 클라이언트에서 처음 질의를 받은 DNS가 중심이 되어 책임지고 루트 DNS부터 상위 DNS에 차근차근 쿼리를 보내 결괏값을 알아낸 후 최종 결괏값만 클라이언트에 응답합니다. 클라이언트는 한 번의 쿼리를 보내지만 이 요청을 받은 DNS 서버는 여러 단계로 쿼리를 상위 DNS 서버에 보내 정보를 획득합니다. 호스트가 DNS 서버에 질의했던 방식을 재귀적 쿼리(Recursive Query)라고 하고 DNS 서버가 루트 NS와 TLS NS, zigispace.net NS에 질의한 방식을 반복적 쿼리(Iterative Query)라고 합니다.
| 참고 재귀적 쿼리(Recursive Query)와 반복적 쿼리(Iterative Query) 재귀적 쿼리는 쿼리를 보낸 클라이언트에 서버가 최종 결괏값을 반환하는 서버 중심 쿼리이고 반복적 쿼리는 최종값을 받을 때까지 클라이언트에서 쿼리를 계속 진행하는 방식입니다. 일반적으로 재귀적 쿼리는 클라이언트와 로컬 DNS 간에서 사용하고 반복적 쿼리는 로컬 DNS 서버와 상위 DNS 구간에서 사용합니다. 이때 로컬 DNS는 클라이언트로 동작해 상위 DNS에 반복적으로 쿼리합니다. |
다음 그림은 위에서 설명한 쿼리 과정입니다.
1. 사용자 호스트는 ‘zigispace.net’이라는 도메인 주소의 IP 주소가 로컬 캐시에 저장되어 있는지 확인합니다.
2. ‘zigispacenet’이 로컬 캐시에 저장되어 있지 않으면 사용자 호스트에 설정된 DNS에 ‘zigispace.net’에 대해 쿼리합니다.
3. DNS 서버는 ‘zigispace.net’이 로컬 캐시와 자체에 설정되어 있는지 직접 확인하고 없으면 해당 도메인을 찾기 위해 루트 NS에 .net에 대한 TLD 정보를 가진 도메인 주소를쿼리합니다.
4. 루트 DNS는 ‘zigispace.net’의 TLD인 ‘.net’을 관리하는 TLD 네임 서버 정보를 DNS서버에 응답합니다.
5. DNS는 TLD 네임 서버에 ‘zigispace.net’에 대한 정보를 다시 쿼리합니다.
6. TLD 네임 서버는 ‘zigispace.net’에 대한 정보를 가진 zigi 네임 서버에 대한 정보를 DNS 서버로 응답합니다.
7. DNS는 zigi 네임 서버에 ‘zigispace.net’에 대한 정보를 쿼리합니다.
8. zigi 네임 서버는 ‘zigispace.net’에 대한 정보를 DNS 응답합니다.
9. DNS는 ‘zigispace.net’에 대한 정보를 로컬 캐시에 저장하고 사용자 호스트에 ‘zigispace.net’에 대한 정보를 응답합니다.
10. 사용자 호스트는 DNS로부터 받은 ‘zigispace.net’에 대한 IP 정보를 이용해 사이트에 접속합니다.
