Port 53에서 시작되는 은밀한 통신 DNS 이야기

우리는 주소창에 google.com을 입력하면 당연하다는 듯 구글 홈페이지가 열리는 간편한 세상에 살고 있습니다.

하지만 그 평온한 화면 뒤에서는 Port 53을 통해 흐르는 은밀한 DNS(Domain Name System) 요청이 조용히 일을 처리하고 있습니다.

이제 부터 DNS에 대한 기본 개념과 동작 원리, 그리고 공격자가 사용할 수 있는 기본적인 방식을 알아보겠습니다.

1. DNS란 무엇인가?

DNS는 도메인 이름을 IP 주소로 변환하는 시스템 입니다.

사람이 기억하기 쉬운 도메인 이름(google.com)을 컴퓨터가 이해하는 숫자형 IP 주소(172.217.161.206)로 바꿔 주는 역할입니다.

---

2. DNS 동작 원리

2-1. DNS 조회 과정

1. 사용자가 브라우저에 google.com 주소를 입력하고 요청합니다.

2. 브라우저는 먼저 로컬에 설정된 DNS 리졸버(Resolving Name Server)에게 google.com의 IP 주소를 문의합니다.

3. 로컬 DNS 리졸버는 요청을 처리하기 위해 최상위 DNS 서버인 Root Name Server에 google.com을 문의합니다.

4. Root Name Server는 .com 최상위 도메인을 담당하는 TLD Name Server의 주소를 응답합니다.

5. 로컬 DNS 리졸버는 TLD Name Server에게 google.com의 IP를 문의합니다.

6. TLD Name Server는 google.com 도메인의 정보를 가진 Authoritative Name Server의 주소를 알려줍니다.

7. 로컬 DNS 리졸버는 Authoritative Name Server에 최종적으로 google.com의 IP 주소를 요청합니다.

8. Authoritative Name Server는 도메인의 IP 주소를 찾아 요청의 출발지 IP로 UDP 53 포트를 통해 응답합니다.

9. 로컬 DNS 리졸버는 받은 IP 주소를 브라우저에 전달합니다.

10. 브라우저는 전달받은 IP 주소로 TCP 연결을 하여 google 페이지를 사용자에게 보여줍니다.

2-1-1. DNS 리졸버의 UDP Port 53

로컬 DNS 리졸버는 Authoritative Name Server에 도메인 IP 주소를 요청할 때 목적지 포트는 항상 UDP 53번 출발지 포트는 임의의 고유 포트로 설정하여 요청을 보냅니다.

Authoritative Name Server는 요청의 출발지 IP와 포트 번호를 기반으로 해당 리졸버에게 응답을 되돌려 보냅니다.

따라서 리졸버는 UDP 53 포트를 열어두는 것이 아니라 요청에 사용한 임의의 출발지 포트를 열어두고 응답을 대기하는 구조입니다.

2-1-2. Authoritative Name Server의 서브도메인 처리 특성

Authoritative Name Server는 해당 도메인의 IP를 최종적으로 응답하는 주체입니다.
이때 도메인에 속한 서브도메인까지 모두 직접 관리하거나 DNS Zone 파일에 등록되지 않은 서브도메인 요청에 대해서도 자신에게 온 요청으로 간주해 응답하거나 존재하지 않는 경우에는 NXDOMAIN 오류를 반환하기도 합니다.

😈 OOB / DNS Tunneling

이러한 처리특성을 이용하여 존재하지 않는 무작위 서브도메인 요청을 유도하고 Authoritative Name Server에 해당 요청이 기록되는 특성을 활용해 데이터 유출이나 명령 통신에 이용하는 방식으로 악용됩니다.

 

😈 DNS Reflection

DNS 서버는 요청자의 출발지 IP로 응답을 보내는 특성을 악용해 공격자가 피해자 IP를 출발지로 위조해 요청하면 응답이 피해자에게 전달되어 대량 트래픽이 집중되는 DDoS 공격에 활용되며 주로 UDP 53 포트와 큰 응답(ANY, TXT 레코드)을 사용합니다.

2-2. Cache & TTL (Time To Live)

