Presentation is loading. Please wait.

Presentation is loading. Please wait.

DNS(Domain Name System) 리눅스웨어㈜ 2012.4.25. Contents  DNS 란 ?  Domain Name 의 체계  DNS 질의 과정  실제 인터넷 환경에서의 DNS  Name Server 의 유형  DNS records 종류  Zone.

Similar presentations


Presentation on theme: "DNS(Domain Name System) 리눅스웨어㈜ 2012.4.25. Contents  DNS 란 ?  Domain Name 의 체계  DNS 질의 과정  실제 인터넷 환경에서의 DNS  Name Server 의 유형  DNS records 종류  Zone."— Presentation transcript:

1 DNS(Domain Name System) 리눅스웨어㈜ 2012.4.25

2 Contents  DNS 란 ?  Domain Name 의 체계  DNS 질의 과정  실제 인터넷 환경에서의 DNS  Name Server 의 유형  DNS records 종류  Zone 데이터베이스  도메인 위임  DNS 서비스 구조도  DNS 조회툴  SPF  기타

3 DNS 란  Domain Name System 이란 ? Domain Name System 이란 이름과 IP 주소를 매핑하여주는 거대한 분산 네이밍 시스템이다 61.100.184.171 IP Address www.mailplug.com Domain Name DNS( 도메인 네임 서버 )

4 Domain Name 의 체계

5 DNS 질의 과정

6 실제 인터넷 환경에서의 DNS

7 Name Server 의 유형  Primary name Server(authoritative)  Secondary name Server  Cache only server(recursive)

8 DNS records 종류  SOA(start of authority) : SOA 레코드는 해당 도메인에 대해 네임서버가 인증 (authoritative) 된 자료를 갖고 있음을 의미 하며, 자료가 최적의 상태로 유지, 관리될 수 있도록 한다.  NS : 해당 도메인의 네임서버를 지정  A : 해당 도메인의 실제 IP 주소를 부여  MX(Mail eXchange): 메일서버를 지정  CNAME(Canonical NAME) : 해당 도메인에 다른 이름을 부 여  HINFO(Host INFOmation) : 호스트 정보 지정  PTR : IP 주소에 대해 도메인을 매핑  TXT : 해당 도메인에 텍스트 정보 부여

9 Zone 데이터베이스 $TTL86400 @ IN SOA ns.nobreak.com. hostmaster.nobreak.com. ( 1998122801 ;Serial 21600 ;Refresh ( 6 hours) 1800 ;Retry (30 minutes) 1209600 ;Expire (14 days) 86400) ;Minimum ( 1 day) IN NS ns.nobreak.com. IN NS ns2.nobreak.com. IN MX 10 mail ; 메일 라우팅 호스트 mail IN A 210.105.79.2 ; Hosts Here - This is comments router IN A 210.105.79.1 ns IN A 210.105.79.2 ns2 IN A 210.105.79.3 power IN A 210.105.79.103 IN HINFO "Sun Sparc Ultra 5" "Solaris 2.6" IN TXT "Nobreak Technologies, Inc." www IN CNAME power

10 도메인 위임 도메인 위임이란 도메인을 여러 서브 도메인으로 나누어 각 서브 도메인의 관리를 다른 기관에 맡기는 것을 말한다. 부모 도메인은 서브 도메인의 데이터가 저장되어 있는 곳을 가리키는 포인터 만을 갖게 되며, 서브 도메인에 관련된 정보는 위임받은 하위 기관에서 관리한 다.

11 도메인 위임 ( 서브도메인 위임 예 ) $TTL86400 @ IN SOA ns.nobreak.com. hostmaster.nobreak.com. ( 1998122801 ;Serial 21600 ;Refresh ( 6 hours) 1800 ;Retry (30 minutes) 1209600 ;Expire (14 days) 86400) ;Minimum ( 1 day) IN NS ns.nobreak.com. IN NS ns2.nobreak.com. IN MX 10 mail ; 메일 라우팅 호스트 mail IN A 210.105.79.2 ; Hosts Here - This is comments router IN A 210.105.79.1 ns IN A 210.105.79.2 ns2 IN A 210.105.79.3 www IN CNAME power nms IN NS ns.nms ; Delegation IN NS ns2.nms ns.nms IN A 150.183.110.2 ; Glue Record ns2.nms IN A 150.183.110.3

12 DNS 서비스 구조도 Internet US PC : 10.0.7.22 www.aaa.com Root L4 Cache DNS : 168.126.63.1 ISP DNS KT/SK 브로드밴드 등.com Root NS Ns2.aaa.com 도메인등록기관 (NIDA, Verisign 등 ) 1. 호스트추가 2. 네임서버 등록 Ns1.aaa.com Ns2.aaa.com NS Ns1.aaa.com # dig @e.gtld-servers.net serverchk.com Cache DNS www.aaa.com 서비스업체

