[정보보안기사] 3. 애플리케이션 보안 - (1) DNS 아키텍처와 공격 기법/대응 방안

 

1. 애플리케이션 보안 - DNS 아키텍처와 공격 기법/대응 방안

1.1. DNS 컴포넌트 구조 및 질의 메커니즘

(1) DNS 서버의 역할에 따른 분류 및 동작 차이

- 요약 키워드: 캐싱 전용, Recursive Server, Authoritative Server, 질의 전송 주체

- 이론 상세 내용 및 아키텍처 차이:

DNS 네임서버 체계는 클라이언트의 질의 요청을 대리 수행하는 컴포넌트와 실제 도메인 자원 레코드를 물리적으로 관리하는 컴포넌트로 명확히 분리됩니다.

• Recursive DNS Server (재귀적 네임서버 / 캐싱 전용 서버): 클라이언트(Resolver)로부터 최초 질의를 접수받아 최종 IP 주소를 찾아줄 때까지 인터넷 루트 서버부터 단계를 거쳐 대리 질의(재귀적 질의)를 수행하는 주체입니다. 일반 사용자가 PC 설정에 등록하는 통신사 DNS(예: 168.126.63.1)가 이에 해당하며, 부하 감소를 위해 한 번 획득한 도메인 정보를 일정 시간 보관하는 캐싱 기능을 수행합니다.
• Authoritative DNS Server (권한 있는 네임서버): 특정 도메인 존(Zone)의 마스터 데이터 레코드를 물리적인 파일 형태로 보유하고 신뢰성 있는 응답을 제공하는 실제 원본 네임서버입니다. 도메인 등록 시 지정하는 웹호스팅사나 기관 전용 네임서버가 여기에 속하며, 자신이 직접 관리하지 않는 도메인 영역에 대해서는 답변하지 않고 모르는 요청에 대해서는 에러를 반환합니다.

💡 참고: 전반적인 DNS 질의 구조 요약

클라이언트가 도메인 주소를 요청하면 Recursive 서버가 가동되어 [Root 네임서버] -> [TLD(Top Level Domain) 네임서버] -> [최종 Authoritative 네임서버] 순으로 단계별로 질의를 전송하며 정보를 추적하는 반복적 질의(Iterative Query) 과정을 거쳐 최종 매핑 IP를 획득합니다.

(2) 호스트 진단 질의 우선순위 및 로컬 해석 매커니즘

- 요약 키워드: 질의 우선순위, hosts, dns 캐시, hosts.ics, 인터넷 연결 공유

- 이론 상세 내용 및 운영체제별 해석 흐름:

운영체제가 사용자가 입력한 문자열 도메인을 IP로 변환하기 위해 로컬 내부 자원과 외부 네트워크 쿼리를 타는 순서는 커널 단에 정적으로 규정되어 있습니다.

1. 1순위 - 로컬 DNS 캐시 (DNS Cache Memory): 운영체제가 직전에 성공했던 도메인 변환 결과를 메모리 버퍼에 임시 적재해 둔 공간입니다. 외부 네트워크 카드로 물리적인 패킷을 송출하기 전 메모리를 먼저 탐색하므로 불필요한 네트워크 대역폭 낭비와 지연 시간을 줄입니다.
2. 2순위 - hosts 파일: 관리자가 수동으로 IP와 도메인을 하드코딩 매핑해 놓은 정적 텍스트 파일입니다. 리눅스는 /etc/hosts, 윈도우는 C:\Windows\System32\drivers\etc\hosts 경로에 위치합니다.
3. 3순위 - hosts.ics 파일 (윈도우 전용): 윈도우 운영체제의 ICS(Internet Connection Sharing, 인터넷 연결 공유) 기능을 활성화했을 때 시스템이 임의로 생성하여 제어하는 특수 정적 파일입니다. PC가 일종의 소형 가상 라우터(DHCP 서버 역할)가 되어 핫스팟이나 내부 가상 머신(VM)에 사설 IP를 할당할 때, 연결된 하위 단말들의 도메인 이름을 동적으로 바인딩 관리하는 독립적 우선순위 영역입니다.
4. 4순위 - 외부 DNS 서버 질의: 로컬 내부 자원(캐시, hosts)에서 모두 매핑 정보를 찾지 못했을 때 비로소 네트워크 카드를 통해 외부 설정 네임서버(resolv.conf 등)로 UDP 53번 패킷을 송출하여 질의를 시작합니다.

