Understanding DNS — 기본 구조와 레코드¶

이 페이지에서 다루는 것

DNS 서버 4종과 조회 경로, TTL과 캐시, 레코드 종류(A·AAAA·PTR·TXT·CNAME·MX·SRV·NS·HTTPS), 각 레코드의 보안 위험(서브도메인 탈취, 도메인 하이재킹), 그리고 Wireshark에서 DNS 패킷을 읽는 법.

표기

[보충] = 꼭 알아야 할 실무 보충, [정정] = 흔히 잘못 알려진 내용 정정, [변경됨]/[주의] = 최근 바뀐 점과 옛 방식대로 하면 위험한 점. 전체 흐름은 DNS 개요에서, 기록 한 줄을 판별하는 순서는 판별표에서 볼 수 있습니다.

한눈에 보는 핵심 10가지¶

DNS는 주소만 알려준다. 실제 접속은 그 다음에 따로 일어나므로, DNS 기록과 접속(방화벽) 기록을 함께 봐야 한다.
포워딩 서버를 거치면 원래 질문한 PC의 IP가 사라진다. 센서 위치가 가시성을 결정한다.
답은 루트 → TLD → 권한 서버 순으로 찾고, 각 단계에서 TTL만큼 캐시된다.
한 도메인의 답 IP는 여러 개일 수 있다. 전부 기록하고 전부 조사한다.
PTR 질의는 in-addr.arpa 형식으로 거꾸로 적힌다. 보이면 무조건 뒤집어서 읽는다.
PTR은 IP 주인이 아무 이름이나 넣을 수 있다. 증거가 아니라 힌트다.
도메인과 IP는 다대다이고 언제든 바뀐다. 오늘의 답으로 과거 사건을 판단하지 않는다.
악성 도메인의 IP를 막기 전에 그 IP와 통신하는 내부 장비 수를 확인한다. 공유 IP면 도메인을 막는다.
CNAME의 정식 이름은 답에 나온 이름이다. 주인 없는 CNAME은 서브도메인 탈취로 이어진다.
NS를 빼앗기면 도메인 전체(웹, 메일, 인증서)를 빼앗긴다.

DNS 기본 — 서버 4종과 조회 경로¶

DNS는 이름을 IP로 바꾸는 시스템이고, 거의 모든 사건 조사에서 "IP + 그 IP를 가리킨 도메인"을 함께 기록하게 됩니다.

서버 4종¶

종류	위치·예	하는 일	캐시
스텁 리졸버	내 PC (Windows DNS Client)	기억한 답이 있으면 주고, 없으면 설정된 서버로 넘김	함
포워딩 서버	회사 도메인 컨트롤러, 공유기	모르면 위로 넘김. 끝까지 찾아가지 않음	함
재귀(캐싱) 서버	8.8.8.8, 1.1.1.1, 9.9.9.9, ISP DNS, Pi-hole	루트부터 직접 찾아다님	함
권한 네임서버	ns1.google.com	자기 존(zone)의 정답 원본을 가짐	안 함

가장 중요한 점: 포워딩 서버는 받은 질문을 전달하지 않고, 자기 IP로 새 질문을 만들어 보냅니다. 그래서 포워딩 서버 위쪽에서 수집한 기록에는 질문자가 전부 서버 IP 하나로만 보입니다.

재귀 조회 경로¶

내 PC → 회사 포워딩 서버 → 재귀 서버로 질문이 올라감
재귀 서버 → 루트("."): "모름, .com 서버에 물어봐"
재귀 서버 → .com 서버: "모름, ns1.google.com에 물어봐"
재귀 서버 → 권한 서버: 실제 IP 답
답이 역순으로 내려오며 재귀 서버·포워딩 서버·PC에 각각 캐시됨

2~4단계를 오가는 주체는 전부 재귀 서버입니다. 각 서버는 한 칸 아래만 알면 되므로 인터넷 전체를 알 필요가 없습니다. 같은 회사의 다른 PC가 TTL 안에 같은 이름을 물으면 포워딩 서버 캐시에서 답이 나와 바깥으로 나가지 않습니다. 그래서 바깥쪽 센서에는 첫 조회 한 번만 보입니다.

TTL¶

