FOCUS FOCUS 1 인터넷이용의기반 DNS 의 이해와 DNS 보안 김도원 인터넷을이용하면서도인터넷이용의기반인도메인이름체계 ( 이하 DNS ) 1) 를알고이해하는사람은그리많지않을것이다. 그러나 DNS 는인터넷이용의첫관문과도같은, 중요한역할을한다. 따라서 DNS 에보안상취약점이있다면인터넷이용자가입을수있는피해는클것이다. 하지만 DNS 는악의적인해커에의해정보가위 변조될가능성이존재하며이로인해위조웹사이트로연결될수있다. 이러한 DNS의보안취약점을보완하기위해등장한것이위변조방지기술 ( 이하 DNSSEC ) 이다. 본고에서는인터넷이용의근간이되는 DNS 의개념과 DNS 의보안취약점 DNSSEC 의개념, 국내외 DNSSEC 관련현황을설명하고 DNSSEC 의향후발전방향에대해기술하고자한다. Ⅰ. 서론 Ⅱ. DNS 의개요 1. DNS 등장배경 2. DNS 의구성요소 Ⅲ. DNS 보안 1. DNS 보안취약점 2. DNSSEC 개념 3. DNSSEC 이력및동향 Ⅳ. 발전방향 한국인터넷진흥원인터넷주소기술팀선임연구원 (kimdw@kisa.or.kr) 6 Internet & Security Focus 2013 9 월호
Ⅰ. 서론 FOCUS 우리는매일컴퓨터와스마트폰의웹브라우저를통해웹사이트를접속하여뉴스를보고필요한정보를검색하거나인터넷쇼핑과뱅킹등을하고있다. 이같이웹사이트를가기위해서우리는웹브라우저주소창에도메인이름 ( 예. kisa.or.kr) 을입력한다. 그렇게되면우리의눈앞에우리가원하는웹사이트가나타나게되는것이다. 이과정에서사람이알고있는도메인이름으로, 전산시스템에접속하기위해필요한정보인, IP주소 ( 예. 121.156.115.59) 로변환시켜주는도메인이름시스템 (Domain Name System, 이하 DNS ) 의역할은필수적이다. 일반인터넷이용자가웹브라우저주소창에도메인이름을입력하면원하는웹사이트가화면에나타나지만그뒷단에는 DNS 의숨은역할이있는것이다. 그런데, 그뒷단에서숨은역할을수행하는 DNS 가제대로동작하고있는지를의심해본적이있는가? 그리고정확한도메인이름을입력했다하더라도지금접속되는웹사이트가진짜인지, 해커에의해만들어진위조웹사이트인지를의심해본적이있는가? 상당수의인터넷이용자는이런의심을가져보지않았을것이다. 하지만위에서언급한일들은충분히일어날수있는일이며, 도메인이름의유사성 ( 예. kisa.or.kr 과 kisa.co.kr 또는 kisa.kr 과 kiso.kr) 을이용한피싱 (Phishing) 2) 과는달리 DNS 정보위변조가된다면, 인터넷주소창에정확한도메인이름을입력하더라도해커에의해구축된위조웹사이트로접속하게되고인터넷이용자는자신도모르는사이에개인정보를갈취당하게된다. 이같은수법은파밍 (Pharming) 3) 의한수법으로인터넷검색창에서 파밍 을검색해보더라도쉽게사고사례를찾을만큼사회문제가되고있다. 그렇다면이런취약점을막을수있는보안책은없는가? 이런생각에서나온것이 DNS 위변조방지기술, 즉 DNSSEC 이다. DNSSEC 은 10여년전에최초로개념이정립된뒤국내외관련기술의표준화가진행되었으며현재세계곳곳에서그기술을도입하여운영중이다. 그리고국제인터넷주소관리기구 (Internet Corporation for Assigned Name and Numbers, 이하 1) 도메인이름 (www.kisa.or.kr) 을 IP주소 (121.156.115.59) 로변환해주는시스템 2) 금융기관등의웹사이트나거기서보내온메일로위장하여개인의인증번호나신용카드번호, 계좌정보등을빼내이를불법적으로이용하는사기수법 3) DNS Spoofing 이정확한명칭이며인터넷주소창에방문하고자하는사이트의 URL을입력하였을때가짜사이트 (fake site) 로이동시키는공격기법 Internet & Security Focus 2013 9 월호 7
FOCUS ICANN ) 4) 에서는새롭게생성되는.google,. 삼성 과같은최상위도메인 (TLD) 5) 운영을위한 필수사항을규정하고있을만큼중요한기술로자리매김하고있다. DNSSEC 은도메인이름의연결상의안정성을보장하는기술의차원을넘어전세계적으로 운영되고있는 DNS 라는인프라를이용하여새로운보안인증체계를만들기위한연구가진행중이다. 이에, 본고에서는 DNS 의역할과보안이점점강조되는시점에서, DNS 의개요와보안취약점, DNSSEC 개념, 관련기술의국내외현황등과향후발전방향에대하여기술하고자한다. Ⅱ. DNS 의개념 1. DNS 의등장배경 DNSSEC 은기존의 DNS의보안취약점을보완하기위한기술이다. 따라서, DNSSEC 을이해하기위해서는먼저보안적용의대상이되는 DNS의기본구조와프로토콜의이해가필요하다. 본장에서는 DNS의역할, 기본구조와구성, 동작원리를설명하고 DNSSEC 과비교하여기존의 DNS 가갖는보안취약점을함께기술한다. 인터넷은 1960 년대말에구축된미국의 ARPANET 으로부터진화한네트워크이다. 1969 년말초기의 ARPANET 은 4대의호스트 6) 가연결된소규모네트워크였지만 TCP/IP(Transmission Control Protocol/Internet Protocol) 7) 개발되고 e-mail(electronic mail) 도입되면서네트워크급격히확장되기시작되었다. ARPANET 에연결된호스트는 1981 년에는 213 개, 1983 년에는 562 개, 1984 년에는 1,024 개, 1985 년에는 1,961 개, 1986 년 2,308 개, 1987 년 28,174 개로기하급수적인증가세를보였다. 4) 비영리기관으로인터넷도메인관리와정책을결정하는도메인관련국제최고기구 5) 인터넷에서도메인이름의가장마지막부분을말하며 kisa.or.kr 의최상위도메인은.kr이된다. 최상위도메인은.com 과같은일반최상위도메인과.kr 같은국가코드최상위도메인으로나뉜다. 6) 정보처리시스템에서중심적인역할을담당하는범용컴퓨터 7) 네트워크전송프로토콜로, 서로다른운영체제를쓰는컴퓨터간에도데이터를전송할수있게하기위해개발된인터넷정보전송표준프로토콜로서, TCP 는전송데이터를일정단위로나누고포장하는것에관한규약이고, IP는직접데이터를주고받는것에관한규약임 8 Internet & Security Focus 2013 9 월호
이들호스트들은자신들의고유한주소를가지고있었다. 그러나이주소체계는사용자가 일일이모든호스트의주소를암기하기가어려웠다. 사람이어떤호스트와통신하기위해서 수백, 수천여개의주소를기억할수있겠는가? FOCUS 이에가장먼저사용되었던방법은호스트내에호스트의별칭과 IP주소를매핑하는테이블, 즉 HOSTS.TXT 라는파일을저장하여관리하는것이었다. 이방식은아직까지도거의모든호스트에서이용되고있다. Unix/Linux 계열호스트에서는 /etc/hosts 파일로, Windows OS 호스트에서는 c:\windows\system32\drivers\etc\hosts 또는 c:\winnt\system32\drivers\etc\ hosts 파일이그것이다. 네트워크에연동된호스트가증가하면서, HOSTS.TXT 파일은개별호스트에서독자적으로관리하는것이불가능해진다. 이에전체호스트들에대한호스트네임을체계적으로관리하는기관이별도로필요하게된다. 호스트들간에그호스트네임이서로중복되지않을필요성이있기때문이다. 이러한역할을담당하는기관을 NIC(Network Information Center) 라하며, 초기 ARPANET 에연동된 4개호스트중하나를관리하는기관인 Stanford Research Institute(SRI) 가 NIC 의역할을하고있었다. DNS가도입되기이전에는각호스트는 NIC에서관리하고갱신하는 HOSTS.TXT 파일을 FTP 를사용하여주기적으로다운로드함으로써자신의호스트에전체호스트에대한호스트네임및네트워크주소정보를갱신하고있었다. 그러나이방식은한계에부딪히게되었다. 호스트네임을중복되지않게부여하고유지하는것이점차곤란하게되고급증하는신규호스들에게기존에사용되고있는호스트네임이아닌다른호스트네임을부여해야했다. HOSTS.TXT 파일의관리가점차어려워지고있었다. 호스트수가증가함에따라호스트네임에대한네트워크주소의변경, 신규호스트의등록이빈번해졌다. 네트워크주소의변경이나신규등록시마다 NIC에서는 HOSTS.TXT 파일을업데이트해야하고, 각호스트들은이 HOSTS.TXT 파일을다운로드하여각호스트의정보를최신정보로업데이트해야했다. HOSTS.TXT 파일을다운로드하기위한 FTP 트래픽이급증했다. 호스트수의증가에따라 HOSTS.TXT 파일크기는증가하였고, 다운로드받는호스트수역시증가하였기때문이다. 이러한한계를극복하기위해 DNS 는 Paul Mockapetris 에의해 1983 년개발되었고, 1984 년인터넷에도입되었다. Internet & Security Focus 2013 9 월호 9
FOCUS DNS 는도메인이름 (Domain Name) 의각영역 (Domain) 별로이름의생성, 변경, 삭제등의관리를독자적으로수행할수있도록하였다. HOSTS.TXT 파일의관리체계에서호스트관리자가사소한변경이발생할때마다 NIC 에그변경사항을일일이반영하는절차를필요없게되었다. 대신 DNS 는자신의영역내에원하는이름의추가, 변경, 삭제를다른기관의협조없이독자적으로수행할수있게된것이다. 곧, 도메인 (Domain) 을확보하면, 그도메인영역내부에존재하는모든정보에대해서는배타적인소유권과관리권한을가지게된다. DNS 는계층적인트리 (tree) 구조를구성함으로써, 분산된네임관리체계를유지하면서도해당도메인내에서네임의중복이일어나지않는다면, 전체도메인네임에대해중복되지않는유일성 (uniqueness) 을유지할수있도록하였다. DNS 는분산구조데이터베이스시스템체계를구현함으로써 HOSTS.TXT 와같은전체호스트네임정보를갖는파일을매번다운로드할필요가없게하였다. DNS 정보를분산된 DNS 서버에분산저장하며, 언제든지그정보를조회할수있게하였다. 이를위해 DNS는서버-클라이언트 (Server-Client) 모델의프로토콜을채용하여, 클라이언트인리졸버 (resolver) 가무수히존재하는 DNS 서버들가운데원하는도메인이름의정보를소유한 DNS 서버를파악하고이정보를조회할수있도록하였다. DNS는기존방식의한계성을극복하면서도, 유연한확장성을가지는체계로개발되었다. 기존의호스트네임에대한네트워크주소변환이라는본연의기능외에네임에대하여다양한정보를연계하여제공할수있는데이터베이스체계를구성할수있게하였다는점이다. 즉, 도메인이름에대해네트워크주소를설정할수있으며, 동시에이도메인이름에대한설명문자열을설정할수도있다. 다양한인터넷자원 (Resource) 정보를도메인이름으로대표할수있도록한것이다. 인터넷자원정보는리소스레코드 (Resource Record) 라는데이터형식으로표현될수있으며, 이리소스레코드는필요에따라새로정의되어 DNS 에추가할수있다. DNS 가인터넷에도입된이후, 인터넷상의사람이이해할수있는주소체계와전산시스템이이해하는주소체계의연결점역할을하면서인터넷의필수적인기반시스템으로자리를잡았다. DNS 는인터넷의기반인프라시스템이며다양한인터넷어플리케이션이인터넷통신을위해 DNS 를사용하고있다. 2. DNS 의구성요소 DNS 는 1) 도메인이름공간 (Domain Name Space) 과리소스레코드 (Resource Record), 2) 네임서버 (Name Server) 그리고 3) 네임서버 (Name Server) 와리졸버 (Resolver) 로구성되어 10 Internet & Security Focus 2013 9 월호
있다. 도메인이름공간은도메인이름들이계층적구조로서로중복되지않는이름체계를갖도록되어있다. 도메인이름공간에서유일성을지난각도메인이름은리소스레코드 (Resource Record) 타입으로정의된유형의데이터를소유할수있다. 즉 DNS가분산구조데이터베이스라면도메인이름은이데이터베이스의데이터를조회하는데사용되는유일한갖을가진키인덱스 (Key Index) 값역할을한하고, 이인덱스와원하는유형의데이터타입곧리소스레코드타입을지정하면인터넷상의 DNS 에서해당데이터를조회할수있다 FOCUS [ 그림 1] DNS 구성개념도 1) 도메인이름공간 (Domain Name Space) 도메인이름공간은계층적구조를갖는트리구조로설계되었다. 그리고도메인이름공간의각영역을서브도메인 (Sub-Domain) 으로구분하여위임할수있도록하였다. 트리 (Tree) 구조에서각가지로분기되는지점을노드 (Node) 라고한다. 그림에서 kr, co, user-domain, lab, dev, beta, www, ftp 등이여기에해당한다. 각노드의이름을 Internet & Security Focus 2013 9 월호 11
FOCUS 레이블 (Label) 이라한다. 각레이블은 1~63 바이트길이를가질수있다. 루트 (Root) 레이블만 예외적으로 0 바이트의길이를갖는다. [ 그림 2] 도메인이름공간 (Domain Name Space) 특정노드는유일성을가져야한다. 즉트리구조와중복되지않는레이블을통해도메인이름은유일성을가질수있게된다는의미이다. 도메인이름은특정노드로부터루트까지이르는모든노드 (Node) 의레이블을점 (.) 으로연결한것이다. 예를들면 dev.lab.user-domain.co.kr. 형태와완전한도메인이름의형태가될것이다. 이와같이. 으로끝나는도메인이름을 FQDN(Fully Qualified Domain Name) 이라한다. 이때, 맨마지막의. 은루트레이블을의미하며통상적으로생략할수있다. 상위도메인에대해하위도메인을서브도메인 (Sub-Domain) 이라한다. 또다른표현으로는상위도메인을부모도메인 (Parent Domain), 하위도메인을자식도메인 (Child Domain) 이라한다. 상위도메인은하위도메인곧서브도메인을포괄한다. 즉 kr 도메인 은그하위의서브도메인인 co.kr 도메인, user-domain.co.kr 도메인 등을모두포괄하여통칭하는개념이다. 12 Internet & Security Focus 2013 9 월호
하나의도메인네임은최상위도메인의관리주체에의해관리되는것이아니라, 서브도메인으로구분된도메인영역을위임받은관리주체가이를관리한다. user-domain.co.kr 도메인을등록신청하여도메인을확보했다면, 이서브도메인영역에대해서는배타적인관리권한을위임받은것을의미한다. 도메인네임체계는이러한위임체계를기반으로분산구조의 DNS 를형성하고있다. FOCUS 2) 리소스레코드리소스레코드 (resource record) 는유일성을갖는도메인이름에설정할수있는다양한데이터유형을제공한다. 리소스레코드를축약하여 RR(Resource Record) 로표기한다. 앞서설명한바와같이, 도메인이름은중복되지않는키인덱스 (Key Index) 역할을한다. DNS 에서제공할수있는실제의정보는리소스레코드에의해정의된다. [ 그림 3] 리소스레코드포멧 리소스레코드는다양한데이터타입을갖는다. 곧, IP 주소데이터 (A RR) 만이아니라일반 문자열데이터 (TXT RR) 나, 제공하는서비스포트정보 (WKS RR), 지리정보 (LOC RR) 등과같은 Internet & Security Focus 2013 9 월호 13
FOCUS 데이터유형들이정의되어있다. 리소스레코드는확장성이커서, 필요에따라 DNS 에서다루는데이터종류를신규로정의함으로써지속적으로확장할수있다. 초기에정의된리소스레코드외에최근의 IPv6 도입에따라추가정의된 IPv6 주소데이터를위한 AAAA RR, 그리고 DNS 보안을위한보안확장프로토콜 DNSSEC 을위해 DNSKEY RR, RRSIG RR, NSEC RR, DS RR 등과같은데이터유형이필요에따라지속적으로추가정의되고있다. 현재까지정의된모든리소스레코드유형은 IANA(Internet Assigned Numbers Authority) 의웹사이트에서참고할수있다. 리소스레코드는해당레코드를소유하는도메인이름을지정하는 Owner Name 필드, 리소스레코드유형을지정하는 Type 필드, 리소스레코드의클래스를지정하는 Class 필드, 리졸버캐시에저장되는시간을표시하는 TTL 필드, 그리고리소스레코드의유형에따른리소스데이터 (Resource Data) 의사이즈및데이터를각각설정하는 RDLENGTH 필드와 RDATA 필드로구성된다. 리소스레코드포맷은네트워크상에서 DNS 메시지에포함되어전달된다. 네임서버에대한리졸버의 DNS 질의응답절차를통해리소스레코드는네임서버에의해 DNS 메시지로리졸버에게전달된다. 리졸버는응답받은리소스레코드를어플리케이션에전달하는한편, 자신이관리하는캐시메모리에저장하여관리한다. 이때에저장되는 (Caching) 시간은모든유형의리소스레코드에있는 TTL(Time To Live) 필드값에의해결정된다. 3) 네임서버 (Name Server) 와리졸버 (Resolver) 네임서버 (name server) 는도메인이름과도메인이름에대한리소스레코드데이터를저장하여인터넷으로부터의 DNS 질의에대하여해당하는리소스레코드를응답하는동작을수행하는서버이다. DNS에서존재하는도메인이름과리소스레코드데이터는네임서버에분산되어저장되어있다. 네임서버는도메인네임시스템의분산구조데이터베이스를구현한서버이다. 각네임서버는존 (zone) 으로구분된영역에속한리소스레코드데이터를가진다. 네임서버의존파일 (zone file) 은이렇듯해당네임서버가관리하는부분적인도메인데이터구역의도메인존과리소스레코드데이터내용을정의한파일이다. 네임서버는 TCP 와 UDP 포트 53번에대해 DNS 질의메시지를수신하고응답처리한다. 네임서버는서버- 클라이언트 (Server-Client) 모델에의해동작하며, 클라이언트에해당하는요소는리졸버 (resolver) 이다. 리졸버는인터넷상에산재하여존재하고있는네임서버들가운데에서특정한도메인이름에 14 Internet & Security Focus 2013 9 월호
대하여원하는유형의리소스레코드데이터를조회하는기능을수행한다. 네임서버에대하여클라이언트의역할을수행한다. ISP 와각회사및기관에서사용하고있는캐시네임서버 (Cache Name Server) 가리졸버이다. 리졸버는스스로리소스레코드데이터에대한질의동작을개시하는것이아니라, 응용어플리케이션의요청에의해질의절차를개시한다. 즉, 리졸버는응용어플리케이션을대신하여 DNS 질의응답을수행하고파악된데이터를응용어플리케이션에리턴한다. 리졸버와응용어플리케이션사이의인터페이스는응용프로그램인터페이스 (API, Application Programming Interface) 의형태를가진다. DNS는계층구조의네임체계를가지고있으므로, 리졸버는대상도메인이름이어느네임서버에그리소스레코드데이터가존재하는지를파악하기위해, 전체도메인네임의뿌리에해당하는루트도메인의네임서버로부터조회를시작한다. 루트네임서버는질의하는도메인이름이속하는위임된하위도메인에대한네임서버정보를리졸버에게알려준다. 이는루트네임서버의존 (Zone) 에설정된자식도메인의위임을표시하는 NS 리소스레코드정보에의해리졸버에게알려진다. 리졸버는계층구조를따라서최종네임서버까지파악하게되고, 최종네임서버는리졸버에게질의된리소스레코드정보를응답한다. FOCUS [ 그림 4] 네임서버 - 리졸버모델 Internet & Security Focus 2013 9 월호 15
FOCUS 네임서버 -리졸버모델은 리커시브네임서버 (recursive name server) 를중간에두는구성형태로하여구현되었다. 이리커시브네임서버를 캐시네임서버 (Cache Name Server), 또는 리졸빙네임서버 (Resolving Name Server) 라고도한다. 이모델에서 DNS 표준프로토콜규정에서의리졸버는리커시브네임서버의리졸버와호스트의스터브리졸버 (stub resolver) 로분리되어있다. 이같이분리된이유는과거 HW 성능이나인터넷상황이현재와같이좋지않은시절, 시스템자원과인터넷통신자원한계와같은제약때문에리졸버의대부분의기능을 DNS 서버에구현하고, 클라이언트호스트에는리졸버의단순한기능만을지닌리졸버를구현하게되었다. 스터브리졸버 (stub resolver) 는표준리졸버 (resolver) 의단순화된형태이며주로각시스템의 OS에포함되어있다. 이에비해전체기능을구현한리졸버는리커시브네임서버에포함되어존재하고있다. 스터브리졸버 (stub resolver) 와리졸버 (resolver) 의차이점은스터브리졸버는루트도메인네임서버로부터최종네임서버에이르는질의응답절차곧, iterative DNS 질의응답절차를수행하지않는다는점에있다. 따라서스터브리졸버는원하는리소스레코드가존재하는네임서버를스스로파악하여조회하는기능이없고, 별도로구축된리커시브네임서버에의존하여리소스레코드조회를수행한다. PC와같은사용자호스트에네트워크환경으로써설정하는 네임서버 정보는바로이호스트의스터브리졸버가 DNS 질의를해야하는리커시브네임서버의 IP 주소에해당한다. 반면에리커시브네임서버의리졸버는루트네임서버의 IP 주소정보를환경설정파일에가지고있다. 이는질의대상도메인이름에대하여루트네임서버로부터시작하는 iterative 질의응답절차를수행할수있으려면, 최소한루트네임서버의 IP 주소를먼저파악하고있어야하기때문이다. 루트네임서버의 IP 주소정보를지닌환경설정파일을흔히 root.hint 파일이라한다. 공식적인루트네임서버 IP 주소정보는 IANA 에서제공하고있다. 리커시브네임서버 (Recursive Name Server) 는네임서버 (Name Server) 와리졸버 (Resolver) 의두가지기능으로구성되어있다. 리커시브네임서버는캐시를관리한다. 캐시에는호스트의 DNS 질의에대하여인터넷상의네임서버에대해 iterative DNS 질의응답을수행하는가운데리졸버가파악하게된리소스레코드들을일시적으로저장하여관리한다. 동일한리소스레코드에대한호스트의 DNS 질의가발생하는경우, 캐시에존재하는리소스레코드데이터로응답함으로써, 리졸버에의한 iterative DNS 질의응답절차가반복적으로발생하는것을생략하도록한다. 이방식은루트네임서버를비롯한네임서버들에대한 iterative DNS 질의 16 Internet & Security Focus 2013 9 월호
트래픽을감소시킨다. 리커시브네임서버를구성함으로써 DNS 질의응답절차에있어서처리절차상의효율성을증가시킬수있다. 하나의도메인존 (zone) 데이터를호스팅하는네임서버는보통다수의서버플랫폼으로구성한다. 이는단일네임서버에장애가발생함으로인해해당네임서버가가지고있는도메인존데이터가함께인터넷에서조회불능상태가되어버리는상황을방지하기위한것이다. 하나의존 (zone) 에대한네임서버를구성하는다수의네임서버들은동일한도메인존 (zone) 의데이터를공유한다. 이다수네임서버중에서도메인존 (zone) 데이터를관리하는주된네임서버가있고, 이네임서버로부터변경갱신되는도메인존데이터를전송받아동기화된도메인존데이터를유지하는보조적인네임서버들이있다. 이때의도메인존 (zone) 데이터를전송하는절차를존전송 (Zone Transfer) 라한다. 주된네임서버를주네임서버 (primary name server), 나머지네임서버를보조네임서버 (secondary name server) 라고한다. 이들을각각마스터네임서버 (master name server), 슬레이브네임서버 (slave name server) 라고도한다. 주네임서버 (primary name server) 와보조네임서버 (secondary name server) 는존 (zone) 단위의관리적인측면에서이렇게구분하는것일뿐이며, 리졸버 (resolver) 의입장에서는 DNS 질의응답절차에있어서는이두가지네임서버를구분하지않는다. 리졸버는주네임서버 (primary name server) 와보조네임서버 (secondary name server) 를특정도메인존 (zone) 을호스팅하고있는동등한네임서버로취급하며, 이중에서네임서버를임의로선택하여 DNS 질의응답을수행한다. Authoritative 네임서버 는네임서버에직접설정된도메인존 (zone) 의데이터를참조하여응답하는네임서버를가리킨다. 곧, 리졸버가관리하는캐시의도메인데이터를참조하지않고직접설정된도메인존데이터만을사용하여응답하는네임서버이다. Authoritative 네임서버 에상대되는용어가리커시브네임서버또는캐시네임서버이다. 리커시브네임서버의 DNS 질의를수신하여응답하는네임서버기능부는리졸버기능부가 DNS 질의응답을통해저장관리하는캐시의데이터를참조하여응답처리한다는점에서 Authoritative 네임서버 와차별된다. 그러나현실적으로는리커시브네임서버기능과 Authoritative 네임서버기능을모두하나의네임서버에서처리하도록구성하는경우가많으므로, 네임서버의기능상구분에한정되고있다. 보안적인측면에서는 Authoritative 네임서버와리커시브네임서버를기능적으로구분하여각기능을전담하는네임서버로분리구축하는것을권장하고있다. FOCUS Internet & Security Focus 2013 9 월호 17
FOCUS Ⅲ. DNS 보안 1. DNS 보안취약점 전산시스템에대한해킹공격이심화되고있는현재, DNS 도예외는아니다. 리커시브네임서버의캐시데이터를위- 변조함으로써정상적인인터넷접속을방해하는공격형태도나타나고있다. 가장대표적인사건은 1997 년미국에서발생한사건으로, 당시인터넷도메인관리최상위기관이었던 InterNIC 의웹사이트에대한웹접속트래픽이제3의웹사이트로전환되도록 DNS 캐시포이즈닝 (cache poisoning) 을유발한사건이다. 이사건은 AlterNIC 의설립자였던유진카시푸레프 (Eugene Kashpureff) 에의해저질러졌다. 그는당시 InterNIC 이인터넷의상위도메인을독점하고있는것에대한강력한항의의표시로써, DNS 보안취약점을이용하여 InterNIC 사이트에접속하는트래픽을 AlterNIC 사이트로전환하게만들어버렸다. 이사건은 DNS 프로토콜의취약점을실제로드러낸사건으로써, 이취약성을활용하여마음먹은대로웹접속트래픽을제 3의서버로전환시켜버리는것이가능하다는것을여실하게보여주었다. 절의한 DNS 메세지패킷 IP Header Source Address Destination Address Source Port Destination Port = 53 UDP Header {IP Address, UDP port} UDP Socket Pair 일치검사 응답받은 DNS 메세지패킷 IP Header Source Address Destination Address Source Port = 53 Destination Port UDP Header Transaction ID= <Randon No Transaction ID= <Randon No QR =0 Opcode AA =0 TC RD RA Z AD CD RCODE QR =1 Opcode AA =1 TC RD RA Z AD CD RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT QNAME QTYPE QCLASS 질의메세지의 ID 와응답메세지 ID 일치여부검사 QDCOUNT ANCOUNT NSCOUNT ARCOUNT QNAME QTYPE QCLASS 응답메시지의각 Section 에설정된 응답데이터의위 - 변조여부를 확인할수있는방법이없음 {IP 주소, UDP 포트,Transaction ID} 가일치하는경우, 응답데이터를수용하여처리 - Answer Section: Resource Records Answer Section: Resource Records Answer Section: Resource Records [ 그림 5] DNS 메시지질의 응답패킷 18 Internet & Security Focus 2013 9 월호
이와유사한최근사건은 2011 년브라질에서 ISP 를대상으로 DNS 캐시포이즈닝공격을시도하여약 3~4 백만의 ISP 서비스이용자가 G메일, 유투브, MS 핫메일접속시악성프로그램설치프로그램설치웹사이트로유도되는사건이발생하였다. DNS 질의응답절차가운데, [ 그림 5] 와같이, 수신된응답메시지가이전에송출한질의메시지에대한응답인지여부는기본적으로는 IP 주소쌍과 UDP 포트번호쌍이질의시에사용된 UDP 소켓쌍 (UDP socket pair) 에합치하고, DNS 메시지의 ID 필드값이질의시의 ID와응답메시지의 ID 가동일한지를체크한다. 리커시브네임서버에게네임서버인것처럼위장하여변조된데이터를응답메시지로송출하는공격자는리커시브네임서버의질의메시지패킷이사용하는착신 / 발신 IP 주소, 착신 / 발신 UDP 포트정보를어렵지않은방법으로미리파악할수있다. 이파악된정보를사용하여 IP 헤더와 UDP 헤더정보를조작하여패킷을생성한다. 문제는 DNS 메시지의 ID 필드값을파악하는방법이다. 이 ID 값만정확히설정할수있으면, 리커시브네임서버가정당한응답메시지인것으로믿게만들수있다. DNS 취약성이본격적으로이슈화되기이전의네임서버들은 DNS 메시지 ID를순차적으로증가하는값을사용하도록구현하고있었다. 이당시에이러한네임서버로구성된리커시브네임서버의캐시에위-변조된데이터를삽입시켜설정하는것은어렵지않았다. FOCUS [ 그림 6] 캐시포이즈닝공격의예 Internet & Security Focus 2013 9 월호 19
FOCUS [ 그림 6] 은 DNS 메시지의 ID 필드값을파악한경우, 위조된응답패킷을발송함으로써리커시브네임서버를속이고캐시에원하는데이터를설정하도록유도하는방식의공격사례를보인것이다. 이사례와같은공격방식은현재에는오래된버전의 BIND DNS 와 Windows 서버 DNS 에서의캐시오염 (cache pollution) 방지설정이되어있지않은경우에한하여그공격이성공할수있는오래되고전통적인공격형태이다. 공격자가위변조하고자하는도메인존의도메인네임을대상으로하는 DNS 질의메시지를송출하고, 리커시브네임서버가 iterative DNS 질의를한후에수신하게될응답메시지인것처럼위-변조된 DNS 응답메시지패킷을리커시브네임서버로전송한다. 이때공격자는각헤더부분의값을적절히설정하여리커시브네임서버가응답메시지라고믿게함으로써, 자신이원하는값으로조작하여설정한각 Section 의리소스레코드데이터를캐시에반영하도록유도한다. [ 그림 6] 의예시에서보는바와같이 Answer Section 의리소스레코드값을위변조하면서동시에 Authority Section 과 Additional Section 에서 user-domain.co.kr 의네임서버정보를공격자가운영하고있는네임서버 ns.fake.co.kr 로리소스레코드데이터를변조설정함으로써이리커시브네임서버가이후에 user-domain.co.kr 에대한질의는공격자가관리하고있는네임서버로향하도록유도하고있다. 실제로이러한방식에의해리커시브네임서버는 user-domain. co.kr 존의네임서버가 ns1.fake.co.kr 서버라고믿고이서버에게이후의 iterative DNS 질의를하게된다. 리커시브네임서버가이러한위변조된응답메시지를단순하게믿게되고이데이터를캐시에반영하는동작을하는것은 DNS 표준자체의보안취약점에의한것이다. 리커시브네임서버가위-변조된응답메시지에대해이메시지에포함된위-변조된리소스레코드데이터를의심없이캐싱하는것은이메시지의리소스레코드에대해위-변조여부를확인할수단이존재하지않기때문이다. DNS 표준이처음개발될당시, 이러한 DNS 응답메시지의위-변조가능성에대해서는면밀한고려없이개발되었기때문이다. 2. DNSSEC 의개념 DNSSEC 표준은이와같은 DNS 의근본적인보안취약점을극복하기위해개발되었다. DNSSEC 표준은응답메시지의각 Section 에설정되는리소스레코드데이터자체를보호하기위해, 리소스레코드에대하여전자서명메커니즘을적용하는표준방안을제공한다. 20 Internet & Security Focus 2013 9 월호
절의한 DNS 메세지패킷 IP Header {IP Address, UDP port} UDP Socket Pair 일치검사 응답받은 DNS 메세지패킷 IP Header FOCUS Source Address Destination Address Source Address Destination Address Source Port Destination Port = 53 UDP Header Source Port = 53 Destination Port UDP Header Transaction ID= <Randon No Transaction ID= <Randon No QR =0 Opcode AA =0 TC RD RA Z AD CD RCODE QR =1 Opcode AA =1 TC RD RA Z AD CD RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT QNAME QTYPE QCLASS 질의메세지의 ID 와응답메세지 ID 일치여부검사 QDCOUNT ANCOUNT NSCOUNT ARCOUNT QNAME QTYPE QCLASS Answer Section: DNSSEC 표준은전자서명메커니즘을 DNS 에적용, 응답메시지의리소스레코드데이터에대한 위 - 변조검증기능추가 Resource Records + RRSIG(Signature) Answer Section: Resource Records + RRSIG(Signature) Answer Section: Resource Records + RRSIG(Signature) [ 그림 7] DNS 메시지질의 응답패킷 [ 그림 7] 과같이, DNSSEC 이적용되는핵심적인데이터보호부분은응답메시지의각 Section 에설정되어응답되는리소스레코드데이터들이다. 이와같이 DNSSEC 이적용되었을때, {IP 착발신주소, UDP 착발신포트번호, DNS 메시지트랜잭션 ID} 가일치한다하더라도, 응답메시지의 Answer Section 에설정된응답리소스레코드는이와함께제공되는서명데이터 (RRSIG RR) 를사용하여서명검증을통해이데이터가위변조된여부, 권한 (Authoritative) 네임서버가서명한원본데이터인지를검증해낼수있게된다. 이서명검증에의한데이터위변조여부의검증기능은리커시브네임서버로하여금각수신되는응답메시지의데이터를조사하고검증하여위변조된데이터와안전한데이터를분류하여캐시에관리하는것을가능하게한다. 따라서 DNSSEC 이적용된경우, 공격자는더이상 IP 헤더의 IP 주소와 UDP 헤더의 UDP 포트번호, DNS 메시지의트랜잭션 ID를조작하는방법만으로는리커시브네임서버를속일수없게된다. 이 3가지요소가질의된트랜잭션의그것과정확히일치하더라도, 이를바로캐시에반영하지않고, 이메시지가갖는리소스레코드에대한서명검증을수행하며이과정에서공격자의응답리소스레코드데이터는전자서명의견고한암호방식체계를위변조하지않는한리커시 Internet & Security Focus 2013 9 월호 21
FOCUS 브네임서버에의해위 - 변조데이터로판명되기때문이다. 3. DNSSEC 이력및동향 DNS 의근본적인문제인보안취약성을극복하고보안성을부여하기위한 DNSSEC 표준은 IETF 에서 1995 년경부터표준화작업이시작되었다. IETF 에서는 DNSSEC 워킹그룹을중심으로 DNS 에대한보안확장표준을개발하였다. 1999 년 RFC2535 표준문서을시작으로, DNSSEC 프로토콜이최종적으로완성된것으로여겨졌다. 그러나 1999 년의 RFC2535 문서로대표되는 DNSSEC 표준을실제적용하고및시험적으로운영하는가운데에있어서보안상의문제점과적용운영상의문제점이드러났다. 이에 IETF 의워킹그룹은이초기 DNSSEC 표준을대체할새로운 DNSSEC 표준을개발하기시작했다. 흔히이새로운표준을 DNSSECbis 라한다. 2번째 DNSSEC 표준화라는의미이다. DNSSECbis 표준은 2005 년 RFC4033, RFC4034, RFC4035 표준문서로써표준화작업이완료되었다. 2005 년말, 스웨덴은자신의최상위국가도메인인 SE. 도메인에 DNSSEC 을적용하였다. 유럽대륙의 RIR(Regional Internet Registries) 인 RIPE NCC 는자신의도메인과리버스도메인 (reverse domain) 에대하여 DNSSEC 을적용하였다. 이외에도 ISC(Internet Systems Consortium, Inc) 에서는 DNSSEC 을운영할수있도록하는네임서버 SW 인 BIND DNS 를제작하고배포하고 DNSSEC 을적용하였다. 그러나특히유럽지역에서 DNSSEC 표준에의해 DNSSEC 을본격적으로적용할때, DNSSEC 표준에서의 NSEC RR에의해도메인존내부의도메인네임과리소스레코드설정내역이모두공개될수있다는점이개인정보보호관련법률에위배될수있다는이유로 DNSSEC 적용을거부하는이슈가발생하였다. 실제로 DNSSEC 표준내용중 NSEC RR에의해, DNSSEC 이적용된도메인의내부설정내역이용이하게파악되었다. 이문제는존목록화 (Zone Enumeration) 이슈라고한다. Zone Walking 이슈라고도한다. 이이슈는.COM/.NET 을관리하고있는베리사인 (VeriSign) 과같은상업적인기업에게도중요한문제로받아들여지고있다. 실제로영국과독일등은이러한개인정보보호문제를근거로 DNSSEC 의자국도메인에대한적용을유보하는정책적태도를취하고있다. IETF DNSEXT 워킹그룹에서는 NSEC RR 에의한존목록화 (Zone Enumberation) 문제를해소하기위한추가표준화작업이진행되었다. 이는기존의 NSEC RR을대신하여존목록화 (zone enumberation) 문제를일으키지않을수있는 NSEC3 RR의표준규격이다. 22 Internet & Security Focus 2013 9 월호
이와같이 DNSSEC 표준은미비한사항을보완해가면서안정화를다져갔다. 2008 년, 백악관예산집행부 (OBM) 을시작으로.gov 의 DNSSEC 도입및.gov 의연방정부기 관도메인전체에 DNSSEC 을도입하도록요구하는지침을미국정부는배포하였다. 2009 년, FOCUS.org (Public Interest Registry) 의 DNSSEC 도입서명을하였으며 2009 년,.gov (General Services Administration, 미국조달청 ) DNSSEC 도입서명적용하였다. 2010 년 7월 15일, 루트도메인존의 DNSSEC 도입서명적용함으로써, DNSSEC 의궁극적인적용이가능해졌다. 2011 년, 베리사인 (VeriSign) 에서관리하는.com 및.net DNSSEC 도입서명적용하였으며, 우리나라는 2011 년부터 go.kr 을시작으로 2012 년까지 co.kr,. 한국에 DNSSEC 도입서명을하여모든국가도메인 (.kr/. 한국 ) 에 DNSSEC 도입을완료하였다. 그리고민간에서는 2012 년, 미국 ISP Comcast 가자사의캐시 DNS 서버에 DNSSEC 검증기능을활성화하였으며 2013 년, 글로벌 DNS 서비스제공중인 Google Public DNS 서비스의 DNSSEC 검증기능을활성화하여 DNSSEC 서비스를이용할수있게되었다. 그뿐아니라인터넷주소관리기구 (ICANN) 에서 2012 년부터진행되고있는신규일반최상위도메인 (gtld) 8) 신규신청을위해서는 DNSSEC 도입이의무화되어있다. 즉신규일반최상위도메인신청및관리기관획득을위해서는 DNSSEC 도입서명을해야하며, DNSSEC 운영계획을제출해야하는것이다. Ⅳ. 발전방향 DNSSEC 은기존 DNS 의본질적인보안취약점을보완하기위해표준화추진되었다. 그러나 DNSSEC 은단순히 DNS 데이터의위변조가능성에대한대응만을그목적으로하지는않는다. DNSSEC 의적극적인의미로는보안상신뢰할수있는데이터를제공할수있는 DNS 체계를구축하여, 인터넷상에서보안메커니즘을필요로하는시스템차원, 어플리케이션차원의보안인증관련데이터를높은신뢰성을갖춘도메인네임시스템을통해제공하는것이가능할수있다는점이있다. 이와관련하여, 초기 DNSSEC 표준화진행시에는개인의공개키정보와각응용어플리케이션의공개키등을배포할수있는글로벌키배포시스템으로서의기능을 DNS 이수행할수있도록 DNSSEC 표준자체에이러한기능을포함하여개발하기도했다. 이러한 8) 국가에서관리하는국가코드최상위도메인 (cctld) 와는다른, 특정한조직및계열에서사용되는최상위도메인예 ) com( 영리목적의기업이나단체 ), net( 네트워크를관리하는기관 ), org( 비영리기관 ) Internet & Security Focus 2013 9 월호 23
FOCUS 표준화를 DNS-based Authentication of Named Entities) 이라고한다. 이는공개키암호방식이유용한보안체계를제공하기는하지만, 글로벌범위에서의효율적인공개키배포문제는해소되지않고있었기때문에, DNS 의보안확장인 DNSSEC 을통하여각종공개키를 DNS 에저장하여보다용이하고보편적인방법으로배포할수있는체계를구현할목적으로하고있다. 초기 DNSSEC 표준안에는지금의 DNSKEY RR에해당하는 KEY RR에다양한형태의각종공개키정보를종류별로설정할수있도록정하고있었다. 그러나이렇게 KEY RR에수많은종류의공개키를설정하는방식이 DNS 자체의안정성을해칠수있는가능성이드러남으로써 DNSSECbis 표준안에서는 DNSKEY RR의새로운 RR을도입하면서, DNSKEY RR에는오직도메인존의공개키만을설정하도록제한하여표준으로정함으로써보편적인공개키배포기능을 DNSSECbis 표준의목표구현사항에서배제하였다. DNSSEC 표준사항에상위계층의응용어플리케이션이필요로하는공개키등인증관련정보를함께설정하는방식은인프라시스템인 DNS 자체의보안을불안정하게만들수있는문제가있으므로, 도메인네임시스템에대한표준인 DNSSEC 표준사항에서는제외하되각어플리케이션별로필요로하는인증정보를별도의리소스레코드를추가정의하여개별적으로활용하도록하였다. 이결과, IPSECKEY RR이나 SSHFP RR과같이개별어플리케이션에적합한데이터포맷을가진리소스레코드가정의되어추가되고있다. DNS 그자체로써인터넷의기반인프라관련정보를제공하는시스템이므로, 보안메커니즘을위한공개키등의인증정보를설정하는경우, 주로인프라차원의보안을위한정보를설정하는것이도메인네임시스템의특성에적합하다. SSHFP RR과같은경우, 로그인을위한사용자인증을위한데이터가아니라원격서버의시스템인증을위한인증데이터를저장하도록정의하고있다. 공개키암호방식을활용하는어플리케이션에있어서보안메커니즘에필요한공개키를보편적이면서도안전하고용이하게공개배포할수있는수단을필요로하고있다. 이미다양한어플리케이션이공개키암호방식의인증및암호화메커니즘을활용하고있다. 이에는 SSH(Secure Shell), IPSec(IP security), Mobile IP를비롯한많은어플리케이션이있으며앞으로개발될많은어플리케이션이있을수있다. SSH는보안취약점을갖는 TELNET 을대체하고있는원격서버접속프로토콜로써원격서버와보안채널 (secure channel) 을형성하여암호화된데이터송수신을제공한다. SSH 의경우, DNSSEC 이보편적으로적용된환경을상정하여 SSH 의보안접속시필요한서버의공개키에대한지문 (fingerprint) 데이터를 DNSSEC 이적용된도메인에설정하는방법을표준문서로 24 Internet & Security Focus 2013 9 월호
정의하고있다. DNS 의리소스레코드타입중 SSHFP(SSH FingerPrint) RR이그것이다. 이를사용하는경우, 최초로접속하는원격의서버가위장된서버인지여부를 SSH 클라이언트에서 DNSSEC 이적용된 DNS 질의응답을통해쉽게검증확인할수있다. 이외에 IPSec 의경우에도 IPSec 에필요한공개키를저장하는도메인네임시스템의리소스레코드타입으로써 IPSECKEY(IPSec Key) RR을표준으로정의하고표준리소스레코드타입으로등록하고있다. 또한다양한인증서 (certificate) 및인증서폐기목록 (certificate revocation list) 관련정보를 DNS 상에저장하고이를참조할수있도록 CERT(certificate) RR을표준리소스레코드타입으로정의하고있기도하다. 따라서, 앞으로글로벌하게운영되고있고운영의지속성이입증된 DNS 를통해공개키암호방식의인증및암호화매커니즘을사용할수있다면현재보다더욱강력한인터넷인프라로서의역할을수행할것이다. 그리고 DNS 는중요성이더욱부각되는만큼 DNS 보안성강화방안이연구될것이고새로운응용서비스들이개발을통해인터넷사용에기여할것이다. FOCUS 참고문헌 1. A Brief History of the Internet, http://www.isoc.org/internet/history/brief.shtml 2. Internet Timeline and History, http://www.inetassociation.com/timeline.html 3. IANA, DOMAIN NAME SYSTEM PARAMETERS http://www.iana.org/assignments/dns-parameters 4. RFC1035, DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION http://www.ietf.org/rfc/rfc1035.txt 5. IANA, Root Zone Hints File ftp://ftp.internic.net/domain/named.root, http://www.internic.net/zones/named.rootdns 캐시포이즈닝사례, tp://www.circleid.com/posts/brazil_facing_massive_dns_poisoning_attacks/ 6. Steven M. Bellovin, Using the Domain Name System for System Break-Ins, 1995 http://www.cs.columbia.edu/~smb/papers/dnshack.pdf 7. CERT RR, RFC4398, Storing Certificates in the Domain Name System (DNS), http://www.ietf.org/rfc/rfc4398.txt 8. IPSECKEY RR, RFC4025, A Method for Storing IPsec Keying Material in DNS, http://www.ietf.org/rfc/rfc4025.txt Internet & Security Focus 2013 9 월호 25