정호 충자료 dns 와 dns 체계 구축 - mmu.ac.krlily.mmu.ac.kr/lecture/13is/add_dns.pdf ·...

DNS 와 DNS 체계 구축

정보보호 보충자료

목차

1. DNS 기본 개념

2. ISC의 BIND

3. IPv6와 DNSv6

4. DNS 보안 강화

2

1. DNS 기본 개념 DNS 탄생 배경 DNS 구성 요소와 구조 DNS 프로토콜 도메인(domain)과 존(zone) 자원 레코드 (Resource Record) 도메인 위임 관련 RR : SOA & NS 호스트 주소 관련 RR : A & AAAA 전자우편 서비스 관련 RR : MX 일반적인 DNS 도메인 위임설정 보안이 강화된 DNS 도메인 위임설정 DNS ZONE 관련 확장 – 기존 방법(AXFR) DNS ZONE 관련 확장 – NOTIFY DNS ZONE 관련 확장 – IXFR DNS ZONE 관련 확장 – Dynamic Update DNS 확장 - EDNS0

3

DNS 탄생 배경

DNS(Domain Name System) : 도메인 이름 네트워크 주소

Name system 중 하나 (URI, IRI, …)

역사적 배경

초기에 숫자 형식의 네트워크 주소 직접 사용

호스트 수가 늘어나면서 기억하기 쉬운 니모닉(호스트 이름) 이용

1970년대 초반 23개 호스트

1970년대 중반 이후 111개 호스트 : hosts.txt 파일을 ftp로 다운받아 이용

1983년 562개 호스트 : 위스콘신 대학에서 DNS 제안

DNS = 체계적인 도메인 이름체계 + 분산구조형 계층적 도메인 데이터베이스 체계

4

DNS 구성 요소와 구조(1)

구성 요소

도메인 이름 공간(Domain Name Space) 및 자원 레코드(Resource Record)

네임서버(Name Server)

리졸버(Resolver)

5

Domain name space Resource Records

Name Server Resolver

application

cache

DNS protocol udp 53 or tcp 53


도메인 이름 공간 : 도메인 이름의 계층적 구조 공간 도메인 이름의 할당과 분배는 전세계적으로, 체계적으로 관리

국내 관리기관 : 한국인터넷진흥원(KISA : 과거 KrNIC)

국제 : InterNIC, APNIC(Asia-pacific NIC) 등

자원 레코드 : 도메인 이름에 대해 필요한 인터넷 자원 정보를 매핑하는 수단을 제공 예: www.example.com 1800 IN A 192.0.2.101

새로운 타입의 자원 레코드가 계속 정의 중

네임 서버 : 도메인 트리의 일부분에 해당하는 정보를 지니고 전체 인터넷 도메인 트리의 한 부분을 구성 iterative DNS 서버 : 특정 질의에 대해 자신이 소유한 도메인 존의 정보만 그

응답으로 제공하는 동작을 하는 DNS 서버

recursive DNS 서버 :

authoritative DNS 서버 : 도메인 네임 공간 상의 특정 영역에 대해 관리권한이 위임된 서버

6


리졸버 : 응용 프로그램과 DNS 간의 인터페이스 역할로서 도메인 데이터베이스를 검색하는 기능 전체 도메인 데이터베이스를 검색할 수 있도록 도메인 네임 시스템 검색의 시작점이

되는 루트 네임서버(root name server)의 IP 주소 정보를 자신의 환경 구성 파일에 저장

동일한 DNS 질의를 짧은 시간 내에 빈번하게 반복하는 것을 방지하기 위해 캐쉬(cache)을 내부에 구현

대부분의 호스트에는 전체 리졸버 기능이 아닌 스터브 리졸버(Stub Resolver) 형태로 구현

스터브 리졸버 : 호스트 내의 응용 프로그램에 프로그래밍 인터페이스를 제공하고 응용 프로그램의 질의 요청이 있는 경우, 시스템에 지정된 리졸버(Resolver) 역할의 네임서버(name server)로 DNS 질의를 요청

스터브 리졸버의 설정 파일 내에는 리졸버 네임 서버의 주소만 저장 (Windows XP에서 설정하는 네임 서버의 주소, UNIX 계열 호스트의 /etc/resolv.conf에 저장되는 주소)

물리적 구현 요소 : 네임서버, 리졸버, 스터브 리졸버

7

DNS 프로토콜

네트워크를 통해 DNS 구현요소 간 DNS 질의(DNS query)와 응답(DNS response)를 수행하기 위한 서버-클라이언트 모델의 응용 계층 프로토콜

네임서버와 리졸버간, 리졸버와 스터브 리졸버간에 사용

TCP 및 UDP 포트 번호 53번 사용

일반적으로 UDP 포트 53을 사용하여 질의와 응답이 이루어지나, DNS 메시지 영역의 길이가 512 바이트를 초과하는 경우, TCP 53번 포트를 사용하는 TCP 연결을 통한 DNS 질의응답이 이루어지는 메커니즘이 존재

일반적으로 TCP를 이용하는 경우는 영역 전체의 데이터를 전송하는 zone transfer

8

도메인(domain)과 존(zone) (1)

도메인 네임공간 인터넷 상에 존재하는 리소스에 대한 네임체계를 어떻게 체계화할 것인가에 대한

구성방안

계층적인 도메인 네임 구조 루트 도메인(root domain)으로부터 시작하여 각 서브 도메인으로

위임(delegation)하는 구조로 형성

루트 도메인은 특수한 도메인으로 모든 도메인의 부모 도메인

도메인 네임 표현 도메인 네임은 “.”(dot)로 구분된 레이블로 구조화된 이름으로 표시

레이블은 0～63 옥텟의 크기를 가지는 숫자/문자의 조합으로 부여

루트 도메인의 레이블은 널 레이블로 그 길이가 0인 특수한 레이블로 정의

루트가 아닌 다른 노드들은 1～63 옥텟 크기의 레이블을 부여

ASCII 코드 중 “a”에서 “z”까지(또는 “A”에서 “Z”까지)의 문자, 그리고 “0”에서 “9”까지의 숫자, 그리고 기호문자 중 “-”(하이픈)만을 사용

첫 문자에는 “-”이 사용할 수 없음

9


10

도메인(domain)과 존(zone) (3) FQDN(Fully Qualified Domain Name) :

도메인 네임을 루트 도메인으로부터 시작하는 전체 이름의 표기를 사용한 것

최대 255 옥텟의 길이

PQDN(Partially Qualified Domain Name)

상위 도메인 네임이 생략된 도메인 네임

www.example.co.kr로 표기하는 경우 www.example.co.kr.example.co.kr.으로 잘못된 해석

최상위 도메인(TLD, Top Level Domain)

루트 노드 다음 계위의 노드

예: com, org, net, kr, jp, int 등

범용 도메인은 gTLD(generic TLD)

국가별 도메인은 ccTLD(country code TLD)

http://www.iana.org/cctld/cctld-whois.htm에서 확인 가능

인터넷 인프라 도메인 : 특수한 도메인으로 ARPA 도메인을 지칭

164.arpa, in-addr.arpa, ip6.arpa, uri.arpa, urn.arpa 등의 하위 도메인 존재

2단계 도메인(SLD, Second Level Domain)

최상위 도메인으로부터 분기된 다음 계위(level)의 노드

예: co.kr, or.kr, ne.kr 등

11

http://www.example.co.kr로/

http://www.example.co.kr로/

http://www.example.co.kr.example.co.kr/

http://www.iana.org/cctld/cctld-whois.htm




도메인 존(domain zone) 도메인 트리 구조에서 특정 노드와 그 하위 노드를 포함하는 일정한 영역을 지칭

단일 관리자에 의해 관리되는 도메인 네임 영역

“example.co.kr” “example.co.kr”이라는 도메인 등록 절차를 마침으로써 해당 도메인에 대한 권한 위임

관리자는 해당 도메인에 속한 노드에 필요에 따라 원하는 레이블을 부여하여 새로운 도메인 네임을 생성

웹 서버에 대해서는 “www”, 메일 서버에 대해서는 “mail”, 도메인의 DNS 서버에 대해서는 “ns1”과 “ns2"의 레이블을 갖는 노드를 생성, 설정

.co.kr 도메인 example.co.kr 도메인을 포함하는 도메인

co.kr 도메인 존은 example.co.kr에 대한 위임 설정 관리만을 수행

example.co.kr 도메인이 가지고 있는 도메인 네임에 대한 관리는 안 함

12

자원 레코드 (Resource Record) (1)

도메인 네임과 인터넷 자원 정보를 매핑하여 하나의 분산 구조형 데이터베이스를 구성하기 위한 수단

13

자원 레코드 (Resource Record) (2)

도메인 네임이 갖는 속성을 표현

하나의 도메인 네임이 다수의 자원 레코드를 가질 수 있음

자원 레코드는 다양한 인터넷 자원 정보를 표시하는 체계로서 추가 확장 정의될 수 있는 유연한 구조

일반적 구조 <Name><TTL><Class> <Type><RDATA>

<RDATA>는 각 타입마다 다른 형식인데 일반적으로 <RDLength><RRData> 형태

<Name> : 도메인 네임을 의미하며 데이터를 검색하기 위한 키 인덱스 역할

<TTL> : Time To Live

리졸버의 캐쉬 테이블에 얼마나 오래 존속할 것인지를 결정하는 초 단위의 값

0～2147483647

<Class> : 의미가 없어진 필드로 IN(Internet)만 이용

<Type> : 각 자원 레코드의 유형을 지정하는 필드

A RR : 1

NS RR : 2

SOA RR : 6 등

14

자원 레코드 (Resource Record) (3) TYPE CODE 의미 비고

A 1 A host address 32bit IPv4 주소

NS 2 An authoritative name server 네임서버 도메인 네임 지정

MD 3 A mail destination(Obsolete-useMX) 폐지

MF 4 A mail forwarder(Obsolete-use MX) 폐지

CNAME 5 The canonical name for an alias Alias 도메인 네임 설정 원래 도메인 네임을 매핑

SOA 6 Marks the start of a zone of authority Zone의 속성 정보 지정

MB 7 A mailbox domain name(EXPERIMENTAL) 실험적 구현

MG 8 A mail group member(EXPERIMENTAL) 실험적 구현

MR 9 A mail rename domain name(EXPERIMENTAL) 실험적 구현

NULL 10 A null RR(EXPERIMENTAL) 실험적 구현

WKS 11 A well known service description 호스트의 특정 IP주소 및 해당 IP 주소를 통해 제공하는 TCP/ UDP 서

비스 포트정보 지정

PTR 12 A domain name pointer 도메인 네임을 매핑함 주로 IP 주소의 도메인네임 지정에 사용

HINFO 13 Host information 호스트의 CPU와 OS 정보

MINFO 14 Mailbox or mail list information

(EXPERIMENTAL) 실험적 구현

MX 15 Mail exchange 메일서버의 도메인 네임 지정

TXT 16 Text strings 문자열 정보를 지정

RP 17 For Responsible Person 도메인 네임별 담당자 정보

AFSDB 18 For AFS DataBase location AFS DB 위치정보

X25 19 For X.25 PSDN address 도메인 네임의 X.25 주소정보 15


ISDN 20 For ISDN address 도메인 네임의 ISDN 주소정보

RT 21 For Route Through

NSAP 22 For NSAP address NSAP 주소정보

NSAP-PTR 23

SIG 24 For security signature 보안 서명을 저장

KEY 25 For security key 보안 키를 저장

PX 26 X.400 mail mapping information

GPOS 27 Geographical Position 도메인 네임의 지리적 위치정보 위도, 경도, 고도

AAAA 28 IP6 Address 128 bit IPv6 주소정보

LOC 29 Location Information

NXT 30 Next Domain

EID 31 Endpoint Identifier

NIMLOC 32 Nimrod Locator

SRV 33 Server Selection

ATMA 34 ATM Address

NAPTR 35 Naming Authority Pointer

KX 36 Key Exchanger

CERT 37 CERT

A6 38 A6 (IPv6 Address) IPv6 Prefix 및 주소정보 - 폐지

DNAME 39 DNAME A6과 함께 사용하는 도메인 매핑 정보 - 폐지

SINK 40 SINK 16


OPT 41 OPT

APL 42 APL

SSHFP 44 SSH Key Finger print

UINFO 100

UID 101

GID 102

UNSPEC 103

TKEY 249 Transaction Key DNS 질의에만 사용

TSIG 250 Transaction Signature DNS 질의에만 사용

IXFR 251 Incremental transfer DNS 질의에만 사용

AXFR 252 Transfer of an entire zone DNS 질의에만 사용

MAILB 253 mailbox-related RRs (MB, MG or MR) DNS 질의에만 사용

MAILA 254 Mailagent RRs (Obsolete - see MX) DNS 질의에만 사용

* 255 A request for all records DNS 질의에만 사용

17

도메인 위임 관련 RR : SOA & NS (1)

SOA(Start of a zone Of Authority) 도메인 존에 대한 정보를 표시 <Name><TTL><Class><Type=SOA><RDATA> RDATA :

<MNAME><RNAME><SERIAL><REFRESH><RETRY><EXPIRE><MINIMUM> <MNAME> : 해당 존의 최상위 마스터 네임서버(primary master name server)

도메인 네임을 지정하는 필드 해당 존에 대한 전적인 관리권한을 지닌 마스터 네임서버 DNS UPDATE와 같은 도메인 네임 및 자원 레코드의 동적 갱신이나 존 데이터 전송

메커니즘에 있어 중요한 역할 반드시 FQDN으로 표기

<RNAME> : 해당 존을 관리하는 담당자의 이메일 주소를 표기하는 필드 <SERIAL> : 해당 존의 변경에 따른 버전번호 정보 필드

존 내부의 데이터가 변경될 때마다 <SERIAL> 필드의 버전 번호는 하나 이상 증가 해당 존의 변경 여부를 파악할 수 있는 중요한 정보를 제공 수작업으로 변경 작업을 하는 경우에는 일반적으로 YYYYMMDDnn 의 형식으로 버전