TTL은 "이 답을 몇 초 동안 믿어도 되는가"이며 도메인 주인이 정합니다. 위층일수록 길고(루트 NS 6일), 실제 서비스 IP일수록 짧습니다(google.com A 300초).

짧은 TTL(60초 이하)은 CDN·클라우드에서 흔합니다. 공격자의 Fast Flux도 같은 방식이라, TTL은 다른 신호와 겹칠 때만 의미가 있습니다.
ipconfig /displaydns의 남은 TTL로 조회 시점을 역산할 수 있습니다. 원래 TTL 300, 남은 TTL 187이면 약 113초 전 조회입니다.

직접 보는 명령¶

Windows 캐시: ipconfig /displaydns, Get-DnsClientCache (Record Type 1 = A, 5 = CNAME)
Linux 캐시: resolvectl show-cache, resolvectl statistics
조회 경로: dig +trace google.com A

전송 포트¶

기본은 UDP 53, 응답이 크면 TC 플래그 후 TCP 53으로 재질의합니다. 지금은 DoH(TCP 443), DoT(TCP 853), DoQ(UDP 853), HTTP/3 기반 DoH(UDP 443)도 있어 53번만 감시하면 놓칩니다. 루트 서버 이름은 13개지만 애니캐스트로 실제 장비는 전 세계 수천 대입니다.

레코드 종류와 A/AAAA¶

레코드 타입은 "DNS에 던지는 질문의 종류"입니다. 같은 이름이라도 A를 물으면 IP가, MX를 물으면 메일 서버가 나옵니다.

타입 번호표¶

타입	번호	묻는 것	비고
A	1	이름 → IPv4	가장 흔함
AAAA	28	이름 → IPv6	A와 보통 쌍으로 나옴
NS	2	담당 권한 서버 이름
CNAME	5	별명 → 정식 이름
SOA	6	존 기본 정보
PTR	12	IP → 이름
MX	15	메일 서버
TXT	16	임의 텍스트
SRV	33	서비스 위치 + 포트
SVCB	64	서비스 접속 정보	비교적 최근 추가 (RFC 9460, 2023)
HTTPS	65	HTTPS 접속 정보	비교적 최근 추가, 지금 매우 흔함

로그가 숫자로만 남는 경우가 있으므로 1, 28, 5, 12, 16, 65는 숫자로도 알아둡니다.

A/AAAA에서 챙길 다섯 가지¶

Question: 물어본 이름. 대답 패킷에도 확인용으로 다시 들어 있음
Answer: 답 IP. 여러 개일 수 있음. 첫 번째만 적으면 실제 접속 IP를 놓침
Transaction ID: 질문과 대답을 짝짓는 번호표(16비트)
TTL: 캐시 유지 시간(초)
Source/Destination IP: 목적지 서버가 답을 원래 알고 있었다는 뜻은 아님. 위쪽 구간에서는 출발지가 진짜 질문자가 아닐 수 있음

실무 포인트¶

사이트 한 번 방문에 질의 수십~수백 개가 나갑니다(예: 대형 포털 한 번 방문에 A 60개 + AAAA 95개). 의심 질의 하나를 보면 같은 PC의 앞뒤 몇 초를 시간순으로 펼쳐 출발점을 찾습니다.
"1초에 40개" 같은 숫자만으로 감염을 판단하지 않습니다. 무작위 문자열 이름, NXDOMAIN 폭증, 출발점 없음, 새벽 시간, 이상한 프로세스가 겹치면 DGA 같은 악성 패턴입니다.
A와 AAAA가 쌍으로 보이는 것은 정상입니다.
캐시 포이즈닝 방어는 Transaction ID + 출발지 포트 무작위화입니다. DNS 서버의 질의 출발지 포트가 고정돼 있으면 취약점입니다.

[2026] HTTPS 레코드(65)가 바꾼 것¶

예: dig -t HTTPS cloudflare.com +short → 1 . alpn="h3,h2" ipv4hint=104.16.132.229 ech=...

alpn="h3" 때문에 브라우저가 HTTP/3(UDP 443)로 바로 붙습니다. TCP 443만 보면 놓칩니다.
ipv4hint 때문에 A 질의 없이 접속이 일어날 수 있습니다. "DNS 없이 나간 연결 = 의심" 규칙이 흔들립니다.
ech=는 ECH 공개키입니다. ECH가 켜지면 네트워크에서 사이트 이름(SNI)이 안 보이므로 DNS 기록의 가치가 올라갑니다.

