DNS (Domain Name System)란?

1. DNS (Domain Name System)

1) DNS 등장 배경

인터넷 표준 프로토콜은 TCP/IP이다.

TCP/IP 프로토콜을 사용하는 네트워크 안에서 Host들을 식별하기 위한 목적으로 IP 주소를 사용한다.

사람의 경우 숫자보다 문자를 사용하는 것이 더 편하기 때문에 도메인 이름을 사용하여 Host들을 식별한다.

도메인 이름을 사용하는 경우에도 최종적으로 IP주소를 알고 있어야 상대방 장비와 연결이 가능하다.

네트워크에서 도메인이나 호스트 이름을 숫자로 된 IP 주소로 해석해 주는 TCP/IP Network Service인 DNS가 등장하였다. 

 

2) DNS 포트 번호

UDP와 TCP 포트 53번을 사용한다. 

 

UDP: 일반적인 DNS 조회를 할 경우 

TCP: Zone Transfer(영역 전송)을 수행할 경우 또는 512Byte를 초과하는 DNS패킷을 전송해야 할 경우

 

2. DNS 과거와 현재

1) 과거

예전에는 컴퓨터마다 hosts.txt 파일을 가지고 있다.

파일 위치: C:\Windows\System32\drivers\etc\hosts

 

hosts.txt 예시

 

hosts 파일에는 모든 컴퓨터의 Hostname과 IP Address 정보가 저장되어있다.

Client는 FTP를 이용해 접근해서 hosts 파일을 다운로드 및 적용하였다.

90년대 초반 Web 서비스 사용자가 폭발적으로 증가하면서 Internet에 연결된 Host 숫자가 크게 늘어 났다.

호스트의 수정 및 업데이트가 늦어지고 네트워크 트레픽이 증가하고 호스트 이름을 짓기가 어려워졌다.(이름중복)

 

2) 현재 

분산된 데이터베이스 이용한다.

도메인이 워낙 많기 때문에 전 세계 모든 조직의 도메인정보를 갖고 있는 DNS 서버는 존재하지 않는다.

각 조직은 자신들의 도메인 정보를 관리하는 DNS서버를 자체적으로 운영하고,이러한 수 많은 도메인의 DNS 서버들이 상호 연동되어 있는  Domain Name Space를 구성하게 된다.

 

3. DNS의 구성 요소

1) 도메인 네임 스페이스 (Domain Name Space)

DNS가 저장,관리하는 계층적 구조를 의미한다.

 

DNS 계층적 구조

최상위에 루트 DNS 서버가 존재하고, 그 하위로 인터넷에 연결된 모든 노드(네모 표시)가 연속해서 이어진계층 구조로 구성되어 있다.

PC에서 사용하는 디렉토리 구조와 유사함을 알 수 있는데, 각 레벨(Top level, Second level 등)의 도메인은 그 하위 도메인 에 관한 정보를 관리하는 구조이다. (계층적 구조)

 

도메인(Domain) 이란?

도메인은 도메인 네임 스페이스의 서브트리이다. 도메인 이름은 서브트리의 맨 상위에있는 노드에 위치한다.

 

2) 네임 서버 (Name Server)

문자열로 표현된 도메인 이름을 실제 컴퓨터가 통신할 때 사용하는 숫자로 표현된 IP 주소로 변환시켜 주기 위해서는 도메인 네임 스페이스의 트리 구조 에 대한 정보가 필요하며, 이러한 정보를 가지고 있는 서버를 네임 서버라고 한다.

도메인 이름을 IP 주소로 변환하는 것을 네임 서비스라고 한다.

리졸버(Resolver)로부터 요청 받은 도메인 이름에 대한 IP 정보를 다시 리졸버로 전달해주는 역할을 수행한다.

 

Master Name Server (Primary Name Server)

해당 도메인을 관리하는 주 네임 서버이다.

Zone 파일을 관리하는 네임서버이다.

 

Slave Name Server (Secondary Name Server)

master 네임 서버 의 고장 등의 이유로 동작하지 못하는 경우 이를 대신하여 네임 서버 역할을 수행하는 서버이고 주기적으로 master 네임 서버로부터 Zone Transfer를 통해 자신의 정보를 갱신하여 전체 네임 서버의 정보가 일관성 있게 유지 및 관리된다.

 

