DNS, DNS 쿼리, DNS 레코드, Domain의 구조

DNS, nslookup

 

DNS(Domain Name System)은 도메인 주소를 IP 주소로 변환해주는 것.

 

DNS서버에는 IP주소와 도메인주소가 저장되어 있다.

우리들은 DNS서버에 도메인주소를 통해 IP를 물어보고 그 IP를 통해 웹 사이트에 접속할 수 있게 되는 것이다.

과거 DNS 서버가 없었을 때는 스탠포드 리서치 센터에서 host 파일을 다운 받아야만 했다...🤢

일반 인터넷 사용 뿐만 아니라 웹 아키텍쳐가 MSA 트렌드가 되면서 서비스 간의 API 호출이 많아짐에 따라 서비스의 관점에서도 DNS 를 이해하는 것이 중요해졌다.

 

개발자가 DNS 서버에게 특정 IP를 특정 도메인과 연결지어 사용하겠다고 알린다.

그 후, 유저가 도메인을 접속하면 DNS에서 IP를 전달해주고 최종적으론 유저가 이 IP를 통해 웹사이트로 접속하게 된다.

아무 설정도 하지 않았는데 도메인 주소를 사용할 수 있는건, ISP에서 제공하는 기본 DNS 서버를 사용하도록 기본적으로 설정되어 있기 때문이다. 국내 ISP가 기본 DNS를 제공해준다는 점에서 착안하여 옛날엔 음란 사이트 차단을 하기도 했다. 현재는 다른 방식을 사용하고 있다.

과거 대한민국 정부에서는 DNS를 이용해서 warning.or.kr을 띄웠었다. 국내 ISP들이 돌리는 DNS 서버에 차단하고 싶은 특정 주소를 입력하면 warning.or.kr 로 자동 리다이렉트 되는 식이었다.

출처) https://namu.wiki/w/DNS

 

하여튼 DNS 서버의 핵심은

1. DNS서버에게 도메인을 주고 IP를 얻어온다는 것

2. 접속은 결국 IP 주소로 하게 된다는 것.

 

자신이 사용하고 있는 DNS 서버의 주소를 확인해보려면 아래처럼 확인해보자.

 

 

DNS의 레코드를 조회하고 싶을 때는 아래처럼 nslookup을 사용해봅시다.

www.44bits.io/ko/keyword/cli--nslookup 44bits에서 설명을 잘해줬으니 갈음합니다.

 

nslookup google.com

 

위는 현재 내가 이용하고 있는 DNS 서버의 주소

아래는 google.com의 ip를 말한다.

 

 

Public DNS?

그런데 DNS 서버 ip도 모르고 설정도 아무 것도 해주지 않았는데

어떻게 DNS 서버에 요청을 보내고 ip를 받아올 수 있는 것일까?

 

ISP(internet service provider) 즉, 인터넷 회사 혹은 통신사라고 부르는 곳에서 기본적으로 제공하는 DNS 주소를 사용하도록 설정되어 있다. 보통 통신사들은 자신들이 소유하거나 제휴를 맺은 DNS 서버에 접속한 로그 데이터를 이윤을 목적으로 사용한다.

이런 문제 때문에 인터넷 회사가 자동으로 지정한 DNS 서버를 사용하고 싶지 않을 수도 있다.

 

때문에 Public DNS 서버를 이용하기도 한다.

대표적으로 google public DNS나 Cloudflare에서 만든 public DNS가 있다.

 

물론 구글이나 cloudflare를 믿을 것인지는 본인 판단이다. 😒

또, 이러한 public DNS를 서비스하는 곳은 대부분 외국이니 때문에 국내 사이트 접속이 늦어질 수도 있다.

그럼에도 불구하고 public DNS를 써보겠다면 아래 문서를 읽어보고, DNS 주소를 바꿔주면 된다.

 

https://developers.google.com/speed/public-dns

https://1.1.1.1/dns/

 

 