13 DNS 조회툴 (nslookup)  Windows / Linux 에서 기본 제공됨

14 DNS 조회툴 (nslookup)  기본 쿼리서버 변경 nslookup 은 기본적으로 recurse 모드로 동작하기 때문에, 때론 해당 도메인의 Authority 를 갖는 특정 네임서버에 직접 질의를 하여 Authoritative 응답 ( 네임서버의 캐쉬에서가 아닌 ) 을 확인 할 필요가 있다. server, lserver 명령으로 기본 질의 서버를 변 경 할 수 있다. $ nslookup Default Server: ns.nobreak.com Address: 210.105.79.2 > server ns.jp.freebsd.org. # 기본 서버 변경 Default Server: ns.jp.freebsd.org Address: 199.100.7.25

15 DNS 조회툴 (dig)  Query Option A / MX / NS / TXT / SOA … TTL(Time To Live)

16 SPF 란 ? 발송자 도메인 : 사전에 발신 메일서버의 정보 (IP) 와 메일정책을 자신의 DNS 에 SPF 레코드 형식으로 등록 수신자 도메인 : DNS 에 등록된 SPF 레코드를 조회 / 확인 하고, 결과값에 따라 메일의 수신여부 결정

17 SPF 문법 (1)  Prefix Prefix 결과값내용 ?Neutral 출판된 데이터에 근거해 판단을 내릴 수 없음 +Pass 가 인가되어진 발송서버로 확인됨 -Fail 가 인가되어지지 않은 발송서버로 확인됨 ~SoftFail 는 인가되지 않은 발송서버이나 “Fail” 정책의 적용은 유보함.

18 SPF 문법 (1) 1. all (all) all 메커니즘은 모든 경우에 해당되며 항상 모든 레코드의 마지막에 위치한다. “v=spf1 -all” 해당 도메인은 메일을 발송하지 않음을 명시함. 2. a (a, a:domain, a:domain/cidr-length, a/cidr-length) 해당 도메인의 모든 a 레코드 중 하나가 발송 호스트의 IP 와 일치 하도록 할 때 이 메커니즘이 적용된다. 도메인 명이 명시되지 않은 경우 현재의 도메인이 사용된다. “v=spf1 a -all” 현 도메인 명이 사용되며 도메인의 A 레코드가 발송 호스트의 IP 와 동일한 서버만 메일을 발송하며 그 이외의 어떤 호스트에서도 메일을 발송하지 않음. “v=spf1 a:example.com -all” 발송호스트의 IP 가 example.com 의 A 레코드와 동일한 서버만 메일을 발송하며 그 이외의 어떤 호스트에서도 메일을 발송하지 않음. “v=spf1 a:mailer.example.com -all” 발송호스트의 IP 가 mailer.example.com 의 A 레코드와 동일한 서버만 메일을 발송하며 그 이외의 어떤 호스트에서도 메일을 발송하지 않음.

19 SPF 문법 (2) 3. mx (mx, mx:domain, mx:domain/cidr-length, mx/cidr-length) 해당도메인의 모든 mx 레코드의 A 레코드 중 하나가 발송호스트의 IP 와 일치 하도록 할 때 이 메커니즘이 적용된다. 도메인이 명시되어 있지 않을 때 현재 도메인 명이 사용된다. “v=spf1 mx mx:deferrals.example.com -all ” 발송호스트 IP 가 발송도메인의 mx 레코드 중 하나의 IP 와 일치하거나 deferrals.domain.com 의 mx 레코드 중 하나의 IP 와 동일한 서버만 메일을 발송하며 그 이외의 어떤 호스트에서도 메일을 발송하지 않음. “v=spf1 mx/24 mx:offsite.domain.com/24 -all” 발송호스트의 IP 가 발송도메인의 mx 레코드 의 C- 클래스 네트워크 주소중의 하나가 발송지의 IP 와 일치하거나 외부도메인 (offsite.domain.com) 의 mx 레코드의 C- 클래스 주소중의 하나가 발송호스트의 IP 와 동일한 서버만 메일을 발송하며 그 이외의 어떤 호스트에서도 메일을 발송하지 않음. 4. ptr(ptr, ptr:domain) 발송 호스트의 PTR 쿼리를 통해 얻어진 호스트 명의 A 레코드가 발송 IP 와 일치 할 때 이 메커니즘이 적용된다. 도메인이 명시되어 있지 않을 때 현재 도메인 명이 사용된다. “v=spf1 ptr -all” 발송호스트의 IP 의 ptr 쿼리가 현재 도메인 이름과 일치하는 호스트만 메일을 발송하며 그 이외의 어떤 호스트에서도 메일을 발송하지 않음. “v=spf1 ptr:otherdomain.com -all” 발송호스트의 IP 의 ptr 쿼리가 “otherdomain.com” 과 일치할 경우 메일발송을 허가하며 그 이외의 어떤 호스트에서도 메일을 발송하지 않음.