PTR — 역방향 조회¶

PTR은 IP → 이름을 묻는 레코드입니다(역방향 전화번호 조회). 함정은 두 가지: 주소가 거꾸로 적히고, 결과를 믿을 수 없습니다.

함정 1: 거꾸로 적힌다¶

nslookup 8.8.4.4를 치면 실제 패킷의 질의는 4.4.8.8.in-addr.arpa입니다.

이유: DNS 이름은 오른쪽이 큰 범위(www.google.com), IP는 왼쪽이 큰 범위(8.8.4.4). 방향을 맞추려고 뒤집습니다.
in-addr.arpa는 역방향 전용 구역입니다.
읽는 법: 꼬리를 떼고, 점으로 나뉜 덩어리(옥텟) 4개 순서를 뒤집습니다. 덩어리 안의 숫자는 뒤집지 않습니다.
예: 36.129.85.203.in-addr.arpa → 203.85.129.36
흔한 실수: 뒤집지 않고 위협 정보 사이트에 넣으면 엉뚱한 IP가 깨끗하게 나와 사건을 잘못 종결합니다.
IPv6는 ip6.arpa를 쓰고 16진수 글자 하나씩 뒤집습니다. 손으로 풀지 말고 dig -x <IP>를 씁니다.

함정 2: 믿으면 안 된다¶

결론: PTR 레코드가 말하는 것을 믿지 마라.

A는 도메인 주인이, PTR은 IP 주인이 설정합니다. 둘은 다른 사람일 수 있습니다.
IP 주인은 PTR에 남의 도메인 이름도 넣을 수 있습니다.
한 IP 뒤에 사이트가 수천 개여도 PTR은 IP 주인이 고른 이름 하나만 줍니다.
Google조차 불일치: google.com → 142.250.6.206 → PTR lga25s72-in-f14.1e100.net
클라우드 IP의 PTR은 ec2-...amazonaws.com처럼 "클라우드 어딘가"만 알려줍니다.

FCrDNS (Forward-Confirmed reverse DNS)¶

IP를 PTR 조회 → 이름을 얻음
그 이름을 정방향(A) 조회 → 원래 IP가 나오는지 확인

일치하면 도메인 주인도 그 IP를 인정한 셈입니다. 공격자는 남의 도메인 A 레코드를 바꿀 수 없기 때문입니다. 메일 서버들이 스팸 판단에 씁니다. 단, 통과해도 "같은 주인"까지만 증명하며 "안전"은 증명하지 않습니다.

쓰는 법¶

PTR은 힌트로만: 가정용 회선인지, 클라우드인지, Tor인지 감 잡기. 내부망 PTR은 상대적으로 믿을 만합니다.
판단은 WHOIS/RDAP(공식 소유 기관), ASN(네트워크 운영자), Passive DNS(그 IP가 과거에 서비스한 도메인)로 합니다.
[주의] 공격자 IP에 PTR 조회를 하면 질의가 공격자 DNS 서버까지 가서 흔적이 남습니다. 도구의 자동 역방향 조회 기능도 확인합니다.
[주의] 내부 PC가 1.5.0.10, 2.5.0.10... 식으로 PTR을 연속 조회하면 내부 스캔(정찰) 신호입니다. nmap은 기본으로 PTR 조회를 합니다.
예전 8.8.4.4 → google-public-dns-b.google.com은 이후 dns.google로 바뀐 것으로 알고 있습니다. PTR이 바뀐다는 실례입니다.

다대다 매핑과 IP 차단 사고¶

도메인과 IP는 서로 다른 사람이 각자 관리하는 두 개의 지도이고, 두 지도는 따로따로 언제든 바뀝니다.

네 가지 규칙¶

한 도메인 → 여러 IP, 또는 없음. 도메인 주인은 남의 IP도 허락 없이 가리킬 수 있음
여러 도메인 → 같은 IP, 또는 없음. CDN·공유 호스팅은 IP 하나 뒤에 사이트 수천 개(아파트 한 건물에 수백 세대)
IP → 아무 도메인(PTR은 IP 주인 마음대로)
위 모든 것이 언제든 바뀜

실제로 일어나는 사고¶

