수상한 DNS 기록 판별표 · 정정 · 헷갈리는 포인트¶
이 페이지에서 다루는 것
DNS 기록 한 줄을 받았을 때 무엇을 어떤 순서로 보는지 정리한 실무 참고표, 흔히 틀리게 알려졌거나 최근 바뀐 부분, 복습하면서 실제로 헷갈렸던 포인트.
표기
[보충] = 꼭 알아야 할 실무 보충, [정정] = 흔히 잘못 알려진 내용 정정, [변경됨]/[주의] = 최근 바뀐 점과 옛 방식대로 하면 위험한 점. 전체 흐름은 DNS 개요에서, 기록 한 줄을 판별하는 순서는 판별표에서 볼 수 있습니다.
수상한 DNS 기록 판별표¶
DNS 기록 한 줄을 받았을 때 무엇을 어떤 순서로 보는지 정리한 참고표입니다. DNS 파트 전체 내용을 칸별로 모았습니다.
0. 판별 전: 기록을 믿을 수 있나¶
- 질문자가 진짜 PC인가(센서가 회사 DNS 서버 위쪽만이면 전부 DNS 서버 IP)
- 응답 IP까지 기록되나
- TTL·결과 코드 칸이 살아 있나
- 회사 DNS 우회(외부 53번 직행, DoH)도 보이나
- 보관 기간이 과거 사건 조사에 충분한가
1. 판단 원칙¶
- 강한 신호 하나, 또는 약한 신호 여러 개
- 나쁜 평가는 증거, 좋은 평가는 증거 아님
- 주장과 출처가 맞는가
- 도메인은 오른쪽부터, 등록 도메인으로 주인 판단
- 평소(baseline)와 비교
- "지금"이 아니라 "그때" 기준
2. 칸별 판별¶
A. 질문한 이름(도메인)
| 신호 | 강도 | 요령 / 흔한 오탐 |
|---|---|---|
| 위협 정보 정확 일치 | 강 | 일치하면 판단 끝 / 목록에 잘못 들어간 공유 도메인 |
| 등록 도메인 자체가 무작위 | 강~중 | DGA 의심 / Punycode는 풀어서 확인 |
| 하위 이름만 무작위 | 대개 정상 | 등록 도메인 기준 재판단 / CDN·클라우드. 단 DDNS·호스팅 플랫폼(duckdns.org, pages.dev 등)은 하위 이름마다 주인이 달라 하위 이름이 등록 단위 → 무작위면 의심 |
| 하위 이름이 비정상적으로 길고 무작위 | 중 | 터널링 의심. 등록 도메인부터 확인(백신 평판 조회 sophosxl.net 등 정상 오탐). 회사 DNS 서버에서 탐지 후 등록 도메인 차단 |
| 브랜드 이름을 끼워 넣음 | 강~중 | 등록 도메인이 브랜드 소유가 아님 |
Punycode(xn--) |
풀어봐야 앎 | 유명 브랜드 흉내면 강 / 정상 비영어 도메인 |
| 최근 등록(7/30/90일) | 약~중 | 새 정상 사업체 |
| 오래됐는데 최근 깨어남 | 중 | Updated Date·등록 업체·NS 변경, Passive DNS 공백 후 재활동, 첫 인증서 최근 |
| 우리 조직에서 처음 봄 | 약 | 다른 탐지의 보조 / 새 업무 서비스 |
저가 TLD, .zip/.mov |
약 | Public Suffix List로 쪼개기 |
| 무료 호스팅 하위 주소 | 약~중 | 하위 주소 단위로 판단 |
| 평판 악성·중간 위험 이상 | 강 | 빠른 판정 |
| 평판 미분류 | 약 | 신규 또는 방문 적음 |
| 평판 안전 | 근거 아님 | 바꿔치기·해킹·플랫폼·만료 재구매·클로킹 |
| 비정상적으로 긴 이름 | 약 | 예외 존재(웨일스 마을) |
A칸 추가: IANA 공식 TLD 목록에 없는 TLD(.bazar, .emc, .lib, .eth 등) 조회는 강한 신호. NXDOMAIN이어도 PC 안에 악성코드가 있다는 증거. 예외: 내부 이름(.local, .corp, .lan), 오타, 점 없는 한 단어. 블록체인 게이트웨이 도메인(eth.limo, ipfs.io, dweb.link 등)은 공식 TLD라 별도 목록으로 관찰·차단. E칸 추가: 업무와 무관한 PC·프로그램의 블록체인 노드 API 조회 후 DNS 없이 IP 직접 접속 = EtherHiding 의심.
A칸 추가: xn--로 시작하는 덩어리가 있으면 IDN → 반드시 풀어서 확인. 문자 체계가 섞임(라틴 + 키릴·그리스·체로키 등) = 강한 신호, 풀었을 때 유명 브랜드·우리 도메인과 비슷하면 강한 신호(같은 라틴 체계의 ɡ, ḟ 같은 글자도 있으니 브랜드 비교 필수). 퓨니코드 두 번째 부분과 브랜드를 비교해 빠진 글자 = 바꿔치기 자리. 한 문자 체계의 자연스러운 이름(한국.kr)은 대개 정상.
B. 질문 종류(레코드 타입)
| 패턴 | 의심 | 정상인 경우 |
|---|---|---|
| 일반 PC의 TXT 비중 높음 | 명령 수신, 터널링 | 메일 서버 |
| 일반 PC의 MX 대량 조회 | 스팸봇 | 메일 서버 |
SRV(_ldap·_kerberos·_gc) 몰아서 |
내부 정찰 | 부팅·로그인 시 몇 건, 복합기 주소록 LDAP |
| PTR을 IP 순서대로 연속 | 내부 스캔(nmap) | — |
| CNAME 타입 직접 질의 | 사람이 조사 도구 사용 | 관리자 작업 |
| A·AAAA 쌍, HTTPS(65)/SVCB(64) | 정상 | 파서가 65를 모르면 오탐 |
B칸 추가: NULL(10) 타입은 정상 프로그램이 거의 안 쓰므로 등장 자체가 강한 터널링 신호(iodine 기본). 터널링 판별은 "한 출발지 × 한 등록 도메인"의 고유 하위 이름 수와 질문량을 며칠~몇 주 누적해서 봄. 오탐: 백신 조회(sophosxl.net), DNSBL(zen.spamhaus.org), CDN, Chrome 하이재킹 테스트(점 없는 무작위 한 단어 + NXDOMAIN).
C. 응답 내용
| 패턴 | 의심 | 요령 |
|---|---|---|
| NXDOMAIN 폭증(서로 다른 도메인 대부분) | DGA | 무작위 이름과 겹치면 거의 확정. 사전 단어 DGA도 이 흔적은 남김 |
127.0.0.1/0.0.0.0 |
잠복 C2, 싱크홀 | 무해 아님. 지금도 조회하는 PC = 지금도 감염 |
| 짧은 TTL + IP가 계속 바뀜 | Fast Flux | 짧은 TTL 혼자는 CDN과 구분 불가 |
| 답 IP 여러 개 | 정상 가능 | 전부 기록·조사, 실제 접속 IP는 방화벽으로 |
| CNAME 체인 | 정상 가능 | 끝까지 보고 최종 목적지 판단 |
D. 응답 IP
| 덧붙일 것 | 요령 | 주의 |
|---|---|---|
| 위협 정보 | C2 등록이면 강 | 공유 IP면 IP 평판 약해짐 |
| ASN 이름 | 주장과 출처가 맞나(브랜드 또는 그 브랜드의 CDN) | 대형 회사는 CDN 배포 |
| ASN 종류 | 사람 계정 로그인이 호스팅 ASN이면 수상 | 가정용 프록시로 위장 |
| 공유 IP 여부 | 공유면 IP 차단·IP 피벗 부적합. "IP 뒤에 몇 개?"는 PTR이 아니라 역방향 IP 조회(Passive DNS). 작은 호스팅 ASN이면 기록 확인 후 IP 차단 가능, CDN·클라우드면 금지 | 도메인 단위로 |
| 위치 | 방향·프로토콜로 쪼개기(웹 무시, SSH·FTP 주목) | 추정치. IP 위치 ≠ 공격자 위치 |
E. 질문한 장비와 맥락
| 볼 것 | 요령 |
|---|---|
| 장비 역할 | 역할에 맞는 조회인가. 사건 시각 기준 DHCP 매핑 |
| 프로그램 | Sysmon Event ID 22. chrome.exe vs Temp\update.exe |
| 시간대 | 근무 시간 vs 새벽 |
| 직전 몇 초 | 출발점(연 사이트)이 있나, 광고에서 파생됐나 |
| 다른 PC 수 | 한 대뿐이면 표적·감염, 수십 대면 정상 서비스 가능성 |
| 그다음 | 실제 접속, 지속 시간, 전송량 |
| 평소와 비교 | 매일 같은 시간이면 예약 작업일 수 있음 |
F. 경로
| 패턴 | 의미 |
|---|---|
| 일반 PC가 외부 DNS에 53번 직접 질의 (목적지 IP 칸으로 찾음) | 기록·차단 우회. 정책 위반·설정 오류·악성코드. 이름이 평범해도(연결 확인) 의심 |
| 외부 DNS로 Google·Microsoft 조회 직후 다른 곳 조회·접속 | 악성코드의 연결 확인 → 그다음이 진짜 목적지 |
| 방화벽의 외부 53번 차단(deny) 기록, PC 방화벽 Event ID 5157 | 막혔어도 그 PC·그 프로그램은 조사 대상 |
| 853번(TCP DoT / UDP DoQ) 외부 연결 | 암호화 DNS로 우회 |
| 알려진 공개 DoH 서버로의 443 연결 | DoH 우회. 브라우저면 정책 위반, 브라우저가 아닌 프로그램(EDR로 확인)이면 악성코드 강한 의심. 업무 PC의 SSLKEYLOGFILE 설정도 조사 대상 |
| 회사 DNS 질의가 사라졌는데 웹 접속은 계속 | DoH 가능성 |
| 53이 아닌 포트로 DNS 형식 트래픽 | 우회 시도 |
PC의 DNS 서버 설정(레지스트리 NameServer) 변경 — Sysmon Event ID 13 |
트래픽 전에 잡는 신호. 모든 프로그램이 공격자 DNS를 쓰게 됨 |
| hosts 파일 변경 — Sysmon Event ID 11·FIM | DNS 질의 자체가 안 생겨 네트워크·DNS 기록에 흔적 없음 |
| 내부 도메인 이름이 외부 DNS로 | 내부 정보 누출, 설정 오류 |
| 우리 DNS 서버의 질의 출발지 포트 고정 | 캐시 포이즈닝 취약 |
주의: 정상 예외(DNS 고정 IoT·스트리밍 기기, 일부 VPN·개발 도구)는 기록 기간에 목록화. 외부 53번 차단으로도 회사 DNS를 정상적으로 거치는 터널링은 못 막음(A·B칸 패턴으로 탐지). 재택 PC는 집 공유기 DNS 변조도 고려.
3. 우리 도메인 자체의 이상(정기 점검·변경 감시)¶
| 이상 | 의미 | 대응 |
|---|---|---|
| NS 변경 | 도메인 전체 탈취 | 되찾기 → 잠그기 → TTL 동안 버티기 → 무단 인증서·가로챈 메일 확인 → 알리기 |
| MX 변경 | 메일 가로채기 | 즉시 원복, 계정 점검 |
| 외부 CNAME 대상이 NXDOMAIN | 서브도메인 탈취 직전 | CNAME 삭제, 전수 점검 |
| 쓰지 않는 서비스 인증 TXT | SaaS 노출 | 정리 |
추가: DNS 관리자 계정이 뚫렸을 때의 이상
| 이상 | 의미 | 대응 |
|---|---|---|
| 우리 도메인에 목록에 없는 새 하위 이름 | 도메인 섀도잉(우리 평판에 올라탐) | 레코드 목록 관리 + 새 레코드 경보, 계정 점검 |
| 우리 서비스(VPN 등) A 레코드가 낯선 IP로 | 레코드 바꿔치기(복제 로그인 페이지로 비밀번호 탈취) | 즉시 원복, 계정 MFA·세션 종료 |
| crt.sh에 우리가 발급한 적 없는 우리 도메인 인증서 | DNS 통제로 TXT 소유 증명 → 진짜 인증서 발급 | 인증서 폐기, 레코드·계정 조사 |
| DNS 관리자 계정의 낯선 로그인·설정 변경 알림 | 모든 변조의 출발점 | MFA, Registry Lock |
4. 판별 흐름¶
- 기록 품질 확인
- 칸으로 쪼개기(시각·장비·도메인·타입·응답·IP·TTL)
- 강한 신호 먼저(위협 정보, 평판 악성)
- 덧붙이기: 누가·무엇을·어디로·왜/그다음
- 약한 신호가 몇 개 겹치나
- 흔한 오탐 대조
- 확인은 OPSEC 순서: 우리 기록 → 외부 Passive DNS → 비귀속 환경 새 조회
- 판정·대응: 확실한 것은 확실하게, 모르는 것은 모른다고
흔한 오탐: CDN 무작위 하위 이름, A·AAAA 쌍, 웹페이지 하나의 수십 건 조회, HTTPS(65) 질의, 짧은 TTL, 정상 Punycode, 복합기 LDAP, 메일 서버의 TXT·MX, VPN으로 인한 불가능한 이동, 경보에 찍힌 회사 DNS 서버.
하지 말 것: 회사 PC에서 의심 도메인 nslookup, PTR로 주인 단정, in-addr.arpa 안 뒤집고 검색, 공유 IP 차단, 의심 파일 VirusTotal 업로드, 피싱 URL 공개 스캔, "해외 차단 = 해외 공격 차단"이라고 믿기.
5. 2026년 판별을 어렵게 하는 것¶
| 변화 | 영향 | 대응 |
|---|---|---|
| DoH 기본값화 | 회사 DNS 기록·53번 감시에 안 보임 | 브라우저 정책 |
| ECH | 사이트 이름(SNI) 안 보임 | DNS·PC 기록 가치 상승 |
HTTPS 레코드 ipv4hint |
A 질의 없이 접속 | "DNS 없는 연결" 규칙 재검토 |
| 사전 단어 DGA | 무작위성 검사 통과 | NXDOMAIN·나이·조회 패턴과 겹쳐 봄 |
| 무료 호스팅 플랫폼 | 상위 평판 최고 등급 | 하위 주소 단위 판단 |
| 클로킹 | 평판 서비스엔 정상 화면 | 메일 맥락 우선 |
| 숙성·만료 재구매 | 나이 신호 회피 | 최근 변경·NS·재활동 확인 |
| 가정용 프록시 | 위치·ASN 정상으로 보임 | 피싱에 강한 MFA, 관리 기기 조건 |
| PC 기록 중요성 | 네트워크로 안 보이는 것 증가 | Sysmon 22·EDR(브라우저 자체 DoH는 Sysmon 22에도 안 잡힐 수 있음) |
흔한 오해 정정과 2026년 업데이트¶
DNS의 원리는 하나도 낡지 않았습니다. 아래는 흔히 틀리게 설명되거나 환경이 바뀐 부분만 모은 것입니다.
| 구분 | 흔한 설명 / 예전 상황 | 2026년 현재 |
|---|---|---|
| 정정 | "Linux does not cache answers by default" | systemd-resolved가 캐시함(resolvectl show-cache). macOS도 캐시. 3대 OS 모두 캐시 있음 |
| 정정 | "SPF TXT records start with spf=" | v=spf1로 시작 |
| 정정 | TXT "255-character limit" | 문자열 덩어리 하나 기준. 여러 덩어리를 이어 붙임 |
| 정정 | MX 규칙 근거 RFC 974 | RFC 5321로 대체(규칙 내용 동일) |
| 정정 | 8.8.4.4의 PTR = google-public-dns-b.google.com |
현재 dns.google로 바뀐 것으로 앎(PTR이 바뀐다는 실례) |
| 정정 | DoH "JSON encoded" | 표준 DoH는 application/dns-message, JSON은 비표준 API |
| 신규 | 기본 레코드 타입만 알면 됨 | HTTPS(65)·SVCB(64), RFC 9460(2023-11). 지금 매우 흔함 |
| 신규 | SNI로 사이트 이름 확인 가능 | ECH(RFC 9848·9849, 2026-03). 이름 암호화 → DNS 기록 가치 상승 |
| 변경 | DoH는 아직 드문 기술 | 브라우저 기본값에 가까움. 53번만 감시하면 놓침 |
| 변경 | SPF + DKIM | SPF + DKIM + DMARC 필수(2024 Google·Yahoo, 2025 Microsoft) |
| 변경 | 공유 IP 사고 경고 | CDN 확산으로 웹 위협에 IP 차단 점점 부적합. 도메인 차단이 기본 |
| 변경 | Alexa Top 1M | 2022년 종료 → Tranco, Cisco Umbrella, Cloudflare Radar |
| 변경 | OpenNIC이 EmerDNS를 해석 | 2019년경 연결을 끊은 것으로 알려짐 |
| 변경 | 무료 TLD .tk·.ml | Freenom이 2023년 신규 등록 중단 |
| 보충 | — | 서브도메인 탈취(댕글링 CNAME) |
| 보충 | — | 도메인/NS 탈취, 주인 없는 DNS 계정(Sitting Ducks, 2024) |
| 보충 | — | 정상 서비스를 통신에 쓰는 공격(Living off Trusted Sites) |
| 보충 | DNS 수집 = 서버 기록 + 네트워크 추출 | 세 번째 축으로 PC 기록(Sysmon, EDR)의 중요성 상승 |
그대로 유효한 것: 계층 구조, 위임, 캐시와 TTL, 레코드 의미, 다대다 매핑, "PTR을 믿지 마라", "막기 전에 확인하라".
자주 헷갈리는 포인트¶
복습 문제를 풀면서 실제로 나온 혼동들입니다. 시험과 보고서에서 용어를 정확히 써야 조사 방향이 틀어지지 않습니다.
| 헷갈린 것 | 정확한 이해 |
|---|---|
| A 레코드 vs PTR 레코드 | 이름을 넣었으면 A, IP를 넣었으면 PTR. 도메인이 127.0.0.1을 가리키게 바뀐 것은 도메인 주인(공격자)이 A를 바꾼 것 |
| PTR 결과 검증 방법 | 역방향을 또 하는 게 아니라 그 이름을 정방향(A)으로 조회해 원래 IP가 나오는지 확인(FCrDNS). 보고서엔 "FCrDNS를 확인했다"로 씀 |
| 정식 이름(canonical name) | 물어본 이름이 아니라 답에 나온 이름 |
| PTR 뒤집기 | 옥텟(덩어리) 단위로 뒤집음. 덩어리 안 숫자는 그대로. IPv6만 글자 단위 |
| SPF/DKIM pass = 진짜 메일? | 어느 도메인 기준인지, 화면 From과 정렬되는지(DMARC), 계정 탈취 가능성까지 봐야 함. 인증 ≠ 선의 |
| NS 탈취 시 첫 조치 | 사고 후 첫 조치는 NS 원상복구(되찾기). MFA는 그 다음 잠그기 단계. 대상은 DNS 서버가 아니라 도메인 판매 업체 계정 |
| 질의가 많다 = 감염? | 웹페이지 하나에 수십 개가 정상. 숫자가 아니라 내용·패턴·프로세스·시간대로 판단 |
| 오늘 조회 결과로 과거 판단 | 금지. 그 당시 기록(우리 DNS 로그, Passive DNS)으로 조사 |
127.0.0.1 응답 = 무해? |
잠복일 수 있음. 지금도 조회하는 PC = 지금도 감염된 PC |
| 포워딩 서버의 목적지 IP = 답을 아는 서버? | 아님. 뒤에서 다시 물어봤을 수 있음. 캡처 위치가 보이는 범위를 결정 |
탐지·공격 파트에서 추가로 나온 혼동:
| 헷갈린 것 | 정확한 이해 |
|---|---|
| 출구 센서를 두면 질문자가 보인다? | NAT 안쪽에 둬야 진짜 PC IP가 보임. 바깥쪽이면 회사 공인 IP 하나로 뭉침 |
| 53번 외부 차단이면 우회 DNS 끝? | DoH(443)는 센서·차단 모두 우회. 브라우저 정책으로 막아야 함 |
| 피벗 시간 범위는 조회 직후 몇 초만? | 캐시 때문에 다른 PC는 DNS 질문 없이 TTL 동안 접속 가능. 범위를 TTL만큼 넓히면 숨은 감염 PC까지 찾음 |
| 직접 조회의 문제는 들키는 것뿐? | 들킴 + 지금 답 ≠ 그때 답 + 우리 기록 오염, 세 가지 |
| 덧붙이기(보강)에 뭘 붙이나 | 누가(PC) · 무엇을(도메인) · 어디로(IP) · 왜/그다음(맥락) |
| 등록 도메인 읽기 | 오른쪽부터, 공용 접미사 바로 앞 덩어리까지. 앞부분은 장식 |
| "가능성이 높다" vs "확실하다" | 도메인 구조로 판단되는 것은 사실이므로 단정. 확인 안 된 것만 가능성으로 |
| 평판 "안전" = 오탐? | 좋은 평판은 증거가 아님. 바꿔치기·해킹·플랫폼·만료 도메인·클로킹 |
| 생성일이 오래됨 = 오래 같은 주인? | WHOIS/RDAP는 현재 한 장. Updated Date·등록 업체·NS 변경·Passive DNS 공백을 봄 |
.bazar NXDOMAIN = 실패했으니 무사? |
조회 자체가 PC 안 악성코드의 증거. 다른 경로로 재시도했을 수 있음 |
"xn-- 전부 차단" |
정상 다국어 사이트를 막음. 문자 체계 섞임 + 브랜드 비교로 |
| DNSSEC으로 엿보기·하이재킹 방지? | 암호화를 안 하고, 판매 업체 계정이 뚫리면 무력 |