번호를 관리 YYYY=년도, MM=월, DD=일, nn=일련번호

18


<REFRESH>, <RETRY>, <EXPIRE> : 존에 대한 정보를 갱신하는 메커니즘에 있어서의 타이머 시간 정보를 지정

<REFRESH> : 슬레이브 네임서버가 해당 존에 대한 변경 여부를 확인하는 주기

슬레이브 네임서버는 <REFRESH>에 지정된 주기로 마스터 네임서버에 대하여 대상 존(zone)의 SOA 리소스 레코드를 질의하여 <SERIAL> 버전이 자신이 알고 있는 <SERIAL> 버전을 기준으로 갱신 여부를 확인

<RETRY> : <REFRESH>에 의한 갱신 시도가 실패한 경우, 다시 존에 대한 갱신을 시도하는 타이머 시간

<RETRY> 값은 <REFRESH> 값보다는 작은 값

<EXPIRE> : 슬레이브 네임서버가 최상위 마스터 네임서버로 대상 존에 대한 갱신 여부 확인에 실패한 경우, 슬레이브에 존재하는 동일 존의 복사본을 어느 정도 시간만큼 유효한 것으로 유지할 것인가에 대한 설정 값

<RETRY>나 <MINIMUM> 값보다 큰 값으로 설정하며 일반적으로 권장하는 설정값은 2주～4주 정도

<MINIMUM> : 존에 속한 모든 자원 레코드의 디폴트 TTL(default TTL) 값을 지정

리졸버의 캐쉬에 리소스 레코드를 저장, 존속시키는 기간으로 사용

약 1～5일의 기간 설정 권장

하나의 존에 반드시 하나의 SOA 레코드 지정

19


NS(authoritative Name Server) 특정 도메인 존이 어느 네임서버에 위임되어 설정되어 있는지를

표시 <Name><TTL><Class><Type=NS><RDATA> RDATA : <NSDNAME>

<NSDNAME> : NS 레코드를 소유한 <Name>의 도메인 존을 가지고 있는 네임서버의 도메인 네임을 지정

FQDN의 도메인 네임을 설정 NS 레코드는 해당 존이 실제로 위치한 네임 서버를 도메인 네임으로

지정

NS RR의 2가지 용도 상위 도메인 존에서 위임되는 도메인 존의 네임서버 지정

NS RR과 네트워크 주소를 알려주는 A RR을 같이 저장

해당 존의 SOA 레코드와 함께 해당 존의 네임 서버 지정 SOA의 <MNAME>에 저장된 것이 마스터 서버이고 나머지는 슬레이브 서버 존 관리 동작(동적 갱신, 갱신 통보(NOTIFY), 존 데이터 전송 등)에 이용

20


21

<Name=example.co.kr.><TTL><Class><Type=NS><NSDNAME=ns1.example.co.kr.> <Name=example.co.kr.><TTL><Class><Type=NS><NSDNAME=ns2.example.co.kr.> <Name=ns1.example.co.kr.><TTL><Class><Type=A><ADDRESS=192.0.2.11> <Name=ns1.example.co.kr.><TTL><Class><Type=A><ADDRESS=192.0.2.12>

co.kr

<Name=example.co.kr.><TTL><Class><Type=SOA><MNAME=ns1.example.co.kr.> <RNAME><SERIAL><REFRESH><RETRY><EXPIRE><MINIMUM> <Name=example.co.kr.><TTL><Class><Type=NS><NSDNAME=ns1.example.co.kr.> <Name=example.co.kr.><TTL><Class><Type=NS><NSDNAME=ns2.example.co.kr.> <Name=ns1.example.co.kr.><TTL><Class><Type=A><ADDRESS=192.0.2.11> <Name=ns2.example.co.kr.><TTL><Class><Type=A><ADDRESS=192.0.2.12>

example.co.kr

위임

호스트 주소 관련 RR : A & AAAA

A RR : IPv4 주소 정보

<Name><TTL><Class=IN><Type=A><RDATA>

<RDATA> : <Address> 32 비트 IPv4 주소

AAAA RR : IPv6 주소 정보

<Name><TTL><Class=IN><Type=AAAA><RDATA>

<RDATA> : <Address> 128 비트 IPv6 주소

특정 도메인 네임에 대한 A 타입의 질의는 해당 도메인이 소유한 A RR만 응답하고, AAAA 타입의 질의에 대해서는 해당 도메인 네임이 소유한 AAAA RR 정보만 응답

임의의 도메인 네임이 IPv4 또는 IPv6 주소를 갖고 있는지의 여부는 A 타입의 질의와 AAAA 타입의 질의를 모두 수행하여 파악

22

전자우편 서비스 관련 RR : MX

메일 교환(Mail Exchange)을 의미하며 메일 서버의 정보

<Name><TTL><Class><Type=MX><RDATA>

<RDATA> : <PREFERENCE><EXCHANGE>

<PREFERENCE> : 우선순위를 지정하는 필드로 뒤에 지정되는 메일 서버에 대한 선호도를 지정 외부에서 메일을 전송하는 메일 서버는 가장 값이 적은 <PREFERENCE> 필드

값을 갖는 자원 레코드의 메일서버 도메인 네임을 선택

다수의 메일 서버를 운영하면서 우선순위 설정이 가능

<EXCHANGE> : 메일서버의 도메인 네임을 지정

MX 레코드에 대한 질의는 MX 레코드와 MX 레코드에 지정된 메일서버 도메인 네임의 IP 주소를 추가 정보로 응답

23

<Name=example.co.kr.><TTL><Class><Type=MX><PREFERENCE=10> <EXCHANGE=mail.example.co.kr.> <Name=mail.example.co.kr.><TTL><Class=IN><Type=A><ADDRESS=192.0.2.21>

example.co.kr

일반적인 DNS 도메인 위임설정 (1)

24

위임

example.co.kr. NS ns1.example.co.kr.



co.kr zone

example.co.kr. SOA ns1.example.co.kr.




….

Slave name server

Master name server

Slave name server

Kr

co

example

example

example

co.kr. Name server

recursive Name server

Name server ns1.example.co.kr.



DNS 질의

Master Name Server

Slave Name Server

Slave Name Server

ZONE TRANSFER

위임 Name Server 재시

Resolution 방향

example.co.kr. zone

일반적인 DNS 도메인 위임설정 (2)

도메인 co.kr.

example 노드를 생성하고 이 노드의 도메인 네임에 대해 NS RR 설정

현재 example.co.kr.에서는 3개의 네임서버를 사용 중이며, 각각을 NS RR로 설정

도메인 example.co.kr.

SOA 리소스 레코드의 <MNAME> 필드로 해당 도메인 존의 최상위 마스터 네임서버의 정보를 지정

현재 example.co.kr.에서는 3개의 네임서버를 사용 중이며, 각각을 NS RR로 설정

NS1이 마스터 서버로 동작하며, 나머지 서버는 슬레이브로 동작하여 Dynamic Update, Notify, Zone Transfer 등 구현

25

보안이 강화된 DNS 도메인 위임설정 (1)

26

위임



co.kr zone

example.co.kr. SOA ns1.example.co.kr.




….

Slave name server

Master name server

Slave name server

Kr

co

example

example

example

co.kr. Name server

recursive Name server




DNS 질의

Master Name Server

Slave Name Server

Slave Name Server

ZONE TRANSFER

위임 Name Server 재시

Resolution 방향

example.co.kr. zone

보안이 강화된 DNS 도메인 위임설정 (2)

도메인 존 example.co.kr.의 최상위 마스터 네임서버가 상위 도메인 co.kr.에서 NS 레코드로 지정되어 있지 않은 구성

리졸버에 의한 통상적인 리졸루션 절차에 있어서는 ns2.example.co.kr. 서버와 ns3.example.co.kr. 서버를 참조

도메인 존의 관리측면에 있어서는 ns1.example.co.kr. 서버에서 관리가 이루어지며 나머지 네임서버 ns2.example.co.kr.과 ns3.example.co.kr. 서버가 ns1.example.co.kr.의 마스터 존의 내용을 복사하여 DNS 서비스를 제공

최상위 마스터 네임서버가 방화벽 내부에 존재하고 외부 인터넷으로부터의 접근이 보안적 측면에서 차단되도록 설정하는 경우에 해당

Dynamic Update 메커니즘에서 마스터 네임서버에 직접 접근이 불가능하므로 슬레이브 네임서버로 DNS Dynamic Update 요청을 하고 해당 슬레이브 네임서버는 마스터 네임서버로 요청을 전달하는 방식으로 동작

27

DNS ZONE 관련 확장 – 기존 방법(AXFR) (1)

도메인 존을 2개 이상의 네임서버로 마스터 존과 이 마스터 존의 복사본인 슬레이브 존을 설정하는 구성이 가능

슬레이브 네임서버가 마스터 네임서버로 접근하여 마스터 존이 갱신되었는지의 여부를 확인하는 절차를 주기적으로 수행 (SOA RR에서 <REFRESH> 정의)

마스터 존의 SOA 레코드 <SERIAL> 필드 버전번호가 슬레이브 존의 <SERIAL> 번호보다 증가한 것을 확인한 경우, 마스터 네임서버에 대해 존 전송(zone transfer) 요청

AXFR ZONE TRANSFER : TCP 53번 포트를 사용하여 해당 도메인 존의 모든 내용을 전송

MCC Laboratory 28

DNS ZONE 관련 확장 – 기존 방법(AXFR) (2)

29

name server ns1.example.co.kr.



example

Master Name Server

example

Slave Name Server

example

Slave Name Server

TCP 53

UDP 53

UDP 53

UDP 53

TCP 53

DNS Query example.co.kr. SOA ?

DNS Query Response example.co.kr. AXFR <RR List>

example.co.kr. zone update

example.co.kr. zone SOA RR<REFRESH > expire

zone의 모든 RR 전송

DNS Query Example.co.kr.SOA?

Example.co.kr.zone SOARR <REFRESH> expire

DNS Query Response Example.co.kr.SOA <SERIAL>….

SOARR <SERIAL> check

DNS ZONE 관련 확장 – NOTIFY (1)

기존 방법에서는 마스터 존의 갱신이 있은 후 최대 <REFRESH>시간의 지연이 발생

마스터 네임서버가 마스터 존에 대한 수정 및 갱신이 발생한 경우, 그 존의 <SERIAL> 버전 번호를 증가시킨 후 SOA 레코드 정보를 모든 슬레이브 네임서버로 NOTIFY 메시지로 통보

모든 슬레이브 네임서버는 마스터 존에 대한 갱신이 발생한 시점에 마스터 존의 SOA 레코드 <SERIAL> 버전번호를 체크

도메인 존에 대한 갱신이 모든 슬레이브 네임서버로 신속한 전파와 반영이 가능

30

DNS ZONE 관련 확장 – NOTIFY (2)

31




example.co.kr. zone RR DATA update SOA RR <SERIAL> ++

example

Master Name Server

example

Slave Name Server

example

Slave Name Server

DNS Query (NOTIFY) example.co.kr SOA <SOA RR>

DNS Query Response (NOTIFY) example.co.kr SOA

DNS Query example.co.kr SOA RR Data

DNS Zone Transfer (AXFR/IXFR)

UDP 53

UDP 53

UDP 53

UDP 53

UDP 53

UDP 53

TCP 53

TCP 53

DNS Query example.co.kr SOA ?

DNS Query Response example.co.kr SOA RR Data

DNS Zone Transfer (AXFR/IXFR)

UDP 53

UDP 53 DNS Query example.co.kr SOA ?



DNS ZONE 관련 확장 – IXFR (1)

슬레이브 네임서버의 요청으로 모든 내용을 전송하는 AXFR과는 달리 마스터 네임서버에서 마스터 존의 변경된 요소 부분만 전송하는 메커니즘(NOTIFY와 같이 이용)

전송 DNS 메시지에서 <SOA 레코드><변경된 리소스 레코드><SOA 레코드>의 구조로 변경내역 데이터만 전송하여 슬레이브 네임서버가 해당 레코드의 변경 내역만 반영

UDP 포트 53번 / TCP 포트 53번 포트를 선택적으로 이용

IXFR 존 전송요청을 슬레이브 네임서버가 지원하지 못하는 경우에는 슬레이브 네임서버에서 동일한 존에 대해 AXFR 존 전송 요청

32

DNS ZONE 관련 확장 – IXFR (2)

33




example.co.kr. zone RR DATA update SOA RR <SERIAL> ++

example

Master Name Server

example

Slave Name Server

example

Slave Name Server

DNS NOTIFY

DNS Query & Response zone SOA ?

DNS Query Response example.co.kr. IXFR <RR DATA Updated Liists>

TCP 53

UDP 53 UDP 53

TCP 53

UDP 53

TCP 53

TCP 53

DNS Query example.co.kr. IXFR slave name server <SOA RR>

DNS Query Response example.co.kr. IXFR <RR DATA Updated Lists>

UDP 53

UDP 53

DNS Query example.co.kr. IXFR slave name server <SOA RR>



갱신된 RR 리스트만 전송함 SLAVE 서버의 SOA <SERIAL>을 참조하여 해당 <SERIAL> 버전까지의 갱신 RR 리스트 전송

DNS ZONE 관련 확장 – Dynamic Update (1)

네임서버에 대해 원하는 도메인 네임에 대한 자원 레코드의 생성, 삭제 요청을 함으로써 도메인 존에 대한 동적 갱신이 가능

진행 과정 대상 도메인 존이 설정되어 있는 마스터 네임서버의 위치를 파악하기 위한 절차

변경 대상 도메인 네임에 대해 SOA 타입 질의

변경 대상 도메인 네임과 자원 레코드에 대한 변경 절차

DNS 질의 메시지 헤더 플래그의 동작코드(operation code)를 Dynamic Update (5)로 설정하고 존 섹션(zone section)과 업데이트 섹션(update section)에 각각 수정 대상 도메인 존(zone), 수정 자원 레코드 내용으로 채워 해당 존의 마스터 네임서버로 전달