c703[.]info(악성)가 Google IP를 가리킴 → 분석가가 그 IP를 방화벽 차단 → 회사 전체 Google 차단. 분석가가 틀린 정보를 쓴 게 아니라, "그 IP = 그 도메인 전용"이라고 가정한 것이 실수입니다. 처방: IP나 도메인을 막기 전에 반드시 기록부터 확인한다.

도메인의 [.] 표기는 실수 클릭 방지용 defang 관례입니다. 보고서에 악성 도메인을 쓸 때 사용합니다.
악성 도메인이 127.0.0.1이나 0.0.0.0을 가리키면 무해한 게 아니라 잠복(파킹) 또는 싱크홀일 수 있습니다. 지금도 그 도메인을 조회하는 내부 PC는 지금도 감염된 PC입니다.
과거 사건은 오늘의 답이 아니라 그 당시 기록(우리 DNS 로그, Passive DNS)으로 조사합니다. 조사 노트에는 "몇 시 기준 이 IP"라고 시각을 함께 적습니다.

IP 차단 전 체크리스트¶

이 IP와 통신하는 내부 장비가 몇 대인가 (1~2대면 검토 가능, 수백 대면 금지)
WHOIS/ASN상 주인이 Cloudflare·AWS·Google·Microsoft·Akamai 같은 공유 인프라인가
우리 DNS 기록·Passive DNS에서 같은 IP를 가리키는 다른(정상) 도메인이 있는가
답 IP가 여러 개면 전부 확인했는가, 실제 접속이 일어난 IP는 어느 것인가
IP 대신 도메인 차단(DNS 싱크홀/DNS 방화벽)으로 충분하지 않은가
차단한다면 만료일(30~90일)과 사유(사건 번호, 날짜, 담당자)를 남겼는가

2026년 관점

CDN 확산으로 악성 도메인이 공유 IP 위에 있을 확률이 크게 올랐습니다. 웹 위협에는 IP 차단이 점점 부적합하고, 도메인 차단이 기본입니다.
ECH가 켜지면 네트워크 장비가 같은 IP의 사이트를 이름으로 구분하기 어려워집니다. 확실한 차단 지점은 DNS 단계와 PC(EDR)입니다.
공격자가 GitHub, Google Drive, Telegram 같은 정상 서비스 자체를 통신에 씁니다(Living off Trusted Sites). 도메인도 IP도 진짜라서 행동 패턴으로 잡아야 합니다.
만료일 없는 IP 차단은 6개월 뒤 그 IP가 협력 업체 서버로 재할당될 때 장애를 일으킵니다.
위협 정보 피드 기반 자동 차단(SOAR)에는 주요 클라우드/CDN 대역의 허용 목록과 "내부 통신 장비 수" 자동 확인을 먼저 겁니다.

TXT — 글자를 담는 상자¶

TXT는 도메인에 임의의 텍스트를 붙이는 레코드입니다. 메일 위조 방지와 도메인 소유 증명의 핵심이면서, 공격자의 비밀 통신 수단이기도 합니다.

기본 성질¶

아무 글자나(출력 가능한 ASCII). 바이너리는 base64로 바꿔 넣음
한 이름에 TXT 여러 개 가능
[정정] "255자 제한"은 따옴표 덩어리 하나 기준입니다. 한 레코드에 덩어리 여러 개를 넣고 이어 붙여 읽습니다. 400자 넘는 DKIM 키가 이렇게 들어갑니다.

메일 인증 3종¶

이름	위치	확인하는 것	예
SPF	도메인의 TXT	이 서버가 이 도메인 이름으로 메일을 보내도 되는가	`v=spf1 include:_spf.google.com ip4:203.0.113.10 -all`
DKIM	`<selector>._domainkey.<domain>` TXT	메일 내용이 위조되지 않았는가(전자 서명)	`v=DKIM1; k=rsa; p=MIIB...`
DMARC	`_dmarc.<domain>` TXT	실패 시 처리 정책 + 화면의 From과 도메인 일치(정렬)	`v=DMARC1; p=reject; rua=mailto:...`

