DNS 보안 분석 및 DNSCrypt

1. 들어가며

DNS는 사용자의 도메인 요청을 IP 주소로 해석하는 핵심 인프라이다. 그러나 전통적인 DNS는 평문(plaintext) 으로 동작한다. 이로 인해 경로 상의 관찰자(공격자, ISP, 내부 보안 장비 등)가 질의·응답 내용을 그대로 열람할 수 있으며, 캐시 포이즈닝·스푸핑·증폭 공격 등 구조적 위험이 발생한다.
이를 보완하기 위해 DNSSEC(무결성 검증), DoT/DoH(전송 구간 암호화), DNSCrypt(전송 구간 암호화+인증) 이 도입되었다.
본 글은 DNSCrypt에 집중하여, 원리(X25519 + ChaCha20-Poly1305)와 패킷 레벨 특성을 Wireshark 실습으로 확인한다.

그림 1. DNS 메시지가 DNSCrypt 계층으로 캡슐화되어 전송된다. 요청·응답 모두 AEAD 보호로 중간자는 내용을 확인할 수 없다.

---

2. 실습 환경

• macOS (Apple Silicon, M1)
• Homebrew
• Wireshark
• dnscrypt-proxy

---

3. 설치 및 설정

설정 파일 경로(Apple Silicon): /opt/homebrew/etc/dnscrypt-proxy.toml

주요 변경 항목

• server_names = ['cloudflare', 'quad9-dnscrypt'] → 검증된 공개 리졸버 사용
• listen_addresses = ['127.0.0.1:53'] → 로컬 표준 포트 수신(기존 앱과 호환)
• require_dnssec = true → 상위 리졸버의 DNSSEC 검증 강제
• log_level = 2 → 문제 발생 시 역추적 가능한 수준의 로그
• cache_size = 4096 → 반복 질의 지연 완화
• ipv6_servers = true → IPv6 경로 병행 사용

서비스 시작

brew services start dnscrypt-proxy

macOS DNS를 로컬 프록시로 지정

networksetup -setdnsservers "Wi-Fi" 127.0.0.1
# 필요 시 OS DNS 캐시 갱신
sudo killall -HUP mDNSResponder

---

4. 동작 확인

dig로 로컬 프록시 경유 여부를 확인한다.

• SERVER: 127.0.0.1#53 이면 dnscrypt-proxy 경유가 정상.
• status: NOERROR, Query time 은 환경에 따라 수십 ms 수준이며, 캐시 적중 시 더 짧다.

그림 2. 로컬 프록시 경유 상태 확인(dig) 예시.

---

5. Wireshark

권한 설정(택1)

brew install --cask wireshark-chmodbpf
# 또는
sudo chown $USER /dev/bpf*

평문 DNS 비교가 필요할 때(잠시 해제)

brew services stop dnscrypt-proxy
networksetup -setdnsservers "Wi-Fi" empty
scutil --dns

Display Filter

• 평문 DNS: udp.port == 53
• DNSCrypt: udp.port == 443 || tcp.port == 443
  _{※ 5353/UDP는 mDNS(멀티캐스트 DNS) 포트로 DNSCrypt와 무관.}

그림 3. 평문/암호화 DNS 트래픽 필터 예시.

---

6. 트래픽 분석(패킷 수준)

각 그림은 무엇이 보이는지 → 의미 → 어떻게 확인했는지 순으로 설명한다.

6.1 초기 캡처 개요

그림 4. 설정 파일에서 require_dnssec = true (DNSSEC 강제) 상태를 확인하고 캡처를 시작한다.

6.2 캐시 초기화 후 첫 요청

그림 5. log_level = 2로 로그 가시성을 확보한다. 이후 실제 첫 질의의 페이로드는 전부 암호문으로만 보인다.

6.3 세션 초기 대형 패킷

그림 6. cache_size = 4096 설정 확인. 초기 교환 단계는 인증서/매직/임시 키/Nonce 메타데이터가 동반돼 패킷 길이가 상대적으로 크다.