마스터 네임서버에 직접 접근이 불가능한 경우 슬레이브 네임서버에게 dynamic update 요구 전달

슬레이브 네임서버에서 마스터 네임서버에게 전달

반영 결과가 슬레이브 네임서버를 통해 제공

보안에 대한 고려 필요

34

DNS ZONE 관련 확장 – Dynamic Update (2)

35

Host

co.kr. name server

recursive name server




(1) DNS Query new.example.co.kr SOA ?

DNS Query Response <example.co.kr SOA RR>

example Master Name Server

example Slave Name Server

example Slave Name Server

kr

co

위임

ZONE TRANSFER

DNS Dynamic Update에 의한 변경 사항은 Zone Transfer에 의해 각 name server에 반영.

DNS Dynamic Update new.example.co.kr. 생성의 경우. 반드시 primary master name server에 update. <new.example.co.kr. 180 IN A 10.0.0.100> RR을 example.co.kr. zone의 master zone에 update.

(2) DNS DYNAMIC UPDATE new.example.co.kr. 180 IN A 10.0.0.100

DNS 확장 - EDNS0

DNS의 한계를 극복하기 위해 확장된 옵션 RR

하나의 예로서, DNS는 UDP 메시지로 질의 응답할 때, DNS 메시지 크기가 512 바이트를 초과할 수 없다는 한계

네임서버에서 DNS 응답을 할 때, 512 바이트를 초과하는 DNS 메시지가 생성되었다면, 네임서버는 DNS Header flag 중 TC(Truncation) 플래그를 1로 세팅하여 응답

TC 플래그가 세팅된 DNS 응답메시지를 받은 호스트는 이 응답 메시지를 폐기하고 동일한 내용의 DNS 질의를 TCP 53을 사용하여 재질의

EDNS0의 각 필드 중 buffer size를 지정하는 필드가 있으며, buffer size를 512 바이트 이상의 값, 즉 1024 byte, 2048 byte 등으로 지정하는 경우, 512 바이트 이상의 DNS 응답 메시지를 UDP로 수신 가능

36

2. ISC의 BIND ISC 소개 WWW.ISC.ORG 초기화면 OARC 소개 OARC.ISC.ORG 초기화면 Bind 8.x Bind 9.x Bind 설치 과정 Bind 설정하기 db.DOMAIN 파일 설정 db.ADDR 파일 설정 Bind 환경 설정 파일 영역 데이터 파일에서의 축약 사용 Bind 운영 Bind 관련 FAQ dig 사용법

37

http://www.isc.org/

ISC 소개

양질의 핵심 소프트웨어, 프로토콜, 운영 절차를 개발하고 유지함으로써 인터넷의 하부구조를 지원하기 위한 비영리 공익 집단

현재 ISC가 지원하고 있는 소프트웨어

BIND

DHCP

INN

OpenReg

Operations Analysis and Research Center (OARC)

DNS를 지원하기 위해 2003년 10월 결성

주기적으로 ISC Internet Domain Survey를 발표

BIND는 전세계 DNS 서버의 70% 이상 점유(2004년 기준)

설치 대수 2위 Microsoft DNS Server 21.7%

38

http://https:/oarc.isc.org/

http://www.isc.org/ops/ds/

WWW.ISC.ORG 초기 화면

39

http://www.isc.org/

OARC 소개 (1)

설립목적과 배경

루트 네임서버 운영자들과 선도 연구자들이 모여 신뢰할 수 있는 플랫폼을 구축하는 것이 목적

DNS의 신뢰성 있는 운영은 인터넷의 지속적인 운영을 위한 중요한 요구사항이며, DNS가 중단되면 인터넷 또한 중단되는 중요한 상황임에도 불구하고, DNS를 계속적으로 작동하게 하는 어떠한 공식적인 메커니즘이 존재하지 않다는 인식에서 출발

역할

정보의 공유와 분석을 위한 포럼과 플랫폼 제공

글로벌 DNS에 대한 공격 또는 위기상황이 나타나면 이에 대한 정보 공유를 위한 중립적 메커니즘 제공

구성원들 간의 글로벌 DNS의 운영의 이해를 위한 정보 공유

더욱 안전하고 신뢰성 있는 글로벌 하부구조 제공

40

OARC 소개 (2)

OARC의 기능 DNS와 관련된 공격이나 치명적인 사건에 대한 정보를 DNS 운영자 집단에게 신속히

전파하고 공유할 수 있는 신뢰할 수 있는 플랫폼 제공

ISC로부터의 여과된 채널을 통해 조기경고, 공격, 글로벌 DNS의 다른 고장에 대한 지속적인 분석 제공

입력 데이터를 분석하여 사고 상황과 이에 대한 가능한 해결방법(solution)에 대한 전문가 의견 제공

주요 네임서버의 부하와 성능을 측정 발표

DNS 구현이나 망 요소들의 테스트

DNS 성능에 대한 장기적인 분석

최종 사용자나 개발업체들에게 관련 중요 정보를 제공하는 교육 홍보 기능

주요 참여자 루트, TLD, 혹은 상용 DNS 서버의 운영자

DNS 소프트웨어나 망 장비 개발자

주요 정부 및 법 관련 기관

DNS에 관심이 많거나 전세계의 DNS 정보 흐름과 상태에 관심이 많은 연구자

41

dig 사용법 (1)

dig (Domain Information Groper) 개요

BIND DNS 배포 패키지에 기본적으로 포함된 DNS 진단용 유틸리티

DNS lookup 유틸리티의 일종

널리 사용되어 왔던 nslookup을 대체 nslookup에 비해 dig이 DNS의 추가 표준사항을 충실히 반영한 진단 도구

DNS 네임서버 구성과 도메인 설정이 완료된 후, 인터넷 일반 사용자의 입장에서 설정한 도메인네임에 대한 DNS 질의 응답이 정상적으로 이루어지는지 확인 점검

ISP 네트워크 관리자가 ADSL/VDSL 가입자의 장애현상에 대한 원인파악을 위해 DNS 네임서버 문제 여부 진단

Unix나 Linux 계열 OS에는 dig이 포함, OS 설치 시에 기본적 설치

Windows 계열 OS 경우, BIND DNS 설치패키지를 다운로드 후 설치 필요

42

dig 사용법 (2)

도메인네임에 대한 질의 형식 : dig [@server] [name] [type]

server DNS 질의를 할 대상 네임서버

네임서버의 도메인네임(domain name) 또는 IP 주소 지정

IP 주소 지정의 경우 IPv4 주소 또는 IPv6 주소 지정 가능

name 질의 대상 도메인 네임

지정하지 않은 경우 : 루트 도메인(.)에 대해서 질의

type 질의 타입

지정하지 않은 경우

name이 지정되지 않은 경우: 루트 도메인(.)의 NS 타입 질의

name이 지정된 경우: 지정된 도메인네임의 A 타입 질의

43

dig 사용법 (3) 사용 예:

[root@lily 13u1]# dig mmu.ac.kr A ; <<>> DiG 9.8.4-P1-RedHat-9.8.4-3.P1.fc16 <<>> mmu.ac.kr A ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41848 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mmu.ac.kr. IN A ;; ANSWER SECTION: mmu.ac.kr. 3600 IN A 202.30.49.100 ;; Query time: 0 msec ;; SERVER: 203.232.248.5#53(203.232.248.5) ;; WHEN: Mon Apr 29 10:28:19 2013 ;; MSG SIZE rcvd: 43

44

dig 사용법 (4)

IP 주소(IPv4, IPv6)에 대한 역변환 질의

형식 : dig [@server] -x ip_address

-x ip_address 역변환 질의 대상 IP 주소 지정

IPv4의 경우: in-addr.arpa. 도메인네임으로 변환 후 질의

IPv6의 경우: ip6.arpa. 도메인네임으로 변환 후 질의

45

dig 사용법 (5) 사용 예: IPv4 주소 역변환

# dig -x 203.232.252.110 ; <<>> DiG 9.8.4-P1-RedHat-9.8.4-3.P1.fc16 <<>> -x 203.232.252.110 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4037 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;110.252.232.203.in-addr.arpa. IN PTR ;; ANSWER SECTION: 110.252.232.203.in-addr.arpa. 3600 IN PTR lily.mmu.ac.kr. ;; Query time: 0 msec ;; SERVER: 203.232.248.5#53(203.232.248.5) ;; WHEN: Mon Apr 29 10:29:42 2013 ;; MSG SIZE rcvd: 74

46

dig 사용법 (6) 사용 예: IPv6 주소 역변환

# dig -x 2001:6b0:1:ea:a00:20ff:fe8f:708f ; <<>> DiG 9.8.4-P1-RedHat-9.8.4-3.P1.fc16 <<>> -x 2001:6b0:1:ea:a00:20ff:fe8f:708f ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51837 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; QUESTION SECTION: ;f.8.0.7.f.8.e.f.f.f.0.2.0.0.a.0.a.e.0.0.1.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa. IN PTR ;; ANSWER SECTION: f.8.0.7.f.8.e.f.f.f.0.2.0.0.a.0.a.e.0.0.1.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa. 3600 IN PTR renskav.stacken.kth.se. ;; AUTHORITY SECTION: a.e.0.0.1.0.0.0.0.b.6.0.1.0.0.2.ip6.arpa. 3600 IN NS ns.stacken.kth.se. ;; ADDITIONAL SECTION: ns.stacken.kth.se. 2047 IN A 130.237.234.17 ns.stacken.kth.se. 5646 IN AAAA 2001:6b0:1:ea::100 ;; Query time: 1232 msec ;; SERVER: 203.232.248.5#53(203.232.248.5) ;; WHEN: Mon Apr 29 10:30:36 2013 ;; MSG SIZE rcvd: 187

47

dig 사용법 (7)

dig 질의결과 출력내용 분석 dig 출력내용은 DNS 메시지의 Header, Question Section, Answer Section, Authority

Section, Addition Section의 구조에 맞추어 출력

끝 부분에 dig이 첨가하는 부가적인 정보로써 DNS 응답소요 시간, DNS 응답서버 정보, DNS 메시지 사이즈 정보 등을 출력

; <<>> DiG 9.2.3 <<>> www.nic.or.kr A

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

opcode: DNS 응답 메시지의 operation code

QUERY : Standard Query

IQUERY : Inverse Query (현재는 사용 않음)

STATUS : Server Status Request

NOTIFY : DNS Notify Message

UPDATE : DNS Dynamic Update Message

48

dig 사용법 (8) status: DNS 응답메시지의 RCODE(Response Code) 표시

NOERROR : No Error [Standard Query] FORMERR : Format Error [Standard Query] SERVFAIL : Server Failure [Standard Query] NXDOMAIN : Non-Existent Domain [Standard Query] NOTIMP : Not Implemented [Standard Query] REFUSED : Query Refused [Standard Query] YXDOMAIN : Name Exists when it should not [DNS UPDATE] YXRRSET : RR Set Exists when it should not [DNS UPDATE] NXRRSET : RR Set that should exist does not [DNS UPDATE] NOTAUTH : Server Not Authoritative for zone [DNS UPDATE] NOTZONE : Name not contained in zone [DNS UPDATE] BADVERS : Bad OPT Version [EDNS0]

id: DNS transaction ID를 표시 flags: DNS Header Section의 flag 필드 값 표시

qr : Query/Response bit (set = Response) rd : Recursion Desired (set = Recursion Desired) ra : Recursion Available (set = Recursion Available, Server) tc : Truncation (set = Message is truncated) aa : Authoritative Answer (set = Authoritative Answer) ad : 확장 flag, Authentic Data cd : 확장 flag, Checking Disabled

49

dig 사용법 (9) QUERY: DNS Query Section의 RR 개수 (항상 1) ANSWER: DNS Answer Section의 RR 개수 AUTHORITY: DNS Authority Section의 RR 개수 ADDITIONAL: DNS Additional Section의 RR 개수

;; QUESTION SECTION: ;www.nic.or.kr. IN A

;; ANSWER SECTION: www.nic.or.kr. 1772 IN A 202.30.50.90

;; AUTHORITY SECTION: nic.or.kr. 1798 IN NS ns2.nic.or.kr. nic.or.kr. 1798 IN NS ns1.nic.or.kr.

;; ADDITIONAL SECTION: ns1.nic.or.kr. 1791 IN A 202.30.50.51 ns2.nic.or.kr. 1798 IN A 220.73.220.113

50

dig 사용법 (10) ;; QUESTION SECTION: DNS 질의 내용을 표시 ;; ANSWER SECTION: DNS 질의 사항에 대한 DNS 응답 RR을

표시 ;; AUTHORITY SECTION: DNS 응답 RR이 속한 도메인 존의 NS

RR 정보 ;; ADDITIONAL SECTION: 부가적인 RR 정보를 표시

;; Query time: 100 msec ;; SERVER: 202.31.190.222#53(202.31.190.222) ;; WHEN: Wed Jun 23 19:18:52 2004 ;; MSG SIZE rcvd: 115

;; Query time: DNS 질의 메시지 발송시점에서 응답시점까지의 소요시간

;; SERVER: DNS 응답 메시지를 보내온 질의응답 네임서버 ;; WHEN: DNS 응답 메시지를 받은 시점의 date & time ;; MSG SIZE rcvd: 응답 받은 DNS 메시지의 size 표시 (byte 단위)

51

3. IPv6와 DNSv6

IPv6 개요

DNSv6 개요

IPv6 DNS 시스템 구성을 위한 사전 검토 사항

IPv6 DNS 설치 및 구동

IPv6 DNS FAQ

IPv6 Socket Programming

IPv6 DNS 이용 Programming 예제

Dual stack IPv6 server의 서비스 제공

UNIX 계열에서 수신된 IPv4/IPv6 데이터그램 처리

UNIX 계열에서 요청된 IPv4/IPv6 데이터그램 처리

52

IPv6 개요 (1)

IPv6 탄생 배경

1980년대 후반 주소 고갈 문제 예상