1.2. DNS 악용 스푸핑 공격 및 취약점 진단

(1) 파밍(Pharming) 공격의 메커니즘 분석

- 요약 키워드: 범죄 수법, 유도, 개인정보를 훔치는, 정상 사이트를 입력하여도, 피싱과 유사, hosts 파일 또는 DNS를 조작

- 이론 상세 내용 및 단계별 대응방안:

파밍(Pharming)은 사용자가 브라우저 주소창에 정확한 정상 사이트 주소를 입력하여도, 공격자가 미리 심어둔 악의적인 변조 기법에 의해 해커가 구축해 놓은 가짜 위조 사이트로 강제 유도되어 금융 정보나 개인정보를 훔치는 고도의 사기 범죄 수법입니다. 외형상 속임수를 쓰는 피싱과 유사하지만, 사용자가 주소를 완벽하게 맞게 입력해도 변조된 결과값으로 인해 유도당한다는 점에서 기술적 차이가 큽니다.

• 공격 구현 매커니즘: 악성코드를 동원해 사용자 로컬 PC 내부의 hosts 파일을 직접 조작하여 정상 도메인에 가짜 IP를 바인딩하거나, 공유기 및 로컬 시스템의 DNS 서버 설정 주소 자체를 해커가 장악한 위조 DNS 서버로 강제 변경하여 동작을 조작합니다.
• 대응방안 가이드:
  • 로컬 hosts 파일의 쓰기 권한을 제한(읽기 전용 속성 부여)하고 보안 솔루션을 통해 상시 변조 모니터링을 수행합니다.
  • 사이트 접속 시 신뢰할 수 있는 기관에서 발급한 SSL/TLS 인증서가 정상 적용되어 있는지 브라우저 경고를 확인하여 최종 위장 사이트 여부를 식별합니다.

(2) 로컬 캐시 진단 명령어 및 DNS TTL 분석

- 요약 키워드: ipconfig, displaydns, flushdns, Time To Live, 캐시 유효기간

- 명령어 및 필드 분석:

윈도우 환경에서 로컬 메모리에 상주하는 가상 DNS 캐시 테이블을 관리하는 핵심 관리 명령어 스펙입니다.

• ipconfig /displaydns: 현재 로컬 PC 메모리 버퍼에 적재되어 있는 모든 DNS 캐시 엔트리 정보(도메인명, 레코드 유형, 매핑 IP)를 텍스트 형태로 화면에 출력하여 상시 확인이 가능한 진단 명령어입니다.
  

  

• ipconfig /flushdns: 현재 메모리에 적재된 로컬 DNS 캐시 레코드를 강제로 전부 초기화(삭제)하는 명령어로, 변조되거나 오염된 캐시 정보를 제거할 때 실무에서 필수 활용됩니다.

💡 참고: DNS TTL (Time To Live)의 기술적 의미

TTL은 권한 있는 네임서버가 특정 레코드 정보를 전달할 때 헤더에 심어 보내는 초(Second) 단위의 캐시 유효 수명을 의미합니다. Recursive DNS 서버나 로컬 PC는 이 TTL 시간 동안만 해당 정보를 캐시에 보관하며, 설정된 시간이 지나 0이 되면 데이터의 정무적 신뢰성을 위해 캐시에서 자동 삭제하고 다음 요청 시 생으로 원본 네임서버에 재질의하게 됩니다.

(3) DNS 캐시 포이즈닝 vs DNS 스푸핑 메커니즘 비교

- 요약 키워드: 조작된 쿼리, 주소 정보를 변조, Transaction ID, 목적지 포트, 정상 응답보다 빠르게, 레이스 컨디션

- 이론 상세 내용 및 공격 원리 비교:

두 공격 모두 사용자에게 가짜 IP 주소를 반환하여 위조 사이트로 유도하는 DoS/위장 계열 공격이지만, 오염시키는 대상 컴포넌트와 패킷 획득 방식에 명확한 차이점이 존재합니다.