로컬 호스트 파일과 DNS 파일의 동작 방식

요청을 보내면 DNS에서 해당 도메인 주소와 매핑된 ip 주소를 가져온다는 대강의 방식은 알았지만,

사실 로컬 내부의 호스트 파일을 먼저 거친 후에 요청이 가는 방식으로 동작합니다. 

 

도메인 쿼리 (브라우저에 도메인 주소 입력)

=> 로컬에 있는 캐싱된 DNS 정보를 확인합니다. DNS 요청을 한 번 이상한 동적 DNS 캐쉬와 로컬 호스프 타일인 정적 DNS 캐쉬 확인

=> 여기를 거쳤는데도 없으면 DNS 서버에 요청을 보냄.

 

로컬 호스트 파일은 일종의 개인적인 IP 전화번호부라고 할 수 있다.

 

그래서 피싱 사기에서 주로 이용하는 곳이기도 하다. DNS 안 거치고 여기에 쇼핑몰 사이트 하나 얹어 놓으면 피싱 사이트로 연결이 될테니까. 참고삼아 호스트 파일을 열어서 구경해보자.

각 경로에 대해서는 여기 참고 : https://en.wikipedia.org/wiki/Hosts_(file)

Win 10 "C:\Windows\System32\drivers\etc"
Unix 계열(Mac 포함) "/etc/hosts"

맥에서 호스트를 까봤는데 다음과 같은 결과물이 나왔다.

 

 

도메인 이름의 구조

 

역트리 구조입니다. 즉, 오른쪽부터 왼쪽으로 위계가 형성되어 있습니다.

 

• sub domain : second level 도메인 아래 있다고 해서 sub 도메인 (www 라는 서브 도메인을 많이 봤을 것이다)
  • Sub Domain의 역할은 한 사이트 내에서 다양한 서비스를 제공할 때 주로 사용한다.
  • ex - https://mail.google.com/, https://drive.google.com/
• second-level domain(SLD)
• top-level domain(TLD) : 가장 높은 도메인. .com, .net. .co.kr ...
• root : 모든 도메인 주소의 끝에는 . 이 숨어 있다.

 

이 각 부분들마다 담당하는 독자적인 서버 컴퓨터가 존재한다. 위를 예로 들면

서브 도메인 담당 서버 (최하위)

세컨드 레벨 도메인 담당 서버

탑 레벨 도메인 담당 서버

Root Name Server (최상위)

 

특기할 점은

 

루트 담당 서버는 탑 레벨 도메인 담당 서버들의 목록을 알고 있어야 하며

탑 레벨 도메인 담당 서버는 세컨드 레벨 도메인 담당 서버의 목록을 알고 있어야 하며

세컨드 도메인 담당 서버는 서브 도메인 담당 서버의 목록을 알고 있어야 한다.

정리하면, 일종의 계층 구조를 형성하고 있다.

 

왜냐하면 유저가 요청하는 방식이 root에 물어보고 꼬리를 물어 sub domain까지 내려오는 역트리 구조이기 때문이다.

최종적인 ip 주소는 서브 도메인 담당 서버가 알고 있지만 처음 접근하는 곳은 root 담당 서버이다.

 

 

DNS 주요 레코드들

cloudflare에서 설명을 정말 잘해놨더라구요

www.cloudflare.com/ko-kr/learning/dns/dns-records/

 

도메인에는 다양한 내용을 매핑할 수 있는 레코드란게 있습니다.

DNS 레코드(또는 영역 파일)는 권한 있는 DNS 서버에 있는 명령으로서, 도메인에 연계된 IP 주소와 해당 도메인에 대한 요청의 처리 방법에 대한 정보를 제공합니다. 모든 DNS 레코드에는 'TTL'이 있는데, 이는 time-to-live의 약어로 DNS 서버가 해당 레코드를 새로 고치는 빈도를 나타냅니다.

 