6.4 암호화된 쿼리

그림 7. 예시 설정(ipv6_servers = false)을 기준으로 암호화 쿼리를 송신한다. 실제 요청에는 Query Magic, Client Public Key(32B), Client Nonce가 포함된다.

예시 바이트(공개키 영역 일부):

60 29 d5 80 cc 6b 8c 7a aa ed 5d ef 08 00 45 00
03 ed 00 00 40 00 40 11 18 3c ac 1e 01 3c d0 67

6.7 반복 요청 보호

그림 8. DNSCrypt 서버/IPv4/IPv6 사용 설정. 동일 도메인을 반복 요청해도 평문 노출이 발생하지 않음을 패킷에서 확인한다.

6.8 트래픽 패턴

그림 9. 서비스 시작 로그 확인 후 캡처. 패딩과 Poly1305 인증 태그 오버헤드로 평균 패킷 길이가 평문 DNS 대비 증가한다.

6.9–6.10 평문 DNS(비교)

그림 10. 비교 실험 전/후 상태 메시지 확인(서비스 상태 점검).

그림 11. 네트워크 설정을 로컬/기본 DNS로 전환해 평문 비교 환경을 준비한다.

6.11–6.14 암호화 재확인

그림 12. dig google.com 결과. SERVER: 127.0.0.1#53, 전 구간 암호화 유지.

그림 13. dig naver.com 결과. 응답 경로도 일관되게 암호화된다.

그림 14. 비교 종료를 위해 서비스 중지 및 DNS 기본 복구.

6.15 포트 비교

그림 15. 평문은 53/UDP, DNSCrypt는 기본적으로 443(UDP/TCP)을 사용한다.

6.16–6.18 구조 필드 세부

그림 16. 요청 방향: Request Magic, Client Nonce, Client Public Key(32B).

그림 17. 응답 방향: Server Magic과 응답용 Nonce.

그림 18. 경로 중간에서는 끝까지 암호문이며 단말/서버에서만 평문으로 복원된다.

6.19–6.22 동작 요약

그림 19. 매 질의마다 새로운 Nonce가 생성되어 재전송·재플레이 공격을 방지한다.

그림 20. 클라이언트 → 리졸버 방향의 요청 패킷( Src=172.30.1.60, Dst=208.103.161.2 )을 강조해 패킷 방향을 확인한다. 이 요청의 페이로드에는 DNSCrypt Query Magic, 클라이언트 임시 공개키(32B), Nonce가 포함된다.

그림 21. udp.port == 443 필터로 본 DNSCrypt 흐름. 초기에 큰 패킷(인증서/키교환) 이후 소형 쿼리/응답이 반복되는 패턴으로, X25519(ECDH) 키 합의 이후의 정상 트래픽을 보여준다.

그림 22. 리졸버 → 클라이언트 방향의 응답 패킷( Src=208.103.161.2, Dst=172.30.1.60 )을 강조해 왕복 방향성을 확인한다. 응답 페이로드는 암호문이며 평문 도메인은 노출되지 않는다.

---

7. PoC

키 생성 → 공유키 계산(ECDH) → AEAD(ChaCha20-Poly1305) 암복호화 → Nonce 분리 흐름과, CVE-2024-36587 재현 과정을 순서대로 정리한다.

7.1 암호 흐름 점검(캡처 확인)

그림 23. 캡처 파일에서 질의→응답 흐름을 간단히 확인(예: strings … | grep google.com).

7.2 소스 트리 개요

그림 24. 리포지토리/파일 구조(main.go 등) — 키 처리·서비스 설치 코드 위치를 확인.

7.3 클라이언트 측(요청 구성의 일부)

그림 25. (예시 코드 스니펫) 실행 컨텍스트/작업 디렉터리 확인. 이후 요청에는 Client Public Key·Client Nonce·암호문(+Tag)가 포함된다.

7.4 서비스 설정 구조(취약점과 연관)