• DNS 캐시 포이즈닝 (DNS Cache Poisoning):
  • 공격 대상: 사용자 PC가 아닌, 중간에 위치한 Recursive DNS Server(재귀적 네임서버)의 캐시 메모리 자체를 오염시키는 공격입니다.
  • 작동 원리: 공격자는 타겟 Recursive 서버에 존재하지 않는 도메인에 대한 조작된 쿼리를 전송하여 외부 권한 네임서버로 외연 질의 패킷이 나가도록 유도합니다. 그와 동시에, 외부 정식 네임서버가 응답을 반환하기 전에 가짜 주소 정보를 변조한 응답 메시지를 대량으로 변조 생성하여 타겟 Recursive 서버로 퍼붓습니다.
  • 대량 전송의 기술적 이유: DNS 응답이 정식 수락되려면 요청 패킷의 16비트 식별값인 Transaction ID와 UDP 통신 규격의 목적지 포트 번호(Destination Port)가 원본 요청과 완벽히 일치해야 합니다. 공격자는 내부 스니핑을 할 수 없는 원격지 환경이므로, 임의로 무작위 대입(Brute Forcing) 연산을 수행하여 일치 확률을 올리기 위해 수만 개의 위조 응답 패킷을 레이싱하듯 대량 전송하는 방식을 취합니다. 인증 성공 시 해당 DNS 서버를 이용하는 모든 사용자가 집단적으로 오염된 주소로 유도당합니다.
• DNS 스푸핑 (DNS Spoofing):
  • 공격 대상: 주로 동일 로컬 네트워크(LAN) 상에 존재하는 단일 사용자 호스트 PC를 직접 타겟팅합니다.
  • 작동 원리: 공격자는 LAN 영역 내에서 ARP 스푸핑 등을 통해 트래픽을 가로채는 스니핑 환경을 먼저 선점합니다. 사용자가 외부 DNS 서버로 DNS Request 패킷을 송출하는 순간을 실시간 모니터링하여, 요청 헤더 속 고정된 Transaction ID와 목적지 포트 값을 그대로 복사해 냅니다. 이후 실제 외부 정식 네임서버의 정상 응답 패킷보다 지리적으로 가깝다는 특성을 악용하여 레이스 컨디션 구조로 더 빠르게 조작된 응답 패킷을 사용자에게 주입하여 처리 규칙을 가로챕니다.

⚠️ 주의: 보안 대응방안 및 핵심 개념 비교

[개념 차이] 캐시 포이즈닝은 원격지에서 DNS 서버의 식별 ID를 무작위 대입으로 뚫어 서버 캐시를 영구 변조하는 공격이고, 스푸핑은 로컬 LAN망 내부에서 스니핑한 ID를 기반으로 정상 응답보다 빠르게 가짜 패킷을 쑤셔 넣는 레이스 컨디션 공격입니다.
[대응방안] 네임서버 보안 강화를 위해 무작위 포트 할당 기술(Source Port Randomization)을 활성화하여 공격자의 ID/포트 예측을 무력화하고, 최종적으로 패킷 데이터에 암호학적 디지털 서명을 첨부하여 무결성을 검증하는 DNSSEC 프로토콜을 도입해야 합니다.

(4) DNS 서버의 전송 프로토콜 운용 방식 (TCP / UDP 사용 케이스)

- 요약 키워드: UDP 53, TCP 53, 존 전송(Zone Transfer), Any TXT, 512바이트 한계

- 기술적 동작 포트 분석:

DNS 서비스는 일반적으로 알려진 대로 기본 포트 53번을 공유하지만, 전송할 데이터의 크기와 처리 신뢰성 목적에 따라 운용 레이어(L4) 프로토콜을 명확히 이원화합니다.