조금 추상적인데, aws route 53에 접속하면, 호스팅 영역마다 지정할 수 있는 레코드가 있는 것을 확인할 수 있습니다.

다음은 제 cineps.net 호스팅 영역 내부에 있는 레코드들입니다. A, NS, SOA, TXT, CNAME 등을 확인해보실 수 있습니다.

 

DNS 레코드는 다음과 같이 정리됩니다.

각 레코드에 대해 살펴보자면,

 

A 레코드는 도메인 주소를 IPv4 주소로 매핑하는 것입니다.

cineps.net을 123.123.123.123 주소와 매핑하는 가장 간단한 형태의 DNS 레코드입니다.

 

AAAA 레코드는 IPv6주소로 매핑하는 것입니다. 여남은 것들은 A 레코드와 동일합니다.

 

CNAME은 canonial 레코드로, alias 즉, 별칭을 사용할 수 있게 해줍니다. 쉽게 말하면, 어떤 도메인 주소를 다른 도메인 주소로 매핑하는 겁니다. 예를 들어 www.cineps.net으로 접속하면 cineps.net으로 연결하게 해줍니다. 물론 둘 다 A 레코드로 매핑해도 동일한 동작을 하지만, IP 주소를 바꿔야 하는 경우 두 번 설정할 걸, www.cineps.net이 cineps.net을 바라보게 해주어 한 번만 설정하게 된다는 그런겁니다.  

 

SOA는 start of authority로 도메인 영역에 대한 권한을 나타냅니다. 

 

NS는 Name Server입니다. 도메인에 대한 관리자 정보를 저장합니다

 

MX는 이메일을 이메일 서버로 전송합니다. 이메일 포워딩할 때 이 녀석을 좀 만졌었죠.

 

 

도메인 이름 등록의 원리 및 과정

간단하게 3단계로 설명해보자.

 

1. 도메인 구입

 

등록자가 등록대행자를 통해 example.com를 구매하고 싶다고 요청한다.

등록대행자로는 가비아, AWS route 53과 같은 곳이 있다.

도메인 구입을 검색하면 나오는 업체가 등록대행자에 속한다.

 

탑 레벨 도메인(.com) 별로 등록소가 다르다.

마치 .vn이 베트남 정부 차원에서 관리하는 도메인인 것처럼.

등록소에서 중복을 체크하고 등록자가 요청한 도메인이 사용하능하다고 판명나면

등록자는 등록대행자를 통해 수수료를 지불하고 도메인을 사용할 수 있게 된다.

 

2. 구입한 도메인에 IP 연결

 

연결 자체는 쉽다. 연결 이후의 과정을 살펴보자.

 

서비스하고자 하는 페이지의 ip를 도메인과 연결하면

등록대행자는 이 정보를 담고 있는 자신들의 서버를 등록소에 알려준다.

앞서 탑 레벨 도메인 서버가 세컨드 레벨 도메인 서버의 목록을 알고 있다는 것이 이런 의미인 것이다.

 

 

3. 유저가 도메인에 접근할 때 DNS에서 IP 전달하기

 

1.1.1.1. DNS 서버를 사용하는 사용자가 도메인을 검색한다. (Cloudflare public DNS)

 

1.1.1.1. DNS 서버는

우선, ICANN (루트 네임 서버를 소유한 비영리단체)에게 물어보고 ICANN은 자신이 자기고 있는 등록소 서버를 말해준다.

다음, 등록소 서버(.com을 담당하는 회사)에서는 등록대행자의 서버를 말해준다.

마지막, 등록대행자의 서버에서 IP를 최종적으로 알아낸다

 

얻어낸 IP로 접속한다. 접속 완료!

 

 

 

reference)

 

dns 등록했으면 여기에 넣어서 전파 되었는지 체크해보세요. (조급증이 있다면 ㅋㅋ)

dnschecker.org/

DNS Checker - DNS Check Propagation Tool