초기에는 주소 필드의 확장만 논의했으나, 아무리 사소한 수정이라도 전체 망 구조에 큰 영향을 미친다는 사실을 깨닫고 근본적인 수정에 착수

IPv6 주소는 IPv4 주소 길이의 4배인 128비트로 43억× 43억× 43억× 43억 개의 주소 제공이 가능. (지구상의 모든 인간이 10억개의 노드로 이루어진 개인 망을 가질 때, 이러한 지구와 같은 행성 50억× 50억 개를 연결 가능)

IPv6의 개선 분야

확장된 주소

간소한 헤더 형식

개선된 확장과 옵션 지원

흐름 라벨링

인증과 비밀성 제공

MCC Laboratory 53

IPv6 개요 (2)

54

IPv4 Header

Ver TOS HELN Total Length Identification flags Fragment Offset

TTL Protocol Header checksum Source IP Address

Destination IP Address

32 bit

4 bit 4 bit 8 bit 16 bit

HLEN = Header Length TOS = Type of Service 헤더 길이 = 20 octets(bytes) + options

IPv6 Header

헤더 길이 = 40 octets(bytes)

Ver Traffic Class Flow Level

Source IP Address

Destination IP Address

Payload Length Hop Limit Next Header

DNSv6 개요 (1)

IPv6를 지원하기 위한 변화와 문제점 ip6.arpa. 도메인 추가

각 레이블은 8 bit 단위의 16진수 표기 단위 이용 예: 2001:2b8:3b:1::100의 경우 0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.b.3.0.0.8.b.2.0.1.0.0.2.ip6.arpa.

IPv6 주소를 지정할 수 있는 신규 RR 정의 : AAAA RR

55

존 파일 (zone file) 표기

www.example.co.kr. 1800 IN A 192.0.2.101 www.example.co.kr. 1800 IN AAAA 2001::2b8:3b::100

A 리소스 레크드 포맷

Name Type Class TTL Data Length

32 bit

010000011…10101

AAAA 리소스 레크드 포맷

Name Type Class TTL Data Length Address

Address

128 bit

0100000101…0100010101

http://www.example.co.kr/

http://www.example.co.kr/

DNSv6 개요 (2)

리졸버에 의한 비재귀적 질의(iterative query)에 대해 네임서버 NS RR과 glue RR 응답 시 IPv4 주소의 A RR과 IPv6 주소의 AAAA RR을 모두 포함하여 응답

특정 도메인 네임의 IP 주소를 파악하기 위해서 A 타입 DNS 질의와 AAAA 타입 DNS 질의를 각각 수행하여 응답을 파악 하나의 도메인 네임에 대한 A 타입 DNS 질의는 A RR만 응답

하나의 도메인 네임에 대한 AAAA 타입 DNS 질의는 AAAA RR만 응답

각 호스트가 IPv4/IPv6 듀얼스택 호스트로 서비스하고 있는 경우 다수의 A RR과 AAAA RR이 네임에 지정됨으로써 DNS 응답 메시지의 길이가 512 바이트를 초과하는 경우 발생 TCP를 사용한 DNS 질의절차로 전환하는 메커니즘을 유발

DNS 질의상의 지연과 네임서버 시스템 부하 증가 문제

리졸버의 캐쉬 관리에서 IPv6 주소의 AAAA RR로 인해 소요되는 메모리 증가

IPv6 Socket API 사용 필요

56

DNSv6 개요 (3)

IPv6의 도입에 따른 DNS 변화 도메인 데이터베이스의 확장

AAAA RR 도입

리졸버의 입장에서는 IPv4 주소와 IPv6 주소가 공존하는 도메인 데이터베이스에서 임의의 도메인 네임에 대한 네트워크 주소정보를 파악하기 위해서는 A 타입 리소스 레코드에 대한 DNS 질의와 AAAA 타입 리소스 레코드에 대한 DNS 질의를 각각 수행

IPv6의 도입으로 인해 IPv6 주소를 갖는 네임서버가 존재하게 되며 네임서버로의 위임 설정이 IPv6 주소로 설정되는 경우가 존재

상위 도메인에는 위임되는 도메인에 대한 글루 레코드(glue record) 정보로써 필요한 네임서버의 IPv4 주소와 IPv6 주소를 각각 A 타입 레코드와 AAAA 타입 레코드로 설정

DNS의 기반 네트워크 환경에 IPv6 네트워크 적용

상당한 기간 동안 IPv4와 IPv6가 공존하는 상태의 네트워크 환경에서 DNS가 설치, 운영될 예정

기존의 IPv4와 새로운 IPv6 영역 모두에게 보편적으로 동일한 DNS 서비스를 제공하여야 하는 요구사항

DNS 도메인 네임공간이 IPv4와 IPv6 영역에 의해 분할되는 일이 발생하지 않도록 하는 문제가 가장 중요

DNS 네임서버에 존재하는 도메인 데이터베이스의 트리 구조 상에 상호 연결성이 파괴될 위험 상존

57

DNSv6 개요 (4)

IPv4 -> IPv6 전환 단계에서의 주요 이슈

58

DNSv6 개요 (5)

DNS 도메인 네임공간의 연속성 유지 문제

59

DNSv6 개요 (6)

IPv6 only 리커시브 네임서버의 리졸루션 불능문제

60

DNSv6 개요 (7)

IPv4 only 리커시브 네임서버의 리졸루션 불능문제

61

DNSv6 개요 (8)

IPv4 및 IPv6 환경에서의 DNS 체계 구성방안

62

DNSv6 개요 (9)

EDNS0 도입

루트 도메인의 IPv6 주소를 지정한 위임설정은 512 바이트로 제한된 DNS 메시지 크기 제한에 의해 기술적 문제 발생

이에 대한 해결책 중 하나가 EDNS0

DNS 프로토콜의 확장을 지정하는 필드 중에는 UDP 전송가능 크기를 512 바이트 이상으로 지정하여 1024 바이트 또는 2048 바이트 등으로 지정

현실적으로는 전 세계 모든 리졸버와 네임서버가 EDNS 기능을 지원하지 는 않고 있다는 점이 문제점

IPv6 프로토콜 변환방식으로 인한 문제

DNS 서버 시스템과는 직접적으로 무관

DNS 질의에 대한 변환기능을 사용하는 전환기술이 존재하고 이에 DNS 메커니즘을 활용하기 때문에 관련된 사항

NAT-PT 네트워크나 RTR 네트워크를 구성하는 경우 이에 대한 사항을 시스템 OS 별로 사전에 확인할 필요성 존재

63

IPv6 DNS 시스템 구성을 위한 사전 검토 사항

네트워크 IPv6 네트워크 구성 여부 결정 IPv6 연동방식 결정 IPv6 주소 확보 방식 결정

DNS 서버시스템 IPv6 지원 플랫폼 확인 IPv6 주소 설정 방식 검토 IPv6 tunnel 지원 항목 확인

DNS Software IPv6 인터페이스 지원여부 확인 IPv6 확장 DNS 구현여부 확인 기타 IPv6 관련 제한사항 확인

IPv6 전환기술 Pv6 전환기술 사용여부 결정 DNS-ALG 적용 필요여부 결정

64

IPv6 DNS 설치 및 구동 (1) IPv6 인터페이스에 대해 DNS 서비스를 제공해야 하므로 이에 대한 설정을 named.conf 파일에 추가

options { directory "/var/named/"; pid-file "/var/run/named.pid"; listen-on-v6 { any;}; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; }; zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" { type master; file "localhost.ipv6.zone"; }; zone "." { type hint; file "root.cache"; }; zone "example.co.kr" { type master; file "example.co.kr.zone"; };

65

IPv6 DNS 설치 및 구동 (2) IPv6 루프백 주소 '::1/128'에 대한 리버스(reverse) 도메인 존

파일 설정 파일 명 : 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. ip6.arpa $ORIGIN 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int. $TTL 180 @ IN SOA localhost. root.localhost. ( 2003071502 ;Serial 21600 ;Refresh ( 6 hours) 1800 ;Retry (30 minutes) 1209600 ;Expire (14 days) 86400) ;Minimum ( 1 day) IN NS rootdns.dnsv6.or.kr. IN PTR localhost.

66

IPv6 DNS 설치 및 구동 (3) IPv6 DNS 도메인 구성

IPv6 주소가 포함된 example.co.kr. 존 파일 $ORIGIN example.co.kr. $TTL 86400 @ IN SOA ns1.example.co.kr. admin.example.co.kr. ( 2003082809 ; serial 21600 ; Refresh (6 hours) 1800 ; Retry (30 min) 1209600 ; expire (14 days) 86400 ; mininum (1 day) ) IN NS ns1 IN NS ns2 IN MX 10 mail ns1 IN A 192.0.2.11 ns1 IN AAAA 2001:3b8:2a::100 ns2 IN A 192.0.2.12 ns2 IN AAAA 2001:3b8:2a::200 www IN A 192.0.2.101 www IN A 192.0.2.102 www IN AAAA 2001:2b8:2a:1:a00:20ff:fed1:3e21 mail IN A 192.0.2.21

67

IPv6 DNS 설치 및 구동 (4) IPv6 주소가 포함된 example.co.kr.의 리버스 존 파일

$ORIGIN a.2.0.0.8.b.2.0.1.0.0.2.ip6.arpa. $TTL 180 @ IN SOA ns1.example.co.kr. admin.example.co.kr. ( 2003071501 ;Serial 21600 ;Refresh ( 6 hours) 1800 ;Retry (30 minutes) 1209600 ;Expire (14 days) 86400) ;Minimum ( 1 day) IN NS ns1.example.co.kr. IN NS ns2.example.co.kr. $ORIGIN 0.0.0.0.a.2.0.0.8.b.2.0.1.0.0.2.ip6.arpa. 0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns1.example.co.kr. 0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ns2.example.co.kr. $ORIGIN 1.0.0.0.a.2.0.0.8.b.2.0.1.0.0.2.ip6.arpa. 1.2.e.3.1.d.e.f.f.f.0.2.0.0.a.0 IN PTR www.example.co.kr.

68

IPv6 DNS 설치 및 구동 (5)

리버스 존 파일 named.conf에 반영 zone "a.2.0.0.8.b.2.0.1.0.0.2.ip6.arpa." {

type master;

file "2001.2b8.2a.ip6.rev.zone";

};

69

IPv6 DNS FAQ (1)

IPv6 인터페이스를 가지고 있는 호스트를 추가하려면? 영역 파일에 AAAA RR을 이용하여 매핑 정보 입력

예:

host-v6.example.co.kr. IN AAAA 124:4567:89ab:cdef:123:4567:89ab:cdef

리버스 존 파일(f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.ip6.arpa)에 PTR RR 추가

네임 서버가 IPv6 인터페이스를 통해 들어온 질의를 처리 하도록 하려면? named.conf 파일 설정

예:

options {

directory "/var/named"

listen-on-v6 { any; };

}

포트 번호 설정 예:

options {


listen-on-v6 port 1053 { any; };

}

70

IPv6 DNS FAQ (2)

특정 IPv6 주소로부터 질의를 보내도록 네임 서버를 설정하려면 ?

질의를 보낼 때 이용할 IPv6 주소와 포트 설정 가능

예:

options {


query-source-v6 address 222:10:2521:1:210:4bff:fe01:d32;

}

예:

options {


query-source-v6 address 222:10:2521:1:210:4bff:fe01:d32 port 5555;

}

71

IPv6 Socket Programming (1) Socket Address 구조체의 변화

일반적인 Socket 구조체 struct sockaddr { uint8_t sa_len; sa_family_t sa_family; /* address family : AF_xxx */ char sa_data[14]; /* protocol specific address */ };

IPv4 Socket 구조체 struct in_addr { in_addr_t s_addr; }; struct sockaddr_in { uint8_t sin_len; /* length of structure */ sa_family_t sin_family; /* AF_INET */ in_port_t sin_port; /* 16-bit TCP or UDP port number */ struct in_addr sin_addr; /* 32-bit IPv4 address */ char sin_zero[8]; /* unused */ };

72

IPv6 Socket Programming (2) IPv6 Socket 구조체

struct in6_addr { uint8_t s6_addr[16]; /* IPv6 address */ }; struct sockaddr_in6 { /* 4.3BSD-based system */ sa_family_t sin6_family; /* AF_INET6 */ in_port_t sin6_port; /* transport layer port # */ uint32_t sin6_flowinfo; /* IPv6 flow information */ struct in6_addr sin6_addr; /* IPv6 address */ uint32_t sin6_scope_id; /* set of interfaces for a scope */ }; struct sockaddr_in6 { /* 4.4BSD-based system */ uint8_t sin6_len; /* length of this struct */ sa_family_t sin6_family; /* AF_INET6 */ in_port_t sin6_port; /* transport layer port # */ uint32_t sin6_flowinfo; /* IPv6 flow information */ struct in6_addr sin6_addr; /* IPv6 address */ uint32_t sin6_scope_id; /* set of interfaces for a scope */ };

73

IPv6 Socket Programming (3)

IPv4 와 IPv6 소켓 구조체 비교

74


소켓 주소 호환을 위한 새로운 자료구조

struct sockaddr_storage : 특정 IP 버전에 종속되지 않는 프로그램 작성을 위하여 sockaddr_storage의 사용이 권고

/*

* Desired design of maximum size and alignment

*/

#define _SS_MAXSIZE 128 /* Implementation specific max size */

#define _SS_ALIGNSIZE (sizeof (int64_t)) /* Implementation specific desired alignment */

75

IPv6 Socket Programming (5) /* * Definitions used for sockaddr_storage structure paddings design. */ #define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) #define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t) + _SS_PAD1SIZE + _SS_ALIGNSIZE)) struct sockaddr_storage { sa_family_t ss_family; /* address family */ /* Following fields are implementation specific */ char __ss_pad1[_SS_PAD1SIZE]; /* 6 byte pad, this is to make implementation /* specific pad up to alignment field that */ /* follows explicit in the data structure */ int64_t __ss_align; /* field to force desired structure */ /* storage alignment */ char __ss_pad2[_SS_PAD2SIZE]; /* 112 byte pad to achieve desired size, */ /* _SS_MAXSIZE value minus size of ss_family */ /* __ss_pad1, __ss_align fields is 112 */ };