• UDP 53번 포트 사용 케이스: 일반적인 웹 브라우징 과정에서 일어나는 단발성 도메인 이름 주소 질의 및 응답(Query / Response) 과정에서 사용됩니다. 오버헤드가 적어 빠른 처리가 가능하지만 전통적인 UDP 프로토콜 규격 상 응답 데이터 페이로드 크기가 512바이트 한계로 고정됩니다.
• TCP 53번 포트 사용 케이스: 다음의 두 가지 대용량 및 무결성 보장 전송 상황에서 강제로 활성화되어 세션을 수립합니다.
  • 존 전송 (Zone Transfer / AXFR, IXFR): 마스터 네임서버와 슬레이브 네임서버 간에 해당 도메인 영역의 전체 데이터베이스 데이터 레코드를 동기화할 때입니다. 데이터 누실이 없어야 하고 용량이 512바이트를 초과하므로 물리적 신뢰성이 높은 TCP 세션을 사용합니다.
  • Any / TXT 레코드 대형 질의: 클라이언트가 도메인의 모든 레코드 정보(ANY)나 앞서 다룬 암호학적 공개키가 들어간 긴 문자열의 TXT 레코드를 요구하여 응답 크기가 512바이트 임계치를 초과할 때, 수신 측에 'Truncation Bit(TC=1, 잘림 표시)' 헤더를 설정해 보내어 클라이언트가 TCP 53번 포트로 재접속하도록 유도합니다.

1.3. BIND 서버 설정 및 인프라 보안 관리

(1) 존 설정(Zone File) 아키텍처와 리소스 레코드 정의

- 요약 키워드: 존 설정 파일, /var/named, 리소스 레코드(Resource Record), 정방향/역방향 매핑

- 리눅스 인프라 실무 가이드:

BIND 네임서버 솔루션 환경에서 도메인과 IP의 데이터 자원 상태를 규정하는 정적 데이터베이스 아키텍처입니다.

• 개념 및 파일 경로: 아파치나 리눅스 커널과 연동되어 구동되는 BIND 설정 상에서, 특정 도메인 존의 관리 데이터 레코드를 기록한 텍스트 원본 파일을 의미합니다. 표준 운영체제 환경에서 기본적으로 /var/named/ 디렉터리 내부에 개별 텍스트 파일 형식으로 안전하게 보관됩니다.
• 리소스 레코드 (Resource Record, RR): 존 파일 내부에서 도메인 구조를 정의하는 행 단위의 표준 암호 규격 데이터 단위입니다. 문자열 도메인을 IPv4 주소로 연결하는 정방향 매핑과, 반대로 IP 주소를 가지고 도메인명을 추적해 내는 인프라 추적 방식인 역방향 매핑(PTR 레코드 활용) 구조를 정의하는 정보입니다.

(2) named.conf 내 구체적 zone 설정 구문 분석

- 요약 키워드: BIND 핵심 설정, allow-transfer, AXFR, IXFR, 증분 전송

- 설정 소스 코드 구문 분석:

BIND의 메인 제어 파일인 /etc/named.conf 내부에 주입되는 마스터 존 선언 블록의 코드 구조 예시입니다.

zone "example.com" IN {
    type master;
    file "example.com.zone"; # ❗이 부분은 마스터만 설정합니다.
    allow-transfer { 192.168.10.20; }; # 존 전송 허용 슬레이브 IP 명시 (보안 설정) 
    #❗슬레이브에서 설정하거나, 마스터 단독 구조인 경우 none;으로 설정합니다. 
};

• type master;: 해당 서버가 해당 존 파일 데이터에 대해 원본 수정 권한을 가진 주 네임서버임을 정의합니다.
• file "example.com.zone";: /var/named/example.com.zone 경로의 레코드 데이터 원본 매핑을 읽어오도록 지시합니다.
• allow-transfer: 중요 보안 지시어로, 무차별적인 내부 인프라 구조 스니핑(Zone Transfer 공격, 존 설정을 적절하게 하지 않을 시 DoS 공격에 활용되거나 중요한 도메인 정보가 노출 가능)을 방어하기 위해 지정된 백업 슬레이브 네임서버 IP 주소로만 존 데이터를 전송할 수 있게 엄격히 제약합니다. 거부 시 공백(none;) 처리합니다.

⚠️ 주의: AXFR vs IXFR 존 전송 메커니즘 차이

