2024. 11. 16.

DNS에서 TCP 찾기

Network

"불광불급(不狂不及)"

이중적 의미의 HOSTNAME

우리가 호스트 네임이라고 말하면, 정확하게 어떤 부분인지 다들 다르게 이야기 할 것이다. 내 생각은 컴퓨터가 보는 시각, 그리고 검색창에 사용자가 입력하는 시각 두 가지로 볼 수 있다고 생각한다.

예전에는 웹 시장이 활발하지 않았을 때, chan.com이라는 공간에서 메일은 mail.chan.com, 파일 전송은 ftp.chan.com, 메인 사이트는 www.chan.com과 같이 각 서비스가 별도의 호스트 이름으로 지칭되었다. 이때는 www, mail, ftp와 같은 호스트 이름만 존재했다.

하지만 인터넷망이 발전하면서 계층 구조가 형성되었다. 따라서 단순히 www만으로는 특정 위치를 식별할 수 없게 되었다. 이와 동시에 DNS가 발전하여 호스트 이름을 효과적으로 관리할 수 있는 구조가 마련되었다. 그래서 www를 알기 위해서는 최하위까지 내려가야 하므로, 결국 www는 여전히 호스트 이름으로 간주될 수 있다.

현재는 www 같은 특정 호스트 이름만이 호스트 이름이 될 수 있는 것은 아니다. 과거에는 역사적인 주소인 www.chan.com처럼 정확히 입력해야 했지만, 지금은 chan.com만 입력해도 내부 로직에 따라 자동으로 리다이렉트되는 경우가 많다. 따라서 www의 의미가 과거의 호스트 그 자체에서 벗어나, 이제는 chan.com 등도 호스트 이름으로 인정받을 수 있게 되었다.

또한, 만약 사용자가 여전히 www.chan.com과 같이 직접 입력하더라도, 계층 구조로 인해 www는 chan.com의 자식 도메인이기 때문에 호스트 이름으로 여전히 유효하다. 이러한 변화는 기술 발전과 사용자의 접근 방식의 변화로 인해 일어난 일이다.

DNS를 보통 계층구조라고 말한다. 너무 일반적인 개념이라, 대충 하고 넘어가보면, 로컬, 루트, TLD, 책임 서버들고 구성되어있으며, 사람 입장에서는 로컬 DNS가 재귀적 쿼리가 되는 것이고, 로컬 DNS 입장에서는 반복적 쿼리를 진행하는 방식으로 운영된다.

NS 요청에 대한 결과들

리눅스 환경에서 dig 를 통해서, 네임서버들에 요청하고 결과를 보기 위해, 윈도우 환경에서도 dig 사용을 할 수 있는 ISC에 들어갔지만, 이제 window를 더이상 지원하지 않는다. 그냥 vmware로 했다.

dig www.google.com

dig @a.root-servers.net www.google.com

dig @a.gtld-servers.net www.google.com

dig @ns1.google.com www.google.com

위의 명령어 대로, 네임 서버들을 탐색해 보았다.

[결과 분석 - 루트 서버]

www.google.com의 최종 IP 주소를 제공하지 않는다. 대신 .com 도메인에 대한 TLD 서버 정보를 알려준다.
AUTHORITY SECTION은 요청한 도메인에 대한 권한이 있는 DNS 서버를 알려주는 섹션이다. 루트 서버는 www.google.com에 대한 최종 정보를 갖고 있지 않기 때문에 .com TLD를 관리하는 DNS 서버 목록을 반환한다. 이 섹션에는 .com 도메인을 관리하는 TLD 서버들의 네임서버(NS) 레코드가 포함된다.
ADDITIONAL SECTION은 AUTHORITY SECTION에서 반환된 네임서버들의 IP 주소를 제공한다. dig 명령어는 효율성을 위해 TLD 서버의 IP 주소도 함께 반환하며, 이를 통해 추가 DNS 조회 없이 바로 해당 TLD 서버에 접근할 수 있다.

[결과 분석 - TLD 서버]