Authoriactive Name Server의 경우 부하분산, 가용성을 위해 보통 2대 이상으로 운영한다.

 

영역 전송(Zone Transfer)이란?

마스터에 있는 원본 영역 데이터를 슬레이브가 동기화하는 작업을 의미한다.

데이터 크기가 크고 신뢰성 있는 전송을 수행하기 위해 TCP 53번 포트를 이용한다.

 

3) 리졸버 (Resolver)

웹 브라우저와 같은 DNS 클라이언트의 요청을 네임 서버로 전달하고 네임 서버로부터 정보(도메인 이름과 IP 주소)를 받아 클라이언트에게 제공하는 기능을 수행한다.

하나의 네임 서버 에게 DNS 요청을 전달하고 해당 서버에 정보가 없으면 다른 네임 서버에게 요청을 보내 정보를 받아 온다.

수많은 네임 서버에 접근하여 사용자로부터 요청 받은 도메인의 IP 정보를 조회하는 기능을 수행할 수 있어야 한다.

 

4) 스터브 리졸버(Stub Resolver)

리졸버의 모든 기능을 PC와 같은 클라이언트 호스트에 구현하는 것은 단말 시스템 자원의 한 계와 같은 제약이 있다.

리졸버의 대부분의 기능을 DNS 서버에 구현하고, 클라이언트 호스트에는 리졸버의 단순한 기능만을 지닌 리졸버 루틴을 구현한것이다.

스터브 리졸버는 수 많은 네임 서버의 구조를 파악할 필요 없이 리졸버가 구현된 네임 서버의 IP 주소만 파악하면 된다.

도메인에 대한 질의를 받은 스터브 리졸버는 설정된 네임 서버로 DNS 질의를 전달하고 네임 서버로부터 최종 결과를 응답 받아 웹 브라우저로 전달하는 인터페이스 기능만을 수행한다.

 

4. DNS 동작 과정

①~③ Root DNS 서버는 전체 FQDN 정보는 알지 못하기 때문에 자신의 하위 Domain인 COM DNS 서버의 주소를 알려준다.

④~⑤ 이를 수신한 Local DNS 서버는 다시 Iterative Query를 사용하여 com DNS 서버에게 정보를 요청하고, com DNS 서버도 자신의 하위 레벨 Domain인 naver.com의 DNS서버 주소를 알려준다.

⑥~⑦ 이를 수신한 Local DNS 서버는 다시 Iterative Query를 사용하여 naver.com DNS 서버에게 www 호스트에 대한 정보를 요청하고, naver.com DNS 서버는 www.naver.com에 대한 IP서버 주소를 알려준다.

 ⑧ Local DNS 서버는 위와 같이 www.naver.com 에 대한 IP주소를 수신 후 자신의 DNS Cache에 등록하고 해당 정보를 요청했던 Client에게 응답메세지로 답변한다.

 

Authoritative DNS 서버

관리/위임받은 도메인을 가지고 있는 네임서버를 말한다.

특정 도메인에 대한 정보를 관리 하면서 해당 도메인 질의에 대한 응답만 수행한다.

아래 그림의 Root, com, naver.com DNS에 해당한다.

 

Recursive DNS 서버

관리/위임받은 도메인 없이 모든 질의에 대해서 응답한다.

ISP 업체에서 제공하는 DNS서버에 해당한다.

Local DNS Cache에 정보를 담고 있고 질의하는 정보가 캐시에 존재할 경우 바로 사용자에게 정보를 전달해 주고 모르는 경우 Authoritative DNS 서버에 질의한다.

아래 그림의 Local DNS에 해당한다.

 

해당 Client는 수신한 www.naver.com의 의 IP주소를 사용하여 실제 해당 서버에 패킷을 전송하게 된다. 그 후 Local DNS 서버는 다른 Client에게 동일한 FQDN에 대한 DNS Query를 수신할 경우 DNS서버 Cache에 등록된 정보로 답변하는 것이 가능하다.

 

 

 

 