76

IPv6 Socket Programming (6) /* * Definitions used for sockaddr_storage structure paddings design. */ #define _SS_PAD1SIZE (_SS_ALIGNSIZE - (sizeof (uint8_t) + sizeof (sa_family_t)) #define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (uint8_t) + sizeof (sa_family_t) + _SS_PAD1SIZE + _SS_ALIGNSIZE)) struct sockaddr_storage { uint8_t ss_len; /* address length */ sa_family_t ss_family; /* address family */ /* Following fields are implementation specific */ char __ss_pad1[_SS_PAD1SIZE]; /* 6 byte pad, this is to make implementation /* specific pad up to alignment field that */ /* follows explicit in the data structure */ int64_t __ss_align; /* field to force desired structure */ /* storage alignment */ char __ss_pad2[_SS_PAD2SIZE]; /* 112 byte pad to achieve desired size, */ /* _SS_MAXSIZE value minus size of ss_len, */ /* __ss_family, __ss_pad1, __ss_align fields is 112 */ };

77

IPv6 Socket Programming (7) Socket 주소 관련 API 변화

기존의 Socket 주소 관련 함수 #include <arpa/inet.h> in_addr_t inet_addr(const char *strptr); int inet_aton(const char *strptr, struct in_addr *addrptr); char *inet_ntoa(struct in_addr inaddr);

호스트 이름들을 얻기 위한 함수 #include <netdb.h> struct hostent *gethostbyname (const char *hostname); struct hostent { char *h_name; char **h_aliases; int h_addrtype; int h_length; char **h_addr_list; }; #define h_addr h_addr_list[0]

78


hostent 구조체

79

IPv6 Socket Programming (9) 추가된 소켓 주소 관련 함수

#include <sys/socket.h>

#include <netdb.h>

int getaddrinfo (const char *nodename, const char *servname,

const struct addrinfo *hints, struct addrinfo **res);

void freeaddrinfo(struct addrinfo *ai);

char *gai_strerror(int error);

struct addrinfo {

int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, .. */

int ai_family; /* AF_xxx */

int ai_socktype; /* SOCK_xxx */

int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */

socklen_t ai_addrlen; /* length of ai_addr */

char *ai_canonname; /* canonical name for nodename */

struct sockaddr *ai_addr; /* binary address */

struct addrinfo *ai_next; /* next structure in linked list */

};

int getnameinfo (const struct sockaddr *sa, socklen_t salen, char *node,

socklen_t nodelen, char *service, socklen_t servicelen, int flags);

80


addr_info 구조체

81

IPv6 Socket Programming (11) getaddrinfo( ) : 호스트 이름과 서비스 이름을 받아 소켓 주소와 그와

연관된 정보들 반환

freeaddrinfo( ) : getaddrinfo 함수가 돌려주는 addrinfo 구조체를 해제시키기 위해 추가

getnameinfo( ) : 소켓 주소를 받아 노드 이름과 서비스 이름 반환

IPv4의 inet_addr( ), inet_ntoa( ) 함수에 대응하는 두 개의 함수 inet_pton( ), inet_ntop( ) 추가

#include <arpa/inet.h>

int inet_pton(int af, const char *src, void *dst);

const char *inet_ntop(int af, const void *src, char *dst, socklen_t size);

#define INET_ADDRSTRLEN 16

#define INET6_ADDRSTRLEN 46

82

IPv6 Socket Programming (12) 추가된 socket 주소 테스트 매크로

#include <netinet/in.h>

int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *); int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *); int IN6_IS_ADDR_MULTICAST (const struct in6_addr *); int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *); int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *); int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *); int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *);

int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *); int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *);

83


IPv6 TCP Program header file

sample6.h #include <stdio.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#define SERV_TCP_PORT 6000

#define SERV_HOST_ADDR "fe80::250:8bff:fe94:bf13"

#define LOOPBACK_ADDR "::1"

84

IPv6 Socket Programming (14) IPv6 TCP Client Program Sample

#include "sample6.h" main(int argc, char *argv[]) { int sockfd; struct sockaddr_in6 serv_addr; bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin6_family = AF_INET6; inet_pton(AF_INET6,SERV_HOST_ADDR, &serv_addr.sin6_addr); /* inet_pton(AF_INET6,LOOPBACK_ADDR, &serv_addr.sin6_addr); */ /* IPv6 loopback */ serv_addr.sin6_port = htons(SERV_TCP_PORT); if ( (sockfd = socket(AF_INET6, SOCK_STREAM, 0)) < 0) fprintf(stderr, "client: can't open stream socket"); /* 이하 생략 */

85

IPv6 Socket Programming (15) IPv6 TCP Server Program Sample

#include "sample6.h"

main(int argc, char *argv[])

{

int sockfd, newsockfd, clilen, childpid;

struct sockaddr_in6 cli_addr, serv_addr;

if ( (sockfd = socket(AF_INET6, SOCK_STREAM, 0)) < 0)

fprintf(stderr,"server: can't open stream socket");

bzero((char *) &serv_addr, sizeof(serv_addr));

serv_addr.sin6_family = AF_INET6;

serv_addr.sin6_addr = in6addr_any;

serv_addr.sin6_port = htons(SERV_TCP_PORT);

if (bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0)

fprintf(stderr,"server: can't bind local address");

listen(sockfd, 5);

/* 이하 생략 */

86

IPv6 Socket Programming (16) UNIX 계열에서 getaddrinfo() 이용 예제

#include <ctype.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> main(int argc, char *argv[]) { struct addrinfo hints, *result; struct addrinfo *tmp; int err_code; if (argc < 3) { fprintf(stderr, "usage : %s hostname service [6|4]\n", argv[0]); exit(1); }

87

IPv6 Socket Programming (17) memset(&hints, 0, sizeof(hints)); hints.ai_socktype = SOCK_STREAM; hints.ai_protocol = IPPROTO_TCP; if (isalpha(argv[1][0])) { hints.ai_flags = AI_CANONNAME; } else { hints.ai_flags = AI_NUMERICHOST; } if (argc > 3) { if (strcmp(argv[3], "6") == 0) { hints.ai_family = AF_INET6; } else { hints.ai_family = AF_INET; } } else { hints.ai_family = AF_UNSPEC; }

88

IPv6 Socket Programming (18) if (err_code = getaddrinfo(argv[1], argv[2], &hints, &result)) { fprintf(stderr, "error in getaddrinfo() : %s\n", gai_strerror(err_code)); exit(2); } if (result->ai_canonname) { printf("canonnical name : %s\n", result->ai_canonname); } for(tmp = result->ai_next; tmp; tmp = tmp->ai_next) { printf("canonnical name : %s\n", result->ai_next->ai_canonname); } freeaddrinfo(result); }

89

IPv6 Socket Programming (19) IP 버전에 독립적인 UNIX TCP 클라이언트

#include <stdio.h> #include <ctype.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #define MAXLINE 1024 int main(int argc, char *argv[]) { struct addrinfo hints, *result; struct addrinfo *tmp; int err_code; int sockfd; char buf[MAXLINE]; int n;

90

IPv6 Socket Programming (20) if (argc < 3) {

fprintf(stderr, "usage : %s hostname port_no\n", argv[0]);

exit(1);

}

memset(&hints, 0, sizeof(hints));

hints.ai_socktype = SOCK_STREAM;

hints.ai_protocol = IPPROTO_TCP;

if (isalpha(argv[1][0])) {

hints.ai_flags = AI_CANONNAME;

}

else {

hints.ai_flags = AI_NUMERICHOST;

}

hints.ai_family = AF_UNSPEC;

if (err_code = getaddrinfo(argv[1], argv[2], &hints, &result)) {

fprintf(stderr, "error in getaddrinfo() : %s\n", gai_strerror(err_code));

91

IPv6 Socket Programming (21) exit(2); } print_addr_info(result); for (tmp = result; tmp; tmp = tmp->ai_next) { if ((sockfd = socket(tmp->ai_family, tmp->ai_socktype, tmp->ai_protocol)) <= 0) { fprintf(stderr, "error in socket()\n"); } else { err_code = connect(sockfd, tmp->ai_addr, tmp->ai_addrlen); if (err_code < 0) { fprintf(stderr, "error in connect()\n"); } else { /* client process */ /* 키보드 입력을 소켓을 통해 서버로 전달 */ /* 소켓으로 온 서버 응답을 화면에 출력 */

92

IPv6 Socket Programming (22) while(fgets(buf, MAXLINE, stdin)) { write(sockfd, buf, strlen(buf)); n = read(sockfd, buf, MAXLINE); if (n <= 0) { fprintf(stderr, "end of connection or read error\n"); break; } else { buf[n] = '\0'; fputs(buf, stdout); } } } break; /* 정상적인 연결이므로 반복 탈출 */ } /* 연결이 안 된 경우 다음 주소로 다시 시도 */ } freeaddrinfo(result); close(sockfd); }

93

Dual stack IPv6 server의 서비스 제공

94

UNIX 계열에서 수신된 IPv4/IPv6 데이터그램 처리

95

UNIX 계열에서 요청된 IPv4/IPv6 데이터그램 처리

96

4. DNS 보안 강화

DNS 보안 위협 분석 DNSSEC 관련 주요 용어 정의 DNSSEC 구성 요소 및 기본 구조 기존 Security-Oblivious DNS와의 공존체계 DNSSEC과 EDNS0의 UDP payload size NSEC RR 관련 문제 DNSSEC에서의 서명 및 검증 DNSSEC RR 포맷 및 기능 도메인에 대한 DNSSEC 적용 DNSSEC 응답사례에 대한 분석 현 시점에서 DNSSEC 도입 시 문제점 TSIG, SIG(0)

97

DNS 보안 위협 분석 (1)

배경

1993년 28th IETF 회의에서 처음 논의

28th IETF 회의 합의 사항

일부 참여자가 DNS 데이터가 권한이 없는 사용자에게도 공개되는 문제를 방어하기를 제안했으나 DNS 데이터 자체가 ‘public’이므로 이에 대한 대책은 강구하지 않기로 결정

일부 참여자가 접근 제한에 기반을 둔 DNS 클라이언트와 서버의 인증에 관심을 보였으나 이것도 DNSSEC의 영역 밖으로 합의

DNSSEC에서 제공하고자 하는 보안 서비스 데이터 무결성(integrity)

데이터 근원지 인증(authentication)

앞서 언급한 서비스는 디지털 서명으로 가능하리라고 결론

채널 보안을 지원하는 TKEY, TSIG 메커니즘은 DNSSEC과는 별도로 추진

98


알려진 위협 패킷 가로채기 (Packet Interception)

가장 간단한 공격유형으로, ‘monkey-in-the-middle’ 공격 등이 대표적

원인 : DNS가 전체 질의/응답 메시지를 주고받을 때, 전혀 암호화되지 않은 UDP 패킷을 사용하기 때문

TSIG나 IPSec과 같은 채널 보안 메커니즘을 이용할 수 있으나 DNS 메시지당 처리 비용이 커지고 홉마다 이를 확인하려면 전체 비용이 급격히 커지는 문제 : 종단간 데이터 무결성을 확인하는 DNSSEC을 적용하면 적절한 비용에 가능

DNSSEC을 적용해도 DNS 메시지 헤더의 수정에 취약하므로 다음 방법 적용 고려

DNSSEC 서명 확인 작업 수행

TSIG 이용

패킷마다 재서명

ID 추측과 질의 예측 (ID Guessing and Query Prediction)

DNS 헤더의 ID 필드는 16비트로 구성되고 DNS 서비스가 잘 알려진 포트를 이용하므로, 대입법(Brute force search)을 통해서 값 추측 가능

ID외에도 QNAME과 QTYPE을 같이 추측해야 공격이 가능

서버에 대한 인증 메커니즘으로 방어 가능

99

DNS 보안 위협 분석 (3) 이름 체인 (Name Chaining)

“캐쉬 오염(cache poisoning)” 공격이라고 부르는 이름기반 공격의 일부

공격자가 피 공격자의 캐쉬에 특정 RRs를 위․변조하여 악의적인 데이터를 공급함으로써 잠재적으로 DNS 이름을 기반으로 하는 뒤이은 오퍼레이션들에 대한 잘못된 판단을 유발

신뢰받는 서버로 위장 (Betrayal By Trusted Server)

패킷 가로채기 공격의 변형

신뢰받는 서버가 사고나 혹은 의도된 조작으로 인해 리졸버나 다른 서버로부터 신뢰를 상실하게 되는 것

서비스 거부 (Denial of Service)

일반적인 네트워크 서비스와 동일하게 DoS에 취약

도메인 이름에 대한 인증 된 거부 (Authenticated Denial of Domain Names)

지속적으로 잘못 입력되는 이름에 대한 RR을 캐쉬(Neg Cache)하는 경우 악의적인 목적에 의해 존재하는 도메인 이름에 대해서 속임수의 의미를 갖는 NULL 응답은 캐쉬 오염 등의 추가적 취약성까지 발생

와일드카드(Wildcards)

와일드카드를 이용하는 도메인 이름에 대한 데이터 무결성과 근원지 인증 문제

100


DNSSEC의 약점

구현하기에 복잡하고 매우 조심스럽게 코딩해야 하는 어려운 경우들이 존재

DNS 응답 패킷의 크기 증가 -> DoS 공격의 증폭기 역할을 할 가능성이 큼

DNSSEC 응답의 확인 과정은 리졸버의 작업 부하를 증가

DNSSEC의 신뢰 모델도 계층적 구조 : 루트와 해당 도메인 네임 사이의 어느 한 존에서 문제가 발생하면 결국 전체의 신뢰가 깨짐

루트에서의 키 갱신 설정(rollover)이 어려움

DNSSEC 서명 생성과 이를 이용한 확인 작업 사이에는 느슨한 시간 동기 메커니즘이 필요