SPF 끝 규칙: -all 거부, ~all 의심 표시, ?all 판단 안 함, +all 아무나 허용(최악)
DMARC 정책: none 보고만, quarantine 스팸함, reject 거부. rua 보고서로 우리 도메인 사칭을 볼 수 있음
[정정] "SPF 레코드는 spf=로 시작한다"는 설명은 틀렸습니다. SPF는 v=spf1로 시작합니다.
[보충] DMARC도 꼭 알아야 합니다. 2024년 2월 Google·Yahoo가 대량 발송자에게 SPF+DKIM+DMARC를 의무화했고 Microsoft도 2025년 Outlook.com에 도입했습니다.

SPF/DKIM pass를 읽는 법¶

맞는 것: 허락된 서버에서 보냈고(SPF), 내용이 안 바뀌었다(DKIM)
함정 1: 어느 도메인 기준 pass인지 확인. 공격자의 micros0ft-billing.com도 자기 기준으로 pass
함정 2: SPF는 봉투 주소(Return-Path)를 검사. 화면의 From과 다를 수 있으며, 이 빈틈을 DMARC 정렬이 막음
함정 3: 진짜 계정이 탈취되면(BEC) SPF·DKIM·DMARC가 전부 pass
결론: 인증은 신원을 확인할 뿐 의도를 확인하지 않음

도메인 소유 증명¶

서비스가 준 문자열을 TXT에 넣어 소유를 증명합니다(예: facebook-domain-verification=..., MS=..., google-site-verification=...). [보충] 이 기록들은 회사가 쓰는 SaaS를 공격자에게 노출해 맞춤형 피싱 정찰에 쓰입니다. 다 쓴 서비스의 인증 기록은 지웁니다.

악용 원리¶

아무 내용이나 담을 수 있고, DNS는 거의 항상 열려 있으며, 메일 서버 때문에 TXT 조회가 흔해 의심받지 않습니다. 감염 PC가 cmd.evil-c2.xyz의 TXT를 물으면 base64 명령이 돌아오는 식입니다. 메일 서버가 아닌 일반 PC의 TXT 조회가 많으면 의심합니다(자세한 탐지는 DNS 악용 공격 참고).

CNAME과 서브도메인 탈취¶

CNAME은 "이 이름은 사실 저 이름의 별명이니 저쪽에 물어봐"라고 넘겨주는 레코드입니다. 관리를 소홀히 하면 회사 주소를 공격자에게 빼앗깁니다.

기본¶

A를 물으면 CNAME + 정식 이름의 A가 함께 옵니다(CNAME chasing).
정식 이름(canonical name) = 답에 나온 이름. 물어본 이름은 별명입니다. 시험에서 가장 많이 틀리는 지점입니다.
용도: 여러 이름을 한 서버로 모으기, 그리고 지금은 주로 외부 서비스로 넘기기(shop.mycompany.com → mycompany.myshopify.com).
CNAME이 서로를 가리키면 무한 루프. 실제로는 CDN 때문에 3~4단계 체인이 흔하므로 응답 체인 전체를 봐야 최종 목적지가 보입니다.
일반 PC가 CNAME 타입을 직접 질의하는 것은 드뭅니다(보통 A로 묻고 CNAME은 덤으로 옴).

댕글링 CNAME → 서브도메인 탈취¶

promo.mycompany.com CNAME mycompany-event.herokuapp.com으로 이벤트 페이지 운영
이벤트 종료 후 Heroku 앱은 삭제, DNS의 CNAME은 방치
대상 이름을 조회하면 NXDOMAIN → "이 자리 비었음, 누구나 가져가라"는 신호
공격자가 같은 이름으로 앱 생성 → 진짜 회사 주소에서 공격자 콘텐츠가 뜸(로그인 피싱, 악성 파일, 사기 공지)

주소창의 도메인을 확인하라는 보안 교육으로도 막을 수 없는 이유는, 주소가 진짜이기 때문입니다.

발견했을 때 대응¶

아직 쓰는 서비스인지 담당 부서에 빠르게 확인(며칠씩 미루지 않음)
CNAME 삭제(1순위). 계속 필요하면 우리가 먼저 대상 이름을 재생성해 자리를 차지
다른 CNAME 중 이미 탈취된 것(정상 응답인데 우리가 만든 적 없는 내용)이 있는지 확인
외부 서비스를 가리키는 CNAME 전수 점검: *.azurewebsites.net, *.cloudapp.azure.com, *.herokuapp.com, *.s3.amazonaws.com, *.github.io, *.myshopify.com
절차 규칙: 서비스를 없앨 때는 DNS를 먼저 지우고 그 다음 서비스를 지운다