DNS 동작과정

 

5. FQDN (Full Qualified Domain Name: 정규화된 도메인 이름)

네트워크상에서 컴퓨터시스템을 지칭하는 하나의 완전한 이름이다.

DNS의 서버이름을 hostname + domain name으로 표현된다.

 

Host name : 실제 서버에 주어진 컴퓨터의 이름이다. (www.naver)

Domain name : 논리적인 그룹을 표기한다. (.com)

 

6. Zone 파일

Authoritative DNS에서 관리하는 도메인 영역을 Zone이라고 하고 관리도메인에 대한 정보를 담고 있는 파일을 Zone파일 이라고 한다.

Domain을 소유한 특정 조직의 DNS 서버는 해당 Domain에 대한 Zone 파일(영역 파일)을 갖는다.

해당 Zone 파일에는 Resource Record라고 불리는 Domain 내부 정보가 존재하고, 해당 정보 조회를 허용하여

외부 Client에게 정보를 제공할 수 있다.

 

Zone 설정 예시

zone "ict.com" IN{    type master;    file "ict.com.db"; }; zone "250.1.10.in-addr.arpa" IN{    type master;    file ict.com.db.rev"; };

 

Zone 파일 설정 예시

@    IN   SOA   ns1.ict.com. maste.ict.com.(                          ... ) ns1   IN   A   ns1.ict.com. 3   IN PTR www.ict.com   [host_name] [TTL] [class] [recode_type] [data]

 

1) Resource Recode 종류

SOA: 해당 Domain 관리 권한 및 Zone Transfer(영역 전송)과 관련된 정보가 들어있다.

NS: NameServer의 정보를 갖고 있다.

A(AAAA): 특정 host의 FQDN과 연결된 IP주소 정보를 갖는다.

CNAME: 특정 A레코드에 대한 별칭을 지정한다.

MX: Mail eXchange의 약자로 Mail 서비스에 관련된 정보를 갖고 있다. (해당 Domain의 Mail서버 정보)

PTR: 역방향 조회에 사용되는 레코드, 특정 IP주소에 대한 FQDN 정보를 가지고 있다.

 

AXFR: 존 버전에 상관없이 무조건 존 전송 요청

IXFR: 존 버전을 비교하여 상위 버전일 경우 존 전송 요청

AXFR, IXFR 레코드를 통해 존 전송 허용 여부를 확인할 수 있다.

 

ANY: 도메인에 대한 모든 레코드 질의 시에 주로 이용된다. 

TXT: 도메인에 대한 텍스트 정보 질의한다. 대표적으로 SPF(발송자 메일서버 인증) 정보가 저장되어 있다.

 

ANY, YXT 레코드의 경우 요청 대비 응답 데이터의 크가기 커서 DNS Reflection DRDOS 공격에 악용될 수 있다.

 

2) DNS 조회

정방향 조회 : Domain Name을 사용하여 IP주소를 조회한다.

역방향 조회 : IP주소를 이용하여 Domain Name을 조회한다.

 

3) DNS 조회 절차

3.1) 우선순위

① Local DNS Cache

서버가 다른 서버에게 매핑 정보를 요청하고 응답을 수신하면 이 정보를 클라이언트에게 전달하기 위해 캐시 메모리에 저장한다.

주소 해석 속도를 높일 수 있지만 오랫동안 캐싱 정보를 가지고 있다면 클라이언트에게 잘못된 매핑 정보를 제공할 수 있다.

네거티브 캐싱을 지원한다.

 

네거티브 캐싱이란?

잘못된 도메인에 관한 요청을 캐싱하여 불필요한 트래픽과 지연을 줄인다.

 

② hosts File

도메인/호스트명과 IP 주소 매핑정보를 담고있는 파일로 질의하기 이전에 먼저 참조되는 파일이다.

파밍 공격을 하기 위해서 해당 파일을 변조하는 사례가 많으므로 관리가 필요하다.

윈도우에서 hosts.ics 파일을 먼저 참조하고 이후에 hosts파일을 참조한다.

 

③ DNS Server Query

 

3.2) 질의 방법

Client PC에서 DNS 조회