존에서의 와일드카드 RR 존재는 인증을 더욱 복잡하게 함

DNSSEC을 적용하더라도 신뢰받는 서버로 위장하는 공격 등에는 취약

101

DNSSEC 관련 주요 용어 정의(1)

네임서버, 리졸버 관련 용어 Security-Oblivious Name Server :

DNSSEC을 인식하지 못하는 일반 name server

Security-Aware Name Server : DNSSEC 표준사항을 인식하는 name server 구현 요건:

DNS 질의 수신 (기본 DNS 기능) DNS 응답 송출 (기본 DNS 기능) EDNS0 메시지 크기 확장 옵션 지원 DO bit 지원 DNSSEC RR 및 메시지 헤더 bit 지원

Authoritative name server만을 의미하는 것이 아니라, Recursive name server의 name server 기능부분도 포함

Security-Oblivious Resolver : DNSSEC을 인식하지 못하는 일반 resolver

102

DNSSEC 관련 주요 용어 정의(2) Security-Aware Resolver :

DNSSEC 표준사항을 인식하는 resolver

구현 요건:

DNS 질의 송출 (기본 DNS 기능)

DNS 응답 수신 (기본 DNS 기능)

EDNS0 메시지 크기 확장 옵션 지원

DO bit 지원

DNSSEC RR 및 메시지 헤더 bit 지원

stub-resolver 포함

Security-Aware Stub Resolver :

DNSSEC 표준사항을 인식하는 stub-resolver

Non-Validating Security-Aware Stub Resolver :

Security-Aware Stub Resolver 중에서 자신 스스로 서명 검증(validation)을 수행하지 않고, Security-Aware Recursive 네임서버에 서명 검증을 의존하는 stub-resolver.

구현요건:

DNS 질의 송출 (기본 DNS 기능)

DNS 응답 수신 (기본 DNS 기능)

Security-aware Recursive 네임서버와 적절한 secured channel 설정 가능

103


Validating Security-Aware Stub Resolver : Security-Aware Stub Resolver 중에서 자신 스스로 서명 검증(validation)을

수행하는 stub-resolver.

용어 "Validating Stub Resolver"와 동일

Recursive Name Server : “Name Server 기능”과 “Resolver" 기능이 결합된 요소

사용자 단말의 DNS 질의를 수신하는 포트 53에 binding 되어 있는 ‘name server' 기능과 name server가 참조하는 cache를 관리하고 업데이트하는 ’resolver' 기능으로 구성

사용자 단말의 stub-resolver와 통신하는 기능은 Recursive Name Server의 ‘name server' 기능

Security-Oblivious Recursive Name Server : DNSSEC을 인식하지 못하는 일반 recursive name server

Security-Aware Recursive Name Server : Security-Aware Name Server와 Security-Aware Resolver 기능으로 구성된 DNS

요소

“a Security-Aware Name Server that offers recursive service”라고도 표기

104


Zone 및 위임 포인트 관련 용어 Unsigned Zone :

DNSSEC을 적용하지 않은 일반 도메인 존

Signed Zone :

도메인 존 내의 RR set들이 서명되고, DNSKEY, RRSIG, NSEC RR과 경우에 따라 DS RR을 가지고 있는, DNSSEC이 적용된 도메인 존

Zone Apex :

자식 존(child zone)에서의 존 도메인 네임(zone domain name)

자식 존 입장에서의 'zone cut'

예: or.kr 존에서 nida.or.kr 존으로 위임받는 경우, nida.or.kr 존에 SOA RR로 설정된 nida.or.kr 도메인 네임이 ‘Zone Apex’

Delegation Point :

부모 존에서 자식 존으로 위임하는 자식 존의 존 도메인 네임(zone domain name)

부모 존 입장에서의 ‘zone cut’

예: or.kr 존에서 nida.or.kr 존으로 위임하는 경우, or.kr 존에 설정된 nida.or.kr 도메인 네임이 ‘Delegation Point’

105


Authoritative RRset : 특정 존(zone) 내에서, 그 도메인 네임이 Zone Apex 이하, 그리고 자식 존으로

위임되는 zone cut 이상의 영역에 속하는 경우, 이 도메인 네임의 RR set을 ‘authoritative’ RR set이라고 함

DNSSEC Public Key 관련 용어

Authentication Key : Security-Aware Resolver가 검증(verification)한 Public Key로써 Resolver가 DNS

데이터 인증(authentication)에 사용하게 되는 Public Key

Authentication Key에는 다음의 2가지가 있음

Zone Signing Key (ZSK)

Key Signing Key (KSK)

Zone Signing Key (ZSK) : 존(zone)을 서명한 Private Key에 대응하는 Authentication Key (Public Key)

ZSK의 대응 Private Key는 도메인 존이 “소유하는” 모든 도메인 네임의 RR set을 대상으로 서명

도메인 존이 소유하지 않는, Delegation Point에 해당하는 자식 도메인 네임의 NS RR set은 서명하지 않음

106


Key Signing Key (KSK) : 대상 존(zone)의 하나 또는 여러 개의 Authentication Key를 서명한 Private Key에

대응하는 Authentication Key (Public Key)

KSK의 대응 Private Key는 도메인 존의 ZSK 데이터를 갖는 DNSKEY RR set을 서명

Trust Anchor : Resolver에 설정되는 DNSKEY RR 또는 DNSKEY RR의 DS RR 해쉬(hash) 데이터

Validating Secure-Aware Resolver는 이 Public Key(DNSKEY RR의 KSK) 또는 hash(DS RR의 hash data)를 DNS 응답 메시지의 서명된 데이터에 대한 인증체인(authentiacation chain)을 구축하는 출발점(starting point)으로 사용

Validating Resolver는 이 Trust Anchor의 초기값을 DNS 프로토콜을 사용하지 않고, 별도의 보안 적용된 방식을 사용하여 설정해야 함

Authentication Chain : DNS Public Key(DNSKEY RR) RR set과 Delegation Signer (DS) RR set이 교대로

순서 지어 형성하는 서명된 데이터의 체인(chain)으로써, 각 체인은 다음 체인을 보증하는 역할을 함

107

DNSSEC 구성 요소 및 기본 구조

108

Security-Oblivious Name Server

Security-Oblivious Resolver


Security-Oblivious Stub Resolver

Port 53 Port 53

Security-Aware Name Server

Security-Aware Resolver


Validating Security-Aware Stub Resolver

Port 53

Port 53

Non-Validating Security-Aware Stub Resolver

Security-Aware Stub Resolver

DNSSEC 적용

Security-Aware Recursive Name Server

Security-Oblivious Recursive Name Server


기존 Security-Oblivious DNS와의 공존체계(1)

기존 Security-Oblivious DNS와 Security-Aware DNS는 공존 가능

Security-Aware DNS 구성요소는 Security-Oblivious DNS 구성요소를 인지하고 이들과 통신하는 경우, Security-Oblivious DNS 질의응답 절차에 따라 동작

Resolver의 DNS 질의 메시지에 EDNS0 "DNSSEC OK" flag bit(DO bit)의 세팅 여부에 의해 Security-Aware Resolver 여부를 판별하고 응답 방식 결정, 처리

109


110


Security-Oblivious Resolver


Security-Oblivious Stub Resolver

Port 53

Port 53


Security-Aware Resolver


Validating Security-Aware Stub Resolver

Port 53

Port 53

Non-Validating Security-Aware Stub Resolver


Security-Aware Recursive Name Server

Security-Oblivious Recursive Name Server



DNSSEC OK bit 설정 질의응답 예: C:\>dig +multi +dnssec +norec @192.36.144.107 www.nic.se a ; <<>> DiG 9.3.2 <<>> +multi +dnssec +norec @192.36.144.107 www.nic.se a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1085 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.nic.se. IN A ;; AUTHORITY SECTION: nic.se. 86400 IN NS ns.nic.se. nic.se. 86400 IN NS ns2.nic.se. nic.se. 7200 IN NSEC nic-demo.se. NS RRSIG NSEC nic.se. 7200 IN RRSIG NSEC 5 2 7200 20060630225233 ( 20060625150557 12392 se. iRF19fLXxDhNMkd0qHJ37cN/vjkVX/5WC7J8AfZ581TD LKngu+fhNAiPcTNYhTr2cmWanVgEy0OHXr6gRPIYVgVe 6ufSoAg46509f1OoKu6FZC+i31GSNzxpFQxWpLvimnug 2TiK3EigvF0GPhTktDsZ3JUmEg+8DmY/tEfMI/w= ) …

111


DNSSEC OK bit 설정하지 않은 질의응답 예: 일반 DNS 질의 응답 C:\>dig +multi +norec @192.36.144.107 www.nic.se a ; <<>> DiG 9.3.2 <<>> +multi +norec @192.36.144.107 www.nic.se a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1483 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.nic.se. IN A ;; AUTHORITY SECTION: nic.se. 86400 IN NS ns2.nic.se. nic.se. 86400 IN NS ns.nic.se. ;; ADDITIONAL SECTION: ns.nic.se. 86400 IN A 212.247.204.130 ns2.nic.se. 86400 IN A 212.247.204.136 ;; Query time: 390 msec ;; SERVER: 192.36.144.107#53(192.36.144.107) ;; WHEN: Mon Jun 26 11:54:32 2006 ;; MSG SIZE rcvd: 95

112

DNSSEC과 EDNS0의 UDP payload size (1)

EDNS0의 sender's UDP payload size 필드

CLASS 필드 해당 필드에 “The sender's UDP payload size” 값 설정

설정 값 범위 : 0 ~ 65,535

Resolver와 Name Server가 각각 자신이 수신할 수 있는 UDP payload size 값 표시

DNSSEC에서의 sender's UDP payload size 필드 값 설정 규정

Security-Aware Resolver와 Security-Aware Name Server

최소한 1220 octets의 메시지 사이즈를 반드시(MUST) 지원해야

4000 octets의 메시지 사이즈 지원이 가능해야 함(SHOULD)

sender's UDP payload size 값에 따른 응답 DNS 메시지

충분히 크게 설정한 경우, 네임서버는 IP Fragment 메커니즘을 사용, 다수의 UDP 패킷에 걸쳐 전체 응답 메시지 전달

113

DNSSEC과 EDNS0의 UDP payload size (2)

Answer Section과 Authority Section에 충분한 RR 정보를 설정하여 응답하지 못할 정도의 작은 값일 경우, Truncation bit 설정, Resolver에서 TCP 연결을 통한 DNS 재질의 발생

UDP payload size가 Answer Section과 Authority Section에 충분한 RR 정보를 설정할 수 있으나, Additional Section에 모든 RR을 설정할 수 없는 경우에는 Additional Section의 일부 RR를 생략하여 지정된 값에 근접한 크기의 DNS 응답 메시지 전달

sender's UDP payload size 값에 따른 존 파일 설정 고려사항

UDP payload size는 최소 1220 octets에서 약 4000 octet까지 지원하도록 규정되므로, 네임서버에서의 응답 메시지가 Additional Section을 제외하여 가능한 한 1220 octet 이내의 size를 갖도록 존 파일 설정 필요

114

NSEC RR 관련 문제 “NSEC walking problem”