매 요청마다 조회 과정을 계속 하게 된다면 비효율적일 수 있습니다.

조회 과정에서 응답받은 결과 값을 OS와 DNS 리졸버 두곳에 TTL이 설정된 Cache를 저장합니다.

• OS에 저장된 캐시를 이용하면 브라우저에서 요청 시 DNS 리졸버에 요청하지 않아 빠른 응답이 가능합니다.
• DNS 리졸버에 저장된 캐시는 여러 사용자의 요청을 처리하며 OS 캐시에 없는 경우에도 재사용되어 Root, TLD 등 상위 서버로의 불필요한 조회를 줄입니다.
• 각 캐시에는 TTL이 설정되어 있어 TTL이 만료되면 해당 캐시는 삭제되고 다시 조회 과정을 거치게 됩니다.
• 이를 통해 네트워크 부하를 줄이고 응답 시간을 최소화하며 최신 정보를 적절히 유지할 수 있습니다.

😈 DNS Poisoning

만약 공격자가 이미 유명한 도메인을 운영하고 있다고 가정해봅시다.

어느 날 피해자가 공격자의 도메인에 요청을 보냈을 때 공격자는 정상 IP 대신 악성 코드가 배포되는 IP 주소를 응답할 수 있습니다.

그러면 피해자가 이용하는 DNS 리졸버(예: KT)의 캐시에 악성 IP가 저장됩니다.

따라서 해당 DNS 리졸버를 이용하는 다수의 사용자가 같은 도메인에 접근할 경우 모두 악성 IP로 연결되어 공격을 당할 위험이 커집니다.

---

3. Name Server 종류

• Root Name Server
  • DNS 계층의 최상위 서버 입니다.
  • 도메인의 최상위 확장자(TLD) 서버 위치를 알려줍니다.
  • IANA 관리 하 전 세계 13개 그룹이 분산 운영되고 있습니다.
• TLD(Top Level Domain) Name Server
  • 최상위 도메인별(.com, .net, .kr 등) Name Server 위치를 알려줍니다.
  • Root Name Server가 알려준 TLD 도메인을 관리합니다.
• Authoritative Name Server
  • 특정 도메인의 실제 IP 주소를 관리 및 응답합니다.
  • 도메인 소유자가 지정한 Name Server로 최종 IP 정보를 제공합니다.

---

4. 왜 XSS로는 OOB를 하지 않을까?

처음에는 ‘XSS로도 외부 도메인에 요청을 보낼 수 있는데, 굳이 SQLi나 서버 측 취약점을 통해 DNS 요청을 유도할 이유가 있을까?’라는 생각이 들었습니다.

XSS에서는 fetch, <img>, <script> 같은 태그나 메서드를 통해 외부 도메인으로 요청을 보낼 수 있으니 이걸 활용해서도 DNS 기반 공격이 가능한 게 아닐까 싶었는데 조금 더 생각해보니 이러한 요청들은 단순히 DNS 질의에 그치지 않고 결국엔 TCP 기반의 HTTP 통신(포트 80이나 443) 으로 이어진다는 점이 중요하게 느껴졌습니다.

이런 HTTP 요청들은 대부분의 네트워크 환경에서 방화벽이나 프록시 등의 아웃바운드 정책에 따라 탐지되거나 차단될 가능성이 높고 로그에도 명확하게 남게 됩니다.

반면 SQL Injection처럼 서버 측 취약점을 통해 gethostbyname(), LOAD_FILE(), xp_dirtree, UTL_HTTP.REQUEST 같은 함수를 호출하면 서버 자체에서 DNS 질의가 발생하게 됩니다.

이 경우는 브라우저 보안 정책의 영향을 받지도 않고 HTTP 통신이 아닌 UDP 기반의 DNS 요청만 발생하기 때문에 상대적으로 탐지나 차단이 어려울 수 있다는 점이 떠올랐습니다.

그래서 제 나름의 결론은 DNS를 활용한 공격은 흔적을 최소화하는 게 핵심이라서 XSS보다는 서버 측에서 조용히 DNS 요청을 발생시킬 수 있는 SQLi 방식이 더 적합하다고 여겨지는 게 아닐까 하는 생각이 들었습니다.