클라우드 업체들이 TXT 기반 소유 확인 같은 보호 장치를 추가해 왔지만, 모든 서비스·설정에 적용되는지는 확실하지 않으므로 우리 쪽 정리가 확실한 방어입니다. 이 점검을 자동화하는 제품군을 EASM(외부 공격 표면 관리)이라고 합니다.

2026년 관점

클라우드·SaaS 확산으로 서브도메인 탈취는 몇 년 전보다 훨씬 흔해졌습니다.
CNAME은 도메인 꼭대기 이름(mycompany.com)에 쓸 수 없는데, HTTPS/SVCB 레코드의 AliasMode가 이 한계를 메웁니다.
광고·추적 업체가 metrics.mycompany.com 같은 자사 주소로 위장해 CNAME으로 외부에 넘기는 CNAME cloaking도 있습니다. "회사 주소 = 회사 서버"가 아닐 수 있습니다.

MX, SRV, NS¶

셋 다 개념은 단순하지만 각각 보안 위험이 하나씩 붙어 있습니다. MX는 메일 가로채기, SRV는 내부 정찰, NS는 도메인 전체 탈취입니다.

MX — 메일 담당 서버¶

메일 전송 3단계: 받는 도메인의 MX 조회 → 그 이름의 A 조회 → 그 IP의 25번 포트로 SMTP 전송
앞의 숫자는 우선순위, 작을수록 먼저. 같으면 분산
MX는 반드시 A/AAAA가 있는 FQDN을 가리킴. IP 직접 기재 금지, CNAME 금지
[정정] 자주 인용되는 RFC 974는 RFC 5321로 대체됨(규칙 내용은 동일)
보안 단서: 일반 PC의 대량 MX 조회 = 스팸봇 의심 / 피싱 도메인의 MX로 의도 파악(없음 = 클릭 목적, Gmail·Outlook = 답장 노림, 자체 서버 = 인프라 단서) / 우리 MX 변경 = 메일 가로채기 비상
[보충] 메일을 안 쓰는 도메인은 Null MX(MX 0 ., RFC 7505) + v=spf1 -all + DMARC p=reject로 사칭을 막음

SRV — 서비스 위치¶

형식 _service._proto.name (밑줄로 일반 호스트 이름과 구분)
답: 우선순위 가중치 포트 대상 예: 0 100 389 dc01.corp.local. — 포트까지 알려줌
AD 핵심 질의: _ldap._tcp.dc._msdcs.<domain>(도메인 컨트롤러), _kerberos._tcp.<domain>(인증), _gc._tcp.<domain>(Global Catalog)
SRV 질의는 내부망에서만 보여야 함 → 외부로 나가면 내부 도메인 이름 누출
정찰 신호: 짧은 시간에 여러 종류를 몰아서 조회, 새벽 시간, 평소 안 하던 장비(복합기·서버), 이상한 프로세스. 단 복합기도 스캔-투-이메일 주소록 때문에 LDAP는 정상적으로 쓸 수 있으므로 평소 기록(baseline)과 비교가 필수
복합기·IP 카메라 같은 사무 기기는 패치가 느리고 EDR이 없어 공격자의 발판으로 쓰임

NS — 정답을 가진 서버의 이름¶

NS는 두 곳에 저장: 위층 TLD 서버의 안내 사본(도메인 판매 업체 사이트에서 입력) + 권한 서버의 원본
이유: 담당 서버를 모르면 담당 서버에 물어볼 수 없는 닭과 달걀 문제. 위층 사본이 길을 알려줌
둘이 다르면 lame delegation(간헐적 해석 실패의 원인)

도메인 하이재킹 (NS 탈취)¶

NS를 공격자 서버로 바꾸면 A·MX·TXT 전부를 공격자가 통제합니다. TXT로 소유 증명을 통과해 회사 이름의 정식 HTTPS 인증서까지 발급받을 수 있습니다. 주 경로는 해킹이 아니라 도메인 판매 업체(registrar) 계정 탈취입니다. 실제 사례로 2018~2019년 Sea Turtle, DNSpionage 캠페인이 정부·통신사 도메인을 노렸습니다. 2024년에는 주인 없는 DNS 서비스 계정을 가로채는 "Sitting Ducks" 유형도 발표됐습니다.