사용자가 Domain Name을 사용하여 특정 Host와 통신을 원하는 경우 Client PC는 hosts파일을 먼저 보고 DNS Cache(ipcofifg /displaydns에 해당 도메인 정보가 있는지 확인한다.

만약 Hosts 파일 혹은 DNS Cache에 해당 정보가 존재하는 경우 해당 정보를 사용하여 패킷을 전송한다.

패킷이 존재하지 않는 경우에는 자신이 알고 있는 Local DNS 서버에서 DNS Query 메세지를 전송한다.

 

Recursive Query를 수신한 Local DNS 조회

해당 DNS Query를 수신한 서버는 자신의 Zone 파일(영역 파일) 정보인지 확인한다.

자신의 Zone 파일 정보가 맞는 경우에는 A레코드에 등록된 IP 주소로 응답한다.

자신의 Zone 파일 정보가 아닌 경우 DNS서버의 Cache 정보를 확인한다. 

만약 Cache에 해당 정보가 등록되어 있는 경우 IP 주소를 Client에게 응답한다.

DNS 서버 Cache에 해당 정보가 없는 경우 Root hints를 참고하여 Root DNS 서버에게 Iterative Query를 전송하게 된다.

 

7. dig 명령어 활용

dig [@nameserver] 도메인 [쿼리 유형] [쿼리옵션]

+tcp: 53/tcp 허용여부를 점검

+norecurse: Authoriative 네임서버를 점검하기 위해 interaitve Query 수행

+trace: 계층적 위임설정 상태 점검

 

dig @168.126.63.1 www.google.com ns

google.com 도메인의 name server를 질의하였다.

google.com을 관리하는 4개의 Authoritative name server를 확인할 수 있다.

 

id: Transaction ID

qr: 응답

rd: Recursive Query

ra: 168,126.63.1 서버가 Recursive DNS 서버이다.

 

 

dig @ns1.google.com www.google.com A +norecurse

+norecurse: iterative Query 수행

 

qr: response 응답

aa: Authoritative DNS Server에서 온 응답

 

 

Authoritative DNS Server의 경우 자신이 관리하는 도메인이 아닐경우 질의를 수행하지 않는다.

 

 

8. DNS Spoofing Attack

UDP 프로토콜의 비연결 특성 취약점을 이용한 공격기법이다.

DNS Spoofing은 Victim에게 전달되는 DNS 응답을 조작 하거나 DNS 서버의 Cache 정보를 조작하여 Victim이 의도하지 않는 주소로 접근하게 하는 공격 방법이다.

 

1) Sniffing 기반의 DNS Spoofing 공격

정의

Victim이 DNS질의를 수행하면 Attacker가 동일 네트워크에서 ARP Redirection 공격을 통해 Sniffing 하고 있다가 올바른 DNS응답보다 빠르게 희생자에게 조작된 웹사이트 IP정보를 담은 DNS 정보를 보내 Vicrtim이 정상적인 주소를 입력하여도 조작된 URL로 접속하게 만드는 공격 기법이다.

 

공격 방법

① Target PC가 Web Browser에서 www.ictsec.com(Web 서버)로 접속한다.

② Target PC가 DNS 서버한테 www.ictsec.com의 주소를 알아 오기 위해 질의를 수행한다.

③ Attacker는 DNS 서버가 응답하기 이전에 먼저 정상적인 Transaction ID, 출발지 IP, 목적지 IP 주소와 조작된 DNS 정보가 감긴 DNS Reply를 보내 Target PC가 Web 서버의 주소가 Attacker의 IP로 등록하게 된다. 

④ Victim은 DNS Reply가 먼저 도착한 패킷을 신뢰하기 때문에 이후 정상적인 DNS 서버에서 보낸 DNS Reply 패킷을 무시하게 된다.

⑤ Target PC는 www.ictsec.com에 들어가기 위해서 Attacker에 접근하게 된다.

⑥ Attacker는 IP Forwording을 통해 Target PC가 웹서버에 접근할 때 정상적인 서버인 것처럼 동작하게 수행한다.

 

공격 수행

Victim: 10.1.10.4