20 SPF 문법 (3) 5. ip4 발송호스트의 IP 를 CIDR 로 정의된 네트워크의 IP 범위 내에 위치시킬 때 이 메커니즘이 적용된다. CIDR 의 범위를 한정하는 “/xx” 이 명시되지 않을 경우에 이는 /32 가 생략된 것으로 정의된다. “v=spf1 ip4:192.168.0.1/16 ?all” 발송호스트의 IP 가 192.168.0.1/16 범위에 있는 호스트만 메일을 발송하며 그 이외의 어떤 호스트에서도 메일을 발송하지 않음. 6. ip6 IPv6 의 발송대역을 정의

21 SPF 예제 ( 메일플러그 )  메일플러그 서비스 도메인의 SPF 룰 "v=spf1 mx include:mailplug.com ~all“  Mailplug.com SPF 룰 "v=spf1 ip4:121.156.118.122 ip4:74.200.70.68 ip4:121.78.227.188 ip4:121.78.227.189 ~all"

22 기타 I  DNS 와 BIND 의 차이 DNS 는 Domain Name System 의 약자로써, 분산 네이밍 시스템을 뜻한다. 조금 쉽게 풀어보면, 도메인명을 IP 주 소로 변환해주는 방법론이다. BIND 는 Berkeley Internet Name Domain 의 약자로, DNS 를 구현한 소프트웨어의 하나이면서, ' 워크맨 ' 이란 단어처럼 DNS 를 구현한 소프트웨어를 칭하는 대명사로 쓰이기도 한다. BIND 는 거의 모든 플랫폼에 포팅되었고, 가장 널리 사용된다.

23 기타 II  글루 레코드 (Glue Record) 글루 레코드는 NS 레코드의 인자로 주어지는 A 레코드 를 말하며, 네임서버에 부트스트랩 정보를 제공한다. 다 음의 경우 ns.nms.nobreak.com 이 글루 레코드이다. nms.nobreak.com. IN NS ns.nms.nobreak.com. ns.nms.nobreak.com. IN A 150.183.110.2 ; 글루 레코드

24 기타 III  Authoritative answer & Non-authoritative answer Name Server 는 질의에 대한 결과를 캐쉬에 저장하고 있기 때 문에 같은 질의가 요구되었을 때 Namespace 를 뒤지지 않고 캐쉬의 자료로 빠르게 응답한다. 캐쉬의 자료는 Resolving 시 얻은 TTL(Time To Live) 시간 동안 에만 유효하고, TTL 경과후에는 파기된다. 클라이언트의 도메인 Resolving 요청시 네임서버가 캐쉬의 자 료로 응답 할 경우는 Non-authoritative answer 이고, 캐쉬에 자 료가 없거나, 자료의 TTL 이 만기되어 해당 도메인의 Primary 네임서버에서 직접 자료를 얻어 답변을 주었을 경우가 Authoritative answer 이다.

25 기타 IV  Positive & Negative Caching 네임서버는 한번 검색한 도메인 정보를 캐쉬에 유지하여, 후에 요 청될 같은 질의를 효율적으로 대처하도록 구현되어 있다. 그렇다면, 존재하지 않는 도메인에 대한 요청은 어떻게 할까 ? 일반적으로 잘못된 도메인에 대한 요청도 많이 중복된다. 또한 이 경우 네임서버는 가능한 가지를 모두 탐색하므로, 불필요한 인터 넷 트래픽 증가라는 문제도 제기된다. 따라서, 네임서버는 이렇듯 잘못된 쿼리에 대한 결과도 캐싱하여 불필요한 트래픽을 차단한다. 이를 Negative 캐싱이라 하며, 반대 로 검색이 되는 도메인에 대한 캐싱을 Positive 캐싱이라 한다.

26 기타 V  mailplug DNS 구성


Download ppt "DNS(Domain Name System) 리눅스웨어㈜ 2012.4.25. Contents  DNS 란 ?  Domain Name 의 체계  DNS 질의 과정  실제 인터넷 환경에서의 DNS  Name Server 의 유형  DNS records 종류  Zone."

Similar presentations


Ads by Google