TLD 서버로 접속하려면 먼저 .com 도메인을 담당하는 TLD 서버 중 하나를 지정한다. 루트 DNS 서버를 통해 .com TLD 서버 목록을 조회한 후 하나를 선택할 수 있다.
AUTHORITY SECTION에는 google.com 도메인을 담당하는 구글의 권한 있는 네임서버 목록이 표시된다. 이 결과는 google.com에 대한 최종 IP 주소를 알고 있는 서버들이 ns1.google.com, ns2.google.com 등임을 의미한다. 따라서, 다음 단계에서 www.google.com의 IP 주소를 얻기 위해 구글의 네임서버 중 하나에 질의할 수 있게 된다.
ADDITIONAL SECTION에는 위의 AUTHORITY SECTION에 나온 구글의 네임서버에 접근하기 위한 IP 주소가 포함된다. 이 정보는 구글의 네임서버(ns1.google.com, ns2.google.com, 등)에 대한 IP 주소를 제공하여, 루트 서버에서 받은 정보 없이도 바로 구글의 네임서버로 질의할 수 있도록 한다.

[결과 분석 - 책임 서버]

구글의 권한 있는 DNS 서버로 접속하려면, TLD 서버 응답에서 제공되는 권한 있는 서버 주소를 이용한다.
ANSWER SECTION은 요청한 도메인(www.google.com)에 대한 최종 응답을 포함하며, www.google.com의 IP 주소가 표시된다. 이 정보는 www.google.com의 IP 주소가 142.250.190.196임을 의미한다. 이 주소는 www.google.com에 대한 최종 IP 주소로, 사용자가 웹 브라우저에 www.google.com을 입력했을 때 연결될 실제 서버 IP이다. 이처럼 ANSWER SECTION은 요청한 도메인 이름의 실제 IP 주소를 반환하는 최종 섹션이다.
AUTHORITY SECTION (없을 수도 있음)의 경우에는 다음과 같다. 일부 경우 AUTHORITY SECTION이 표시될 수 있지만, 보통 ns1.google.com이 권한 있는 서버이므로 포함되지 않거나 비어 있을 수 있다. AUTHORITY SECTION이 포함된다면, google.com 도메인을 담당하는 네임서버 정보가 다시 나타날 수 있다.
ADDITIONAL SECTION (없을 수도 있음)의 경우에는 다음과 같다. ADDITIONAL SECTION도 ANSWER SECTION이 완전한 정보를 제공한 경우에는 생략되거나 비어 있을 수 있다. 구글의 네임서버 IP와 같은 추가 정보를 제공하기 위한 섹션이지만, 이미 요청한 도메인에 대한 IP 주소가 ANSWER SECTION에 포함되어 있다면 나타나지 않을 수 있다.

DNS wireshark를 통해 TCP 찾기

나는 학교 다닐 때, dns는 udp 라고 배웠다. 실제로, 가상환경에서 동시에 wireshark 를 키고 있었는데, 요청한 도메인이 UDP 프로토콜을 사용하긴 했다.

하지만 이론을 공부하다보면, dns는 udp로만이 아니다. tcp로 통신할 때가 있다.

응답이 512바이트를 넘어서면 TCP를 사용한다.
ZONE TRANSFER 작업 즉, DNS 서버가 데이터 복제 작업을 할때, TCP를 사용한다.

실제로, sudo lsof -i tcp:53 명령어를 통해 포트 53에서 열린 네트워크 연결을 보여주는데 tcp가 대기중인 것을 볼 수 있다.

또한 RFC문서에서도 그대로 적혀있다. 와이어샤크를 통해, 필터를 걸고, 실제 512 바이트가 넘을때, tcp통신을 하는지 확인해보았다.

그 중, 825 바이트를 넘었을 때를 찾게 되었고 바로 분석해보았다.

전송 계층에서, tcp 프로토콜을 사용했고, FLAG에서도 실제 SYN, ACK가 1로 되어있다. 그래서, DNS는 TCP 도 쓴다.

수많은 UDP 중에서 TCP를 찾는것은 어려웠다. 거의 99.9가 UDP로 통신이 진행되었지만, tcp는 존재했다. 즉, 100%는 아니라는 것을 알 수 있다. 다음에는 기회가 된다면, 직접 zone transfer를 진행해서, tcp 패킷을 찾는 것도 재미있을것 같다.