* AXFR (All Zone Transfer): 동기화 요청 시 도메인 내에 존재하는 모든 리소스 레코드 데이터베이스 원본 전체를 한 번에 무조건 전송하는 전체 복사 방식입니다.
* IXFR (Incremental Zone Transfer): 존 데이터 내부의 일련번호(Serial Number) 변경 사항을 추적하여, 이전 동기화 시점 이후에 수정되거나 추가된 증분 변경 레코드 데이터만 정제하여 전송하는 고효율 방식입니다.

(3) 방화벽(iptables)을 활용한 존 전송 차단 규칙 수립

- 요약 키워드: 네트워크 레벨 차단, iptables 설정 문법, TCP 53 제어

- 명령어 설계방안:

네임서버 내부 애플리케이션인 BIND 설정을 고치지 못하는 긴급 침해사고 상황 시, 커널 넷필터 모듈 인터페이스인 iptables를 사용하여 네트워크 인프라 레벨에서 존 전송 요청(TCP 53)을 원천 차단하는 방어 명령어 규칙 세트입니다.

# 지정된 백업 슬레이브 IP(192.168.10.20)를 제외한 나머지 모든 대역의 TCP 53번 포트 접속(존 전송 시도)을 원천 차단
iptables -A INPUT -p tcp -s 192.168.10.20 --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j DROP

일반 사용자의 일반 도메인 변환용 UDP 53번 포트 질의 패킷은 정상 수락하여 서비스 가용성을 보장하되, 정보 수집 목적의 비인가 제3자가 TCP 53번으로 핸드셰이크를 맺고 존 전체를 탈취(AXFR 공격)하려는 시도는 네트워크 진입 단계에서 강제로 Drop 시켜 차단 정책을 완료합니다.

(4) DNS 설정 파일 주소 경로 및 options 3대 핵심 보안 파라미터 제어

- 요약 키워드: resolv.conf, named.conf, version, directory, allow-query, 버전 은닉

- 보안 설정 가이드:

리눅스 인프라 환경에서 DNS 정보를 조회하고 데몬 서비스를 운영하기 위한 핵심 두 가지 주소 체계 파일의 필수 하드닝 가이드라인입니다.

• /etc/resolv.conf (클라이언트 등록 파일): 시스템이 외부 인터넷망을 탐색할 때 패킷을 송출할 재귀적(Recursive) DNS 네임서버의 주소를 순서대로 등록하는 파일입니다. (예: nameserver 8.8.8.8)
• /etc/named.conf (BIND 데몬 메인 설정 파일): 네임서버의 운영 환경과 접근 제어 규칙을 전역 선언하는 설정 파일입니다. 내부에 주입해야 하는 필수 보안 3대 속성은 다음과 같습니다.

options {
    directory "/var/named";            // 1. 데이터베이스 존 파일들이 상주할 기준 디렉터리 경로 지정
    version "Unknown / No comment";    // 2. 공격자의 취약점 스캐닝 목적 배너 그래빙(Banner Grab) 방지용 버전 문자열 은닉
    allow-query { 192.168.1.0/24; };  // 3. 네임서버에 단순 주소 질의를 넣을 수 있는 클라이언트 IP 범위를 화이트리스트로 제한
};

(5) 리소스 레코드(Resource Record) 유형별 기술 문법 표준

- 요약 키워드: SOA, A, AAAA, CNAME, MX, PTR, 레코드 작성 예시 문법

- 존 데이터 파일 작성 규격:

기사 실기 주관식 괄호 채우기 문제에서 빈번하게 출제되는 존 파일 내부 레코드 표준 마킹 규격 정보와 한 줄 예시 데이터셋입니다.