NSEC RR에 의해 존재하는 도메인과 존재하지 않는 도메인 정보를 Recursive 네임서버에 제공할 수 있는데, 이를 통해 해당 도메인 존(domain zone)에 설정된 모든 도메인 네임 정보를 용이하게 파악할 수 있음 ("DNSWalk“ 문제)

도메인 네임 정보 보호를 위해 AXFR/IXFR 질의를 차단하는 설정을 하는 것이 일반적인데, DNSSEC을 적용하면 NSEC RR을 질의를 통해 도메인 존(zone)의 전체 도메인 네임을 파악할 수 있게 되어 오히려 보안이 더 취약해짐

EU에서는 DNSSEC 적용이 EU의 Privacy 정책에 위배되는지 검토 (2003년)

RFC4033, RFC4034, RFC4035 문서의 NSEC RR 규정을 수정 또는 새로운 RR을 정의하려 문제를 해결하려 하고 있음. (수정방식 : RFC4470, 새로운 RR 방식 : NSEC3)

RFC4034에서는 NSEC RR을 도메인 존 전체에 대해 적용하도록 규정되어 있으나,

RFC4470은 이를 변경하여, authoritative 네임서버가 필요시 NSEC RR을 생성, 서명하여 응답하는 방식을 사용하여 NSEC RR 조회를 통한 전체 도메인 조회를 용이하지 않게 하는 방식 제시

115

DNSSEC에서의 서명 및 검증 (1)

DNSSEC의 공개 키 암호방식의 적용 방식

키 생성 및 관리 주체 : 도메인 관리자/관리 기관 상위 부모 도메인 관리자가 자식 도메인에 대한 키를 생성하거나 관리하는 일이

없음

각 도메인 단위로 키 관리가 독립적으로 이루어짐

공개 키(public key) 배포 방식 : DNSSEC의 DNSKEY RR에 포함 공개 배포 DNSKEY RR의 RDATA 필드 중에서 “Public Key" 필드에 공개 키(public key) 저장

공개 키에는 2가지 종류가 있음 : ZSK와 KSK DNSSEC 도메인 구성 상, 2 쌍의 키를 생성, 적용함

ZSK : Zone Signing Key, 도메인 존 데이터의 서명을 검증하기 위해 사용되는 Public Key

KSK : ZSK를 포함하는 DNSKEY RR에 대한 서명을 검증하기 위해 사용되는 Public Key (ZSK에 대한 서명 검증 목적)

비밀 키(private key) : 도메인 관리자/관리기관이 보안 관리 비밀 키는 외부에 노출되거나, 전송되는 경우가 없어야 함

116


서명 데이터 : DNSSEC의 RRSIG RR에 포함 RRSIG RR의 RDATA 중 “Signature" 필드에 해당 서명(signature) 저장

도메인 Public Key에 대한 인증(Certificate) : 부모 도메인 DS RR의 digest 값 설정 도메인의 Public Key는 다시 상위 부모 도메인에서 인증(Certificate) 제공

DS(Delegation Signer) RR의 RDATA 필드 중 “Digest" 필드에 자식 도메인의 DNSSKEY RR의 owner name과 RDATA에 대한 digest 값 설정

DS RR은 다시 부모 도메인에 의해 존 서명을 위한 비밀 키(private key)로 서명됨

DNSSEC에서의 키 생성

DNSSEC에서는 보통 2개의 Key Pair을 생성 ZSK를 위한 Key Pair

KSK를 위한 Key Pair

ZSK를 위한 Key Pair 중 비밀 키(private key)는 Zone의 모든 RR set 데이터에 대해 서명

KSK를 위한 Kay Pair 중 비밀 키(private key)는 Zone의 DNSKEY RR set에 대해서만 서명

117


DNSSEC에서의 키 생성 절차

118


DNSSEC에서의 RR set에 대한 서명(Signing) 개요 서명은 서명 대상 <RR set> 단위로 서명 수행

서명 대상 데이터는 단순히 <RR set>에 한정하는 것이 아니라, <Signature 필드를 제외한 RRSIG RDATA>와 <RR set> 데이터를 합한 데이터를 대상으로 함

서명을 수행하기 이전에 RRSIG RR 각 필드 값을 채운 후에 서명 절차 수행

서명 데이터는 RRSIG RR의 RDATA 필드 "Signature"에 설정

하나의 <RR set>에 대하여 하나의 RRSIG RR 생성, 설정

119


RR SIG – RDATA 및 서명 생성 절차

120


DNSSEC에서의 RRSIG RR 서명에 대한 검증(Verification)

Resolver에서 RRSIG RR의 서명에 대한 검증 수행

서명 대상 RRSIG RR의 Signature 필드 제외 부분과 <RR set>을 합한 서명 대상 데이터를 추출하고, 이 데이터에 대해 Hash 알고리듬을 적용하여 digest 값을 추출

RRSIG RR의 Signature 필드에 설정된 서명 데이터에 대해 Zone의 DNSKEY RR의 "Public Key" 필드에 지정된 ZSK 값으로 암호 해독(Decryption) 수행, digest 값 복구

<RRSIG RR의 RDATA(Signature 제외>와 <RR set>에서 직접 계산한 digest 값과 RRSIG RR의 Signature를 암호 해독하여 얻은 digest 값을 상호 비교, 일치 여부 확인

두 개의 값이 일치하는 경우, 서명이 검증된 것임

121


RRSIG RR 서명 검증 절차

122


DNSSEC에서의 DS RR 설정

도메인 존의 상위 부모 도메인에 DS RR을 설정함으로써 인증 체인( Authentication Chain) 구성

자식 도메인의 KSK를 포함하는 DNSKEY RR에 대해 부모 도메인에서 digest 값을 제공, 자식 도메인의 DNSKEY RR(KSK)에 대한 인증(Certificate) 효과 제공

자식 도메인의 DNSKEY RR(KSK)의 <"owner name" 필드>와 <RDATA 필드 전체>를 합하여 처리 대상 데이터를 만들고 이에 대하여 Hash 알고리즘을 적용, Digest 값을 산출, 산출된 digest 값을 DS RR에 설정

DS RR은 부모 도메인의 ZSK를 위한 Key Pair 중 비밀 키(private key)에 의해 서명되어 DS RR에 대한 RRSIG RR을 생성, 설정함

DS RR에 대한 서명이 이루어짐으로써, 자식 도메인 DNSKEY RR(KSK)에 대한 부모 도메인에서의 서명이 RRSIG RR에 의해 제공됨

123


인증 체인 구성 절차

124

DNSSEC RR 포맷 및 기능 (1)

RRSIG RR

도메인 데이터에 대한 서명(signature)을 “Signature" 필드에 저장 제공

도메인 내 각 도메인 네임의 RR set 단위로 서명하고, 서명을 해당 도메인 네임에 대한 RRSIG RR로 생성하여 제공

각 도메인 네임의 RR set에 대해 private key로 서명하여 생성되는 하나의 RRSIG RR 생성

Zone Apex 네임에 대한 DNSKEY RR set에 대해서는 2개 이상의 RRSIG RR 존재 가능

ZSK 대응 private key에 의해 서명된 서명을 갖는 RRSIG RR

KSK 대응 private key에 의해 서명된 서명을 갖는 RRSIG RR

서명 대상 도메인 데이터 : 도메인 존이 소유하는 도메인 데이터 자식 존에 대한 위임설정을 표시하는 자식 존의 delegation point에 대한 NS RR

set에 대해서는 부모 존의 private key로 서명하지 않음

125

DNSSEC RR 포맷 및 기능 (2) DNSSEC 위임설정 예 :

RIPE.NET 도메인 존 파일 내용 : 자식 도메인 ris.ripe.net에 대한 위임 설정 부분 ris.ripe.net. 172800 IN NS sec1.apnic.net. ris.ripe.net. 172800 IN NS ns-pri.ripe.net. ris.ripe.net. 7200 IN NSEC ris-install.ripe.net. NS DS RRSIG NSEC ris.ripe.net. 7200 IN RRSIG NSEC 5 3 7200 20060809051609 ( 20060710051609 46715 ripe.net. WtTRoocV6c/fe2HejFcMjrKAJTBifsFJ7bjKcOfL0inO tPJNqv9Gd2ENTxzxdClB7VjKPGij9fCIU12qyBIbrNKG dtgvth+hj8t3OINiQFJWwNGKDISbPi5HMum6/GpI2Ult UaGXbQzJSFLoi0ixR3t51UUDjOjfiGTAhx+R0dwGGfPs Xf4/F6hcX7Z22rSxG2Je2iBC ) ris.ripe.net. 0 IN DS 9630 5 1 ( 8F4ECC5177221B9CA87B62A3F33FADD3502ED907 ) ris.ripe.net. 0 IN RRSIG DS 5 3 0 20060809051609 ( 20060710051609 46715 ripe.net. dKorBvJzS93fURLF1TkBM17t3polnltONfvVwpY39q8n lxMqafyDwefSbFRWBSj6BTM0L5Pf6uEllDNsVhbX5nDF sF0kSLGIikDd1D3lwzZ0tjqHCYBYfWZZl1CIekNXJd9F bKaCHnZNa4Rx2KklHKJ56cC6z0+JIbWnq9qbqmzHMbif DdgOyQZkiZgw0Hd6YPTJIOEj )

126


RRSIG RR 형식

127

DNSSEC RR 포맷 및 기능 (4) RRSIG RR 데이터 예 C:\Bin>dig +dnssec +cd +multi @202.31.188.15 www.ripe.net a ; <<>> DiG 9.3.2 <<>> +dnssec +cd +multi @202.31.188.15 www.ripe.net a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 654 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 6, ADDITIONAL: 13 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.ripe.net. IN A ;; ANSWER SECTION: www.ripe.net. 414 IN CNAME kite-www.ripe.net. www.ripe.net. 414 IN RRSIG CNAME 5 3 600 20060808231006 ( 20060709231006 46715 ripe.net. LG6vItgoN9hwb3b+3WoFcFBvbsOfyDe+nx9BCcexJlPE BbmJeD/Wyzrp47sSmrlQ/RZRF3/FqkVXuvZ0BXjnOod9 DMP8BO+69Afv+9rIjZTGNnA4CVsCZw3Lep3b26Y5nVtH VVqs1lAdeltCimR76RDX0MYwy2gAzxFuggwk4EhXch4z ZFpzHJhiA1qAxgpFNXYn//gy )

128

DNSSEC RR 포맷 및 기능 (5) “kite-www.ripe.net“의 A RR set에 대한 RRSIG RR 필드 분석

129


RRSIG RR의 필드 데이터를 사용한 서명 검증

RRSIG RR의 필드 중 서명 검증에 사용할 ZSK를 가진 DNSKEY RR을 파악하는 데 결정적인 역할을 하는 필드는 “Key Tag" 필드

Signer's Name에 의해 Zone Apex 도메인 네임을 확인하여 그 DNSKEY RR Set을 파악

“Key Tag" 필드의 값과 일치하는 "Key Tag" 값을 가지는 DNSKEY RR이 서명 검증에 적용될 DNSKEY RR

DNSKEY RR의 Flags 필드 값은 서명 검증을 위한 DNSKEY RR을 파악하는 데에 이용되는 기준이 될 수 없음

존 서명(Zone Signing) 절차에서 참조하기 위한 필드

130


RRSIG RR과 DNSKEY RR 관계

131


DNSKEY RR

DNSKEY RR 포맷

132


“ripe.net”의 DNSKEY RR 필드 분석

“ripe.net"의 경우와 같이, DNSKEY RR이 KSK에 대해서 1개 RR, ZSK에 대해서 2개 RR이 존재하는 경우가 가능

이 경우에도 DNS 데이터의 서명 검증을 위해 사용될 수 있는 ZSK의 DNSKEY RR은 오직 1개

다른 DNSKEY RR은 향후의 ZSK Roll-over 동작을 대비하여 설정해 둔 예비 DNSKEY RR

“ripe.net”의 DNSKEY RR 예

133


134


Zone Apex DNSKEY RR Set에 대한 서명 및 RRSIG RR 생성 서명에 사용된 private key 개수만큼 RRSIG RR이 존재

DNSKEY RR Set은 존 데이터의 하나이므로, ZSK 대응 private key에 의해 서명되어 RRSIG RR이 하나 생성

KSK 대응 private key에 의해 DNSKEY RR Set이 서명되어 다시 RRSIG RR이 하나 더 생성되어 적용

이 두 개의 private key에 의해 서명된 각각의 RRSIG RR을 서로 구분하기 위해서는 RRSIG RR의 "Key Tag" 필드 값에 지정된 “Key Tag(Key ID)" 값에 일치하는 DNSKEY RR을 매칭함으로써 가능

RR SIG 구별 예

135


136


DS RR

DS RR 포맷

137


DS RR 예 부모 도메인(ripe.net)에서 응답하는 자식

도메인(ris.ripe.net)에 대한 DS RR

138


자식 도메인(ris.ripe.net)에서의 Zone Apex DNSKEY RR

139


DS RR 필드 분석 예

140


NSEC RR

NSEC RR 포맷

141

DNSSEC RR 포맷 및 기능 (18) NSEC RR 예: 존재하지 않는 도메인 네임에 대한 질의, 존재하지 않는 타입에 대한

질의

142


NSEC RR 필드 분석 예

143

도메인에 대한 DNSSEC 적용 (1)

도메인에 대한 DNSSEC 설정 절차

원본 도메인 존 파일 작성

해당 도메인 존의 Apex Zone Name에 대한 Key Pair 생성 (ZSK와 KSK 해당 Key Pair)

Key Pair 중 Public Key 해당 DNSKEY RR 데이터를 도메인 존 파일에 반영

해당 도메인 존 파일에 대한 존 서명(Zone Signing)

DNS 서버에 서명된 도메인 존 반영

만일, 해당 도메인이 DNSSEC 영역의 Top Domain이라면, 도메인의 DNSKEY RR 데이터를 Trust Anchor 데이터로 배포, Recursive 네임서버에 설정

만일, 해당 도메인이 DNSSEC 영역의 Top Domain이 아니라면, DS RR 데이터를 상위 부모 도메인 존 파일에 반영하고, 상위 부모도메인에 대한 존 서명(Zone Signing) 후에 DNS에 반영

144


145

도메인에 대한 DNSSEC 적용 (3) DNSSEC 적용 절차에 따른 사용 Tool

도메인 존 파일 작성

존 파일 수작업 작성, 또는 도메인 존 파일 자동 생성기

named-checkzone : 존 파일 문법 오류 체크

Key Pair 생성

dnssec-keygen : Key Pair 생성 tool

산출 파일 :

K<name>+<alg>+<id>.key : 공개 키

K<name>+<alg>+<id>.private : 비밀 키

Public Key(DNSKEY)의 존 파일 반영

수작업 작성 또는 도메인 존 파일 자동 생성기

존 파일에서 $INCLUDE 문을 사용, K<name>+<alg>+<id>.key 파일을 include 시킴

존 서명(Zone Signing)

dnssec-signzone : 존 파일 서명 tool

입력 파일 :

Zone File

K<name>+<alg>+<id>.key (ZSK 해당)

K<name>+<alg>+<id>.key (KSK 해당)

산출 파일 :

<원본 존 파일명>.signed : 서명된 존 파일

dsset-<name> : DS RR 파일 (KSK DNSKEY 대응)

keyset-<name> : DNSKEY RR 파일 (KSK DNSKEY)

146


DNS 서버에 서명된 존 반영

수작업 반영, 또는 자동 반영 처리기

매스터 DNS 서버의 named.conf 파일에서 zone file 옵션에 서명된 존 파일명으로 지정

DNS 서버에 대해 해당 configuration 파일을 다시 읽어 반영토록 명령 rndc reconfig

Recursive 네임서버의 Trust Anchor 설정

Recursive 네임서버의 named.conf 파일에 "trusted-key" 옵션 사용 Trust Anchor 설정

부모 존의 DS RR 반영

부모 존 파일(원본 존 파일)에 $INCLUDE 문을 사용, DS RR에 대한 파일(dsset-<name>)을 반영하도록 작성

부모 존 파일(원본 존 파일)에 대한 존 서명(Zone Signing)

DNS 서버에 해당 존을 reload 반영 처리

147

도메인에 대한 DNSSEC 적용 (5) Key Pair 생성 절차

dnssec-keygen 사용 개요 Usage: dnssec-keygen -a alg -b bits -n type [options] name Version: 9.3.2 Required options: -a algorithm: RSA | RSAMD5 | DH | DSA | RSASHA1 | HMAC-MD5 -b key size, in bits: RSAMD5: [512..4096] RSASHA1: [512..4096] DH: [128..4096] DSA: [512..1024] and divisible by 64 HMAC-MD5: [1..512] -n nametype: ZONE | HOST | ENTITY | USER | OTHER name: owner of the key Other options: -c <class> (default: IN) -e use large exponent (RSAMD5/RSASHA1 only) -f keyflag: KSK -g <generator> use specified generator (DH only) -t <type>: AUTHCONF | NOAUTHCONF | NOAUTH | NOCONF (default: AUTHCONF) -p <protocol>: default: 3 [dnssec] -s <strength> strength value this key signs DNS records with (default: 0) -r <randomdev>: a file containing random data -v <verbose level> -k : generate a TYPE=KEY key Output: K<name>+<alg>+<id>.key, K<name>+<alg>+<id>.private

148

도메인에 대한 DNSSEC 적용 (6) dnssec-keygen 유틸리티의 DNSSEC 키 생성을 위한 사용방법

개요 "-a algorithm" : DNSSEC에 사용하는 Key의 알고리즘 지정 (필수)

DNSKEY RR의 "Algorithm" 필드 및 RRSIG의 "Algorithm" 필드와 관련 (RSASHA1의 경우 "Algorithm" 값은 5)

DS RR의 “Digest Type" 필드 값과 관련 (RSASHA1인 경우, Digest Type = 1 (SHA-1))

"-b key_size" : 생성 키의 bit 단위 사이즈 지정 (필수) 각 Algorithm 별 지정 가능한 key size가 다름 (RSASHA1인 경우 512~4096)

"-n name_type" : 생성 키를 소유하는 주체 유형을 지정 (필수) dnssec-keygen이 생성하는 Key 종류는 다양하며, 이중 하나에 존 서명을 위한

Key가 있음 "-n name_type"에 의해 생성되는 Key가 귀속되는 주체가 무엇인지를 지정 ZONE인 경우, 서명이 적용되는 도메인 존이 Key의 소유 주체가 됨 TSIG을 위한 공유 키 생성의 경우에는 생성되는 Key의 소유 주체가 HOST가 됨 DNSSEC 도메인을 위한 존 서명용 Key를 생성하는 경우 “-n ZONE"으로 지정

149


"-f keyflag" : DNSKEY RR의 "Flags"에서 Bit 15 (SEP bit) 설정 지정 (옵션) 생성되는 Public Key가 DNSKEY RR의 형태로 산출되는 경우, 필드

Flag의 bit 15의 SEP bit를 세팅할 것인지 여부를 지정하는 옵션

KSK에 대한 Key Pair를 생성하는 경우에만 “-f KSK" 옵션을 지정함

“-f KSK” 옵션을 지정하지 않는 경우에는 DNSKEY RR의 필드 “Flags"는 bit 7만 세팅되어 ZSK의 DNSKEY RR로 생성

"-r <randomdev>" : 키 생성을 위한 random 입력 데이터 (옵션이지만 지정 필수) Linux인 경우, 또는 Solaris 9 이상인 경우에는 "/dev/random"

디바이스를 지정

/dev/random을 지원하지 않는 플랫폼인 경우, 임의의 random 값을 갖는 바이너리 파일을 지정 가능

"name" : owner of the key. 생성된 Key를 소유하는 주체의 네임 “-n ZONE" 옵션을 지정한 경우, ”name"은 서명될 도메인 존의

Apex Zone Name을 지정

150

도메인에 대한 DNSSEC 적용 (8) dnssec-keygen이 산출하는 파일

K<name>+<alg>+<id>.key 파일 : Public Key 파일 (DNSKEY RR 데이터)

<name> : “-n ZONE"을 지정하면서 동시에 지정한 "name". 서명될 도메인 존의 Apex Zone Name

<alg> : "-a algorithm"에서 지정한 Algorithm의 코드 값 (RSASHA1 : 5)

<id> : “-n ZONE"을 지정한 경우, DNSKEY RR의 “Public Key" 필드에 설정되는 Public Key의 Key Tag 값

K<name>+<alg>+<id>.private 파일 : Private Key 파일

파일명의 <name>, <alg>, <id>는 K<name>+<alg>+<id>.key 파일의 경우와 동일

Key Pair 생성 예:

[root@ISP-LOCALDNS named]# dnssec-keygen -a RSASHA1 -b 1024 -n ZONE -r /dev/random good.sec.kr

Kgood.sec.kr.+005+59924

[root@ISP-LOCALDNS named]# dnssec-keygen -a RSASHA1 -b 2048 -n ZONE -f KSK -r /dev/random good.sec.kr

Kgood.sec.kr.+005+20895

KSK 해당 Key Pair :

Kgood.sec.kr.+005+20895.key : Public Key (DNSKEY RR)

Kgood.sec.kr.+005+20895.private : Private Key

ZSK 해당 Key Pair :

Kgood.sec.kr.+005+59924.key : Public Key (DNSKEY RR)

Kgood.sec.kr.+005+59924.private : Private Key

151


Public Key(DNSKEY)의 존 파일 반영 존 서명(Zone Signing) 이전에 존 파일에 DNSKEY RR 설정 필요

DNSKEY RR 역시 도메인 존의 DNS 데이터임

서명 절차 중에 DNSKEY RR에 대한 RRSIG RR 생성

NSEC RR은 존 서명(Zone Signing) 과정에서 도메인 네임을 정렬(sorting)하여 자동 생성

반영 방법 및 절차

도메인 존에 대한 DNSKEY RR 데이터는 Key 생성 절차에 의해 산출된 Public Key 파일에 존재

K<name>+<alg>+<id>.key 파일을 내용의 변경 없이 그대로 존 파일에 반영할 수 있음

주의사항 : K<name>+<alg>+<id>.key 파일에는 TTL이 지정되어 있지 않음

따라서, K<name>+<alg>+<id>.key 파일을 그대로 존 파일에 반영하는 경우, $TTL에 지정된 TTL 값이 적용되거나, 존 파일에 $TTL이 명시적으로 지정되지 않은 경우, 도메인 존의 SOA RR의 Minimum TTL 값으로 자동 설정됨

반영 예: 존 파일에 다음 2줄 추가

$INCLUDE Kgood.sec.kr.+005+59924.key ; ZSK

$INCLUDE Kgood.sec.kr.+005+20895.key ; KSK

152

도메인에 대한 DNSSEC 적용 (10) 존(zone) 서명(signing)

존 파일 서명 도구 dnssec-signzone 사용 개요 [root@ISP-LOCALDNS named]# dnssec-signzone Usage: dnssec-signzone [options] zonefile [keys] Version: 9.3.2 Options: (default value in parenthesis) -c class (IN) -d directory directory to find keyset files (.) -g: generate DS records from keyset files -s [YYYYMMDDHHMMSS|+offset]: RRSIG start time - absolute|offset (now - 1 hour) -e [YYYYMMDDHHMMSS|+offset|"now"+offset]: RRSIG end time - absolute|from start|from now (now + 30 days) -i interval: cycle interval - resign if < interval from end ( (end-start)/4 ) -v debuglevel (0) -o origin: zone origin (name of zonefile) -f outfile: file the signed zone is written in (zonefile + .signed) -r randomdev: a file containing random data -a: verify generated signatures -p: use pseudorandom data (faster but less secure) -t: print statistics -n ncpus (number of cpus present) -k key_signing_key -l lookasidezone -z: ignore KSK flag in DNSKEYs Signing Keys: (default: all zone keys that have private keys) keyfile (Kname+alg+tag)

153


dnssec-signzone 유틸리티를 사용한 Zone 서명 방법 개요 "-o origin" : 서명대상 존의 Zone Apex 네임 지정

서명 대상 존 파일 SOA RR의 도메인 네임과 일치 필요

"-r <randomdev>" : 존 서명을 위한 random 입력 데이터 (옵션이지만 지정 필수)

Linux인 경우, 또는 Solaris 9 이상인 경우에는 "/dev/random" 디바이스를 지정 /dev/random을 지원하지 않는 플랫폼인 경우, 임의의 random 값을 갖는

바이너리 파일을 지정 가능

"-a" : 존 서명 후 생성된 서명 데이터를 검증하도록 추가 동작 지정 "-t" : 존 서명 과정에 서명 처리 소요 시간 등 통계 정보 추가 출력 "-k key_signing_key" : KSK 대응 private key를 명시적으로 지정

key_signing_key는 “K<name>+<alg>+<id>”의 형태로 지정

"zonefile" : 서명 대상 원본 존 파일명 지정 "keys" : ZSK 대응 Key를 지정

key는 “K<name>+<alg>+<id>”의 형태로 지정

MCC Laboratory 154


dnssec-signzone이 산출하는 파일

dsset-<name> 파일 : DS RR 데이터의 파일

<name> : "-o origin"으로 지정한 Zone Apex 도메인 네임

keyset-<name> 파일 : DNSKEY RR 데이터의 파일

<name> : "-o origin"으로 지정한 Zone Apex 도메인 네임

<zone_file_name>.signed : 원본 존 파일에 대한 서명된 존 파일

<zone_file_name> : 원본 존 파일명

존 서명(Zone Signing) 수행을 위한 최소한의 dnssec-signzone 명령

dnssec-signzone -o <origin_name> -r <randomdev> <zonefile_name>

존 서명(Zone Signing)시 서명 Key를 명시하는 dnssec-signzone 명령

dnssec-signzone -o <origin_name> -k K<name>+<alg>+<id> -r <randomdev> <zonefile_name> K<name>+<alg>+<id>

주의

ZSK 대응 키를 서명키로 지정하는 경우, 옵션 “-k"를 사용한 KSK 대응 키 지정을 반드시 해야 함

만일 ZSK 대응 키만 지정하고, “-k" 옵션을 누락하는 경우, ZSK 대응 키에 의한 서명만 수행함

서명 키를 명시해야 하는 경우

서명 수행 디렉토리 내에 서명 대상 존의 Key가 여러 개 존재하는 경우(KSK 대응 키와 ZSK 대응 키)

155


Recursive 네임서버의 Trust Anchor 설정 서명된 존이 DNSSEC 보안적용 영역의 Top Domain인 경우

해당 존의 DNSKEY RR 데이터를 외부에 배포하여 recursive 네임서버에서 Trust Anchor로 설정할 수 있도록 함

Trusted-Keys 설정 구문 (BIND 9 Configuration)

trusted-keys {

string number number number string ;

string number number number string ; ...

};

첫 번째 구문 (string) : DNSSEC 적용영역 중 Top Domain의 Zone Apex 네임을 “string"으로 지정 (Trust Anchor 설정을 위해 배포된 KSK DNSKEY RR의 owner name)

두 번째 구문 (number) : KSK DNSKEY RR의 RDATA 첫 번째 필드인 “Flags" 값을 숫자로 설정

세 번째 구문 (number) : KSK DNSKEY RR의 RDATA 두 번째 필드인 “Protocol" 값을 숫자로 설정

네 번째 구문 (number) : KSK DNSKEY RR의 RDATA 두 번째 필드인 “Algorithm" 값을 숫자로 설정

다섯 번째 구문 (string) : KSK DNSKEY RR의 RDATA 세 번째 필드인 “Public Key" 데이터를 Base64 코딩 문자열 형태 그대로 문자열로 지정

156


부모 존에서의 DS RR 반영 서명된 존이 DNSSEC 보안적용 영역의 Top Domain이 아닌 경우

상위 서명된 부모 존으로 DS RR 데이터를 전송하여 부모 존에 반영 부모 존에 DS RR을 반영하여 적용함으로써 부모 존의 인증 체인(Authentication

Chain)에 연결 구성

반영 예: good.sec.kr 존의 DS RR을 sec.kr 존 파일에 반영(다음 줄 추가)

good.sec.kr. IN DS 20895 5 1 6D79FDE16C0542EDAC6F78583104DD26D3FA150C

SEC.KR 존의 Serial Number 증가 수정 SEC.KR zone에 대한 서명 및 DNS 서버에 존 변경 사항 반영

디렉토리에 존재하는 유일한 KSK 대응키와 ZSK 대응키로 서명하도록 dnssec-signzone 수행

[krdns-slave:/usr/local/bind/var/named]# dnssec-signzone -o sec.kr -r /usr/local/bin/snmpwalk sec.zone

dnssec-signzone: warning: Ksec.kr.+005+36575.key:1: using RFC 1035 TTL semantics

sec.zone.signed name server(BIND 9.3.2)에서 SEC.KR 존을 reload하여 반영

[krdns-slave:/usr/local/bind/var/named]# rndc reload sec.kr. zone reload queued

157

DNSSEC 응답사례에 대한 분석 (1)

158


159


160


161

TSIG, SIG(0)

일련의 트랜잭션에 대한 보안 지원으로 확장

stub 리졸버와 캐싱 DNS 서버간의 통신과 같이 비교적 비중이 적은 통신에서 DNSSEC을 적용하는 것은 비용 과다 -> TSIG

TSIG : 다이나믹 업데이트 등의 질의에 대해서도 인증이 가능

비밀키 기반의 인증 사용

요청 트랜잭션을 수행하게 되는 송신과 수신, 양측에 사전에 협의를 통하여 비밀키 공유

DNS 업데이트 메시지의 additional 섹션에 TSIG RR이 포함

RDATA 필드의 내용 안에 메시지에 대한 인증 코드(MAC)를 포함해 무결성 보장을 위한 메커니즘 수행

SIG(0) : DNS 요청이나 응답 메시지에 대해 전자적으로 서명을 함으로써 트랜잭션을 보호

SIG RR의 type covered 필드가 0값을 갖기 때문에 보통 SIG(0)라 불리며 TSIG로부터 유래되었으나 공개키 인증을 사용하는 것이 차이점

공개키는 DNS내에 KEY RR로써 저장되고 그에 대한 비밀키는 서명자에게 저장

키의 길이로 인해 상대적으로 비싼 공개키 암호화 연산이 필요하고, 모든 요청에 대해 SIG(0)의 사용과 그에 대한 검증을 하는 것은 과도한 부하가 되므로 개선 필요

162

정호 충자료 dns 와 dns 체계 구축 - mmu.ac.krlily.mmu.ac.kr/lecture/13is/add_dns.pdf ·...

Documents