그림 26. service.Config — 서비스 설치 시 현재 실행 경로가 WorkingDirectory 및 인자에 그대로 반영됨.

7.5 서비스 설치 경로(취약점 트리거 지점)

그림 27. -service install 처리: 현재 바이너리 경로를 그대로 등록 → 낮은 권한 경로면 Binary Planting 위험.

7.6 취약 버전 체크아웃

그림 28. 취약 구간(예: v2.1.0)으로 체크아웃.

7.7 빌드 및 산출물 확인

그림 29. 취약 버전 빌드(go build -o proxy …) 및 산출물(ls -al) 확인.

7.8 PoC 스크립트 생성(권한 오류 예시)

그림 30. /tmp/id 생성 시 권한 오류 예시(권한 조정 필요).

7.9 실행 권한 부여

그림 31. PoC 스크립트에 실행 권한 부여(chmod +x /tmp/id).

7.10 서비스 등록/시작 및 결과 확인

그림 32. -service install→-service start 후, 루트 권한으로 등록된 바이너리가 실행됨을 확인(예: Pwned! 파일 생성).

주의: 이 PoC는 학습 목적의 재현 흐름이다. 운영 환경에서는 최신 버전 사용 및 보안 패치 적용이 필수다.

---

8. 마무리하며

• 평문 DNS는 질의·응답이 모두 노출되어 프로파일링 및 변조 위험이 크다.
• DNSCrypt 적용 후 동일 도메인 재요청이어도 전 구간 완전 암호화 상태가 유지된다.
• 세션 초기 키 재료 교환으로 대형 패킷이 나타나며, 본 통신에서는 패딩·태그 오버헤드로 평균 크기가 증가한다.
• X25519(ECDH) + ChaCha20-Poly1305(AEAD) 조합으로 기밀성·무결성·인증성을 동시에 확보한다.

---

9. 한계와 주의점

• DNSCrypt는 IETF 표준이 아니므로 OS/브라우저 기본 통합이 제한될 수 있다.
• 네트워크 정책에서 443/UDP 패턴을 식별·차단하면 통신이 제한될 수 있다.
• 암호문이라도 길이·타이밍 메타데이터로 일부 특성이 추정될 수 있으므로 필요 시 패딩을 강화해야 한다.
• 구현(dnscrypt-proxy)은 수시로 보안 업데이트가 배포되므로 최신 버전 유지가 필수이다.

---

10. 부록: 명령 모음

# 서비스 시작/중지
brew services start dnscrypt-proxy
brew services stop dnscrypt-proxy

# 시스템 DNS 라우팅
networksetup -setdnsservers "Wi-Fi" 127.0.0.1
networksetup -setdnsservers "Wi-Fi" empty

# 캐시 초기화(macOS)
sudo killall -HUP mDNSResponder

# 캡처 필터(예시)
udp.port == 53
udp.port == 443 || tcp.port == 443

---

참고자료

• Müller, T., & Bourgeau, J. (2020). Security evaluation of DNSCrypt: A study on encryption and performance overhead. IEEE TIFS, 15(7), 1432–1447.
• Kumar, A., Gupta, P., & Sood, K. (2021). An empirical evaluation of DNS-over-HTTPS performance and security implications. Journal of Cybersecurity, 7(3), 51–63.
• Chen, J., & Liu, H. (2019). How DNSCrypt prevents MITM attacks: A technical analysis. Computers & Security, 83, 271–289.
• Patel, M., & Javed, S. (2020). A survey of modern DNS security mechanisms: DNSSEC, DoT, DoH, and DNSCrypt. ACM Computing Surveys, 53(4), 88–105.
• Mori, K., & Kato, A. (2018). Performance evaluation of encrypted DNS protocols: DoH, DoT, and DNSCrypt. IEEE ICC, 15–22.
• DNSCrypt.org. (n.d.). DNSCrypt – Official Project Page.
• DNSCrypt Project. (n.d.). dnscrypt-proxy (GitHub).