사고 후 대응 순서:

되찾기: 판매 업체 계정에서 NS 원상복구. 로그인이 안 되면 업체 긴급 창구 연락(연락처는 평소에 확보)
잠그기: 비밀번호 변경, 모든 세션 종료, MFA, Registry Lock, 계정 연락처 이메일 변조 여부 확인
버티기: NS TTL(예: 172800초 = 2일) 동안은 복구 후에도 일부가 공격자 서버로 감
피해 찾기: crt.sh(Certificate Transparency)에서 무단 발급 인증서 확인·폐기, 그 기간 메일과 비밀번호 재설정 메일이 가로채졌다고 가정하고 주요 계정 점검
알리기: 고객·거래처·직원에게 해당 기간 요청(특히 계좌 변경) 재확인 안내

예방: 판매 업체 계정 MFA, Registry Lock, NS·MX·SPF 변경 감시 알람, DNSSEC(계정을 빼앗기면 무력하므로 단독으로는 부족). 서비스 해지 시 DNS 안내판부터 정리합니다. 사고 전 첫 조치는 MFA, 사고 후 첫 조치는 되찾기입니다.

패킷 읽기 — DNS on the Wire¶

A, CNAME, PTR 질의 세 쌍이 섞인 캡처를 읽어 봅니다(PC IP와 Transaction ID는 예시 값).

No. Source         Destination    Info
1   192.168.1.156  1.1.1.1        Standard query 0x1a2b A example.com
2   1.1.1.1        192.168.1.156  Standard query response 0x1a2b A example.com A 1.2.3.4 A 162.255.119.240
3   192.168.1.156  1.1.1.1        Standard query 0x3c4d CNAME mail.google.com
4   1.1.1.1        192.168.1.156  Standard query response 0x3c4d CNAME mail.google.com CNAME googlemail.l.google.com
5   192.168.1.156  1.1.1.1        Standard query 0x5e6f PTR 27.208.194.173.in-addr.arpa
6   1.1.1.1        192.168.1.156  Standard query response 0x5e6f PTR 27.208.194.173.in-addr.arpa PTR ql-in-f27.1e100.net

읽는 요령¶

query = 질문, query response = 대답. 대답 줄에는 질문이 반복된 뒤 답이 붙음
번호표(0x...)가 같으면 한 쌍
대답 줄에서 종류 글자가 나올 때마다 답 하나(2번 줄의 A 세 개 = 질문 1 + 답 2)
Wireshark 필터: dns, dns.flags.response == 0(질문만), dns.qry.type == 12(PTR만)

문제와 답¶

문제	정답	포인트
1. A로 조회된 도메인	`example.com`	질문 패킷에서 종류 글자 바로 뒤
2. 해석된 IP	`1.2.3.4`, `162.255.119.240`	두 개. 하나만 쓰면 오답. `1.2.3.4`는 예시용 값 → 도메인 주인은 아무 IP나 적을 수 있음
3. Google 메일 호스트의 정식 이름	`googlemail.l.google.com`	정식 이름 = 답에 나온 이름
4. PTR로 조회된 IP	`173.194.208.27`	옥텟 순서 뒤집기
5. 사용된 DNS 서버	`1.1.1.1`(Cloudflare)	질문의 목적지. 단 이 캡처는 PC~1.1.1.1 구간만 보여줌
6. (보너스) 회사 PC라면 문제점	회사 DNS를 우회해 외부 DNS 직접 사용	기록 안 남음, 도메인 차단 무력화, 내부 이름 누출. 53번 외부 직행 차단 + 시도 알람. DoH면 이 캡처처럼 보이지도 않음

MX → A → PTR 조사 흐름¶

문제 4의 IP는 gmail.com MX → gmail-smtp-in.l.google.com → A 173.194.208.27 → PTR ql-in-f27.1e100.net에서 나왔습니다. 정방향과 역방향 이름이 다르다는 점도 "PTR을 믿지 마라"의 실례입니다. 피싱 메일 발송 서버가 진짜인지 확인할 때 이 순서(MX → A → 헤더의 발송 IP와 비교)를 그대로 씁니다.