Gateway: 10.1.10.254
Attacker: 10.1.10.100

 

① Sniffing

ARP Redirect Attack

ARP Request: arpspoof -i eth0 -t 10.1.10.4 10.1.10.254

IP Forwording: fragroute -B1

ARP Reply: arpspoof -i eth0 -t 10.1.10.254 10.1.10.4

 

② DNS Spoofing

dnsspoof -i eth0 dnsspoof.txt

 

dnsspoof.txt 파일 내용: 10.1.10.100 www.ictsec.com

 

대응 방법

스니핑 공격이 선행되어야 하기 때문에 이를 탐지 및 차단한다.

중요한 사이트 주소의 경우 DNS 질의보다 우선순위가 높은 hosts 파일에 등록하여 관리해야 한다.

 

2) DNS Cache Poisoning 공격

정의

Recursive DNS 서버의 캐시 정보를 조작하는 공격 기법이다.

DNS 서버 자체를 공격하기 때문에 캐시의 TTL이 유지되는 시간 동안 다수의 사용자가 조작된 DNS 응답을 수신하여 대규모의 보안사고가 발생할 수 있다.

Sniffing이 불가능 하기 때문에 Recursive DNS 서버가 AuthoritativeDNS 서버에Iterative Query를 수행할때 목적지 포트 53번으로 어느정도 알 수 있지만 Transaction ID, 출발지 Port를 알 수 없기 때문에 랜덤한 값이 담긴 다수의 조작된 응답을 전송(Birthday Attack)한다.

 

Birthday Attack이란?

한반에 동시에 23명의 사람이 모여있을 때 그중에 생일이 같은 사람이 있을 확률이 50%이상이라는 생일에 역설에 기반을 둔 공격 방법이다. 이는 정답인 확률이 우리가 생각하는 것보다 매우 높다는 의미이다.

 

공격 방법

Recursive DNS 서버가 Iterative Query를 수행할때 조작된 dns 질의를 다수 보내면서 랜덤한 Transaction ID와 출발지 Port를 다수 생성하여 응답한다.

Attacker의 조작된 응답 중 정상 응답보다 먼저 일치하는 응답이 있을 경우 조작된 정보가 DNS 서버의 Cache에 저장되고 이를 질의하는 Victim은 조작된 주소의 사이트로 접속하게 된다.

 

 

대응 방법

Authoritative DNS 서버에서 Recursive Query를 허용하지 않도록 설정하거나 사용자를 제한해서 사용한다.

DNS에 공개키 암호화 방식을 추가한 DNSSEC 기술을 활용한다.

해당 기술을 이용하면 무결성, 데이터 위변조 방지 및 메시지 송신자 인증과 전자서명은 제공되지만, 기밀성, 가용성은 보장할 수 없다.

 

9. DNS 보안 설정

1) Recursive Query 거부 방법

DNS Cache Poisoning 공격을 예방하기 위해 Authoriactive DNS 서버에 Recursive Query를 거부 또는 제한한다.

 

설정 방법

경로: /etc/named.conf

recursion no

allow-recursion {none;}; 

allow-recursion {127.0.0.1; 192.168.1.0/24;};

 

2) Zone Transfer에 대한 제한

Master DNS 서버만 운영할 경우 존 전송을 허용하지 않도록 설정하고 Master, Slave를 운영하는 환경에서는 지정한 Slave에서만 존 전송을 요청하도록 설정한다.

axfr, ixfr 레코드를 이용하여 전송여부를 확인한다.

 

설정 방법

경로: /etc/named.conf

allow-transfer {none;};

allow-transfer {192.168.1.50;};

 

zone 전송이 허용되지 않은 경우 아래와 같이 출력된다.

 

3) bind 버전 정보 숨기기

공격자가 bind 버전을 알 수 있다면 취약한 버전임을 확인하면 악의적 공격을 수행할 수 있기 때문에 버전정보는 노출하지 않도록 설정한다.

 

 

설정 방법

경로: /etc/named.conf

version "unknown";

 

[출처]

dns cache poisoning 그림: https://www.wallarm.com/what/what-is-dns-spoofing-dns-cache-poisoning