레코드 유형	의미 및 기술적 역할	존 파일 내 실제 표기 문법 예시
SOA	존 데이터의 시작을 뜻하며, 일련번호, 동기화 주기 등 존 전체의 제어 권한 관리 정보를 선언	@ IN SOA ns1.example.com. admin.example.com. ( 2026053101 3H 15M 1W 1D )
A	호스트 이름을 IPv4 주소로 다이렉트 매핑	www IN A 192.168.10.50
AAAA	호스트 이름을 IPv6 주소로 정방향 매핑	www IN AAAA 2001:db8::1
CNAME	이미 정의된 호스트 이름에 별칭(Alias)을 추가로 부여	ftp IN CNAME www.example.com.
MX	해당 도메인 영역의 이메일을 수신할 메일 서버(Mail Exchanger)와 우선순위를 지정	@ IN MX 10 mail.example.com.
PTR	역방향 존 파일 내에서 IP 주소를 호스트 이름으로 매핑 역추적	zone "10.168.192.in-addr.arpa" IN { 이 /etc/named.conf에 선행되어야 함 50 IN PTR www.example.com.

1.4. 서브도메인 하이재킹과 DNSSEC

(1) 서브도메인 하이재킹(Subdomain Takeover) 취약점 분석

- 요약 키워드: 타겟팅 공격, CNAME 매핑 허점, 리소스 삭제전 레코드 정리 미흡, 외부 호스팅 연동

- 공격 시나리오 메커니즘 및 4대 완화 대책:

서브도메인 하이재킹(Subdomain Takeover)은 기업이 관리하는 서브도메인의 CNAME 레코드가 외부 클라우드 인프라나 호스팅 서비스(예: AWS S3, GitHub Pages) 주소를 가리키고 있을 때, 연동해 쓰던 외부 자원을 해제한 후 DNS 레코드를 미처 삭제하지 않고 방치(Dangling DNS 상황)한 허점을 노리는 타겟팅 공격 기법입니다.

• 공격 동작 시나리오: blog.example.com이 외부 플랫폼 주소인 shawn.github.io를 CNAME으로 가리키고 있었으나 기업이 해당 github 계정을 삭제했습니다. 해커가 신속하게 동일한 이름인 shawn이라는 계정을 외부 플랫폼에 선점 생성해 버리면, 사용자가 blog.example.com을 입력했을 때 해커가 변조해 둔 외부 클라우드 자원으로 연결되어 XSS 공격이나 피싱 전초기지로 악용당하게 됩니다.

🚨 위험: 서브도메인 하이재킹 방어를 위한 4대 보안 대응방안

1. 리소스 삭제 전 레코드 정리 필수: 클라우드 인프라나 외부 호스팅 버킷 자원을 해제하거나 삭제하기 전, 반드시 연동된 내부 DNS 상의 CNAME 레코드를 먼저 완전 삭제 처리해야 합니다.
2. CNAME 포인팅 주기적 검증: 내부 레코드가 가리키는 외부 대상 도메인이 실제 유효하게 유지되고 있는지, 404 에러나 소유자 미지정 상태가 아닌지 주기적 유효성을 점검합니다.
3. 와일드카드(*) 레코드 남용 방지: 존재하지 않는 서브도메인 요청을 임의로 다 받아주는 와일드카드 레코드 설정을 지양하여, 해커가 임의의 서브도메인을 가로채 사칭 도메인을 만드는 행위를 차단합니다.
4. 자동화된 자원 스캐닝 점검 인프라 도입: 주기적으로 인프라 존 전체를 자동 검사하는 도구를 가동하여 고립된 레코드(Dangling DNS) 상태의 자원을 전수 조사하고 제거합니다.

(2) DNSSEC (DNS Security Extensions) 프로토콜 개요

- 요약 키워드: 위변조 원천 방지, 암호학적 디지털 서명, 무결성 보장, 공개키 암호화 구조

- 인프라 보안 표준 프로토콜 분석:

DNSSEC는 데이터 패킷 탈취 및 조작이 가능한 기본 DNS 프로토콜의 취약점을 근본적으로 보완하여 위변조를 원천 방지하기 위해 IETF가 제정한 보안 확장 프로토콜 기술입니다.

• 보안 기능 및 도입 목적: 공개키 암호화 구조(비대칭키) 알고리즘을 도입하여, DNS 레코드 데이터에 암호학적 디지털 서명(Digital Signature)을 포함해 송출합니다. 수신 측(Recursive DNS 서버)은 이 서명을 검증하여 데이터가 중간에 조작되지 않았음을 확증하는 데이터 무결성 보장 서비스와, 이 레코드가 진짜 해당 권한이 있는 네임서버에서 온 것이 맞음을 확인하는 송신처 인증 서비스를 동시에 제공합니다.
• 동작 레이어 및 적용 대상: 데이터 자체를 안전하게 확인하기 위해 DNS 레코드를 저장하고 응답을 생산해내는 Authoritative DNS Server(권한 있는 네임서버)와 이를 신뢰하여 해석해야 하는 Recursive DNS 서버에 직접 구동 세팅을 반영하여 운영합니다.

DNSSEC 추가된 레코드

• DNSKEY 레코드: 도메인 존(Zone)의 공개키 데이터를 저장하고 제공하기 위한 레코드입니다. DNSSEC이 적용된 존은 개인키와 공개키 쌍을 기반으로 응답 데이터의 무결성을 검증할 수 있도록 구성됩니다. 이때 개인키는 존 관리자가 안전한 위치에 별도로 보관하며, 공개키는 DNSKEY RR 형태로 존에 게시되어 질의응답을 통해 외부 검증자에게 제공됩니다. 수신 측은 이 DNSKEY를 사용하여 RRSIG 레코드에 포함된 전자서명을 검증할 수 있습니다.
• RRSIG 레코드: 존 안에 존재하는 리소스 레코드 셋(RRset)에 대해 개인키로 전자서명한 결과값을 저장하는 레코드입니다. DNSSEC에서는 개별 레코드 하나가 아니라 같은 이름, 같은 타입, 같은 클래스를 가진 RRset 단위로 서명이 생성됩니다. DNS 응답 메시지에는 일반 리소스 레코드와 함께 해당 RRset에 대한 RRSIG가 포함되어 전달되며, 수신 측은 DNSKEY에 포함된 공개키로 이 서명을 검증하여 응답 데이터가 중간에서 위조되거나 변조되지 않았는지 확인할 수 있습니다.
• DS 레코드: DNS 고유의 계층적 위임 구조 안에서 부모 도메인과 자식 도메인 사이의 신뢰 관계를 연결하기 위한 레코드입니다. DS 레코드는 부모 존에 저장되며, 자식 존의 KSK(Key Signing Key)에 대한 해시 값을 포함합니다. 이를 통해 검증자는 상위 존에서 하위 존으로 이어지는 인증 경로를 따라가며 자식 존의 DNSKEY가 신뢰할 수 있는 키인지 확인할 수 있습니다. 즉, DS 레코드는 루트 존부터 최종 도메인 존까지 이어지는 DNSSEC 신뢰 체인(Chain of Trust)을 구성하는 핵심 요소입니다.
• NSEC / NSEC3 레코드: DNS 데이터 부재 인증을 위해 정의된 레코드입니다. DNSSEC에서는 특정 도메인이나 리소스 레코드가 존재하지 않는다는 응답도 단순한 오류 메시지로 처리하지 않고, 전자서명을 통해 검증 가능한 형태로 제공합니다. NSEC 레코드는 존 안에 존재하는 다음 도메인 이름과 해당 이름에 존재하는 레코드 타입 정보를 제공하여, 질의한 이름이나 타입이 실제로 존재하지 않음을 증명합니다. 다만 NSEC은 존에 존재하는 도메인 이름의 순서 관계가 노출될 수 있어, 공격자가 존 내부의 도메인 목록을 추정할 수 있는 문제가 있습니다. 이를 보완하기 위해 NSEC3는 도메인 이름을 그대로 노출하지 않고 해시 값을 기반으로 부재를 증명하는 방식으로 동작합니다.
  • 쉬운 개념 설명: 사용자가 네임서버에 없는 도메인(ex. abcd.com)을 조회했을 때, 공격자가 중간에서 "이 도메인은 여기 IP 주소로 가시면 됩니다"라고 가짜 응답을 조작해 낚는 것을 방어하기 위해 쓰입니다. 네임서버가 알파벳 순서상 앞뒤로 존재하는 실제 도메인 경계를 명시하고 여기에 전자서명을 채워 응답함으로써, "너가 찾는 도메인은 진짜로 우리 서버에 존재하지 않는 도메인이 맞다"라는 사실을 위조 없이 투명하게 증명해 주는 원리입니다. NSEC의 도메인 존 목록 노출 문제를 해결하기 위해 해시 값을 결합한 NSEC3 레코드가 추가로 정의되었습니다.