|
(0) 
(0)(0) (0)'DNS'에 해당되는 글 10건
- 2006/12/22 HOW-TO Configuration zone file
- 2006/12/22 HOW-TO Configuration named.conf
- 2006/12/22 Name Server의 운영 [ 구동과 동작확인]
- 2006/12/22 Name Server 운영
- 2006/12/22 메일에 관련된 잡담..... 제2화 (DNS 는 모냐.~~ 난 Reverse DNS가 몬지 몰라~)
- 2006/12/21 HOW-TO Configuration reverse zone file
- 2006/11/17 DNS MX 레코드 설정하기
- 2006/11/17 DNS Forwarder(전달자) 설정하기
- 2006/11/17 NSLOOKUP
- 2006/09/18 [펌]리버스 DNS 문의 드립니다
(0) (0)
|
(0) (0)2.6. Name Server 구동
네임서버를 구동하기 위한 설정이 마무리되었다. 관련 파일들이 준비되었음을 확인한 후, 네임서버를 구동하자. 일련의 과정은 다음과 같다.
* NS.NOBREAK.COM (BIND-8)
# ls /etc/named.conf # BIND-8 부트 파일
/etc/named.conf
# ls /var/named/ # Zone 데이터베이스 파일 확인
named.root
zone-0.0.127.in-addr.arpa
zone-79.105.210.in-addr.arpa
zone-nobreak.com
# /usr/sbin/named # 네임 데몬 구동 (Solaris: /usr/sbin/in.named)
# ps ax | grep named # 프로세스 동작 확인 (Solaris: ps -e | grep in.named)
254 ? S 0:00 named
* NS2.NOBREAK.COM (BIND-4)
# ls /etc/named.boot # BIND-4 부트 파일
/etc/named.boot
# ls /var/named/ # Zone 데이터베이스 파일 확인
named.root
zone-0.0.127.in-addr.arpa
# ndc start # ndc(Name Daemon Control)가 설치되어 있을 경우
Name Server Started
# ndc status
254 ? S 0:00 named
# ls /var/named/ # Primary의 Zone 전송여부 확인
named.root
sec-79.105.210.in-addr.arpa
sec-nobreak.com
zone-0.0.127.in-addr.arpa2.7. Name Server 동작 확인여기에선 [그림 3]의 가상 네트워크 구성도에 따른 설정을 다루었지만, 기본적으로 필요한 부분은 모두 적용되어 있으므로 실제 네트워크에 적용할 때에도 같은 느낌으로 설정하면 된다. 다음과 같이 타 네임서버를 통해 질의를 던져봄으로써, Namespace 가지상에 잘 연결되어 있음을 확인하자.
$ nslookup power.nobreak.com ns.nobreak.com # Primary 동작 확인 Server: ns.nobreak.com Address: 0.0.0.0 Name: power.nobreak.com Address: 210.105.79.103 $ nslookup power.nobreak.com ns2.nobreak.com # Secondary 동작 확인 Server: ns2.nobreak.com Address: 210.105.79.3 Name: power.nobreak.com Address: 210.105.79.103 $ nslookup power.nobreak.com ns.kornet.ne.kr # Namespace 링크 확인 Server: ns.kornet.nm.kr Address: 168.126.63.1 Name: power.nobreak.com Address: 210.105.79.103위의 3가지 질의가 성공적으로 수행되었다면, 일단 네임서버가 정상적으로 운용된다고 생각해도 좋다. 확실히 하기 위해선, 로그파일 분석을 통해 Zone 데이터베이스 구성상의 오류와 BIND의 동작 상태를 살펴보아야 한다.
(0) (0)
 2.1. Name Server 유형 |
Primary server는 해당 도메인을 관리하는 주 네임서버이고, Secondary server는 특정 도메인에 대한 back-up copy를 유지하는 서버이다. Secondary는 Primary가 비정상 운행될 때와 부하를 분산시키기 위해 운용하며, 다수가 존재할 수 있다.
보통 도메인을 관리하기 위해서는 Primary, Secondary 서버가 필요하게 되며, Secondary는 원칙적으론 외부 네트웍에 위치시켜 정전 등의 사태로 Primary가 다운되었을 때를 대비한다. 따라서, 도메인을 운영하기 위해서는 최소 2대(Primary * 1, Secondary * n) 이상의 네임서버가 요구된다.(기술적으로 Resolver의 입장에서는 Primary와 Secondary가 구분되지 않기에 Primary 만으로도 운영은 가능하나 권고되진 않는다)
Cache only server는 도메인에 대한 데이터를 관리하지는 않고, resolving만을 처리해 준다. 만약, 본사와 지사가 있고 이 회사의 Primary, Secondary Name server가 모두 본사에 위치한다고 할 때, 지사에 위치한 네트워크 유저들은 Local DNS server가 없게 된다. 이럴 경우 도메인 resolving이 요구될 때마다 다른 네트워크(본사)로 접속을 시도하게 되므로 약간의 딜레이가 생기게 되며, 본사 네트워크가 단절 되었을시 지사도 실질적으로 인터넷 사용이 불가능한 단점이 있다. 이럴 때 지사에 Cache only server를 운용하면 효과적으로 문제를 해결할 수 있다.
2.2. BIND(Berkeley Internet Name Daemon) 설치
Name server를 운용하기 위해서는 서버측 데몬 프로그램이 필요하게 되는데, 이중 BIND는 db 파일의 구성이 손쉽고 표준을 충실히 따른 검증된 도구로서 인터넷에서 가장 널리 사용된다. 대부분의 Unix 시스템에서는 BIND가 이미 설치되어 있다. /usr/sbin 디렉토리에 in.named 혹은 named가 존재함을 확인하고, BIND가 이미 설치되어 있을 경우에는 다음과 같이 설치된 BIND의 버전을 확인한다. (BIND가 동작중이여야 함)
$ dig @ns.nobreak.com txt chaos version.bind. | grep VERSION
VERSION.BIND. 0S CHAOS TXT "8.2"
배포처인 ISC(Internet Software Consortium) 에서 BIND의 최신버젼을 확인하고, 버전차이가 많거나 현재 버전에 심각한 문제가 보고되었다면, 업그레이드를 고려하고, BIND-4가 설치되어 있다면, BIND-8로 마이그레이션하여 새로운 흐름에 조인하는것도 나쁘지 않겠다.
BIND의 설치는 매우 간단하다. ISC FTP사이트에서 최신 버전의 소스를 내려받아, 압축을 푼후 다음과 같은 명령을 입력하는 것이 설치에 필요한 전부이다.
# make clean depend all install
그리고, 시스템 rc 스크립트를 적절히 수정하여 시스템 부팅시 BIND가 자동으로 구동될 수 있도록 한다. (FreeBSD: /etc/rc.conf, /etc/rc.network, Solaris: /etc/init.d/inetsvc, Linux: /etc/rc.d/init.d/named)
Windows NT, OS/2, MacOS 등에서 BIND를 운용하고자 한다면, 다음 페이지를 참고하자.
http://www.dns.net/dnsrd/docs/exotic.html
2.3. 퍼블릭 도메인(Public Domain) 신청
Primary, Secondary 네임서버가 준비되었고 신청할 도메인이 결정되었다면, 상위 도메인 관리 기관(kr 도메인의 경우 KRNIC, com/net/org 등의 도메인은 Network Solutions을 대표로 ICANN의 심사를 획득한 등록 대행 업체들)에 도메인을 신청하여 발급(네임스페이스상에 링크) 받게 된다. 도메인 신청양식은 기관마다 조금씩 상이하지만 일반적으로 사용기관, 책임자, 관리자, 결제자 , 네임서버 정보가 요구된다. 이중 신청 도메인을 네임스페이스에 링크하기 위한 네임서버 정보는 다음과 같이 작성한다.
2. Complete Domain Name.......: NOBREAK.COM
7a. Primary Server Hostname....: NS.NOBREAK.COM
7b. Primary Server Netaddress..: 210.105.79.2
8a. Secondary Server Hostname..: NS2.NOBREAK.COM
8b. Secondary Server Netaddress: 210.105.79.3
"NOBREAK.COM"이 등록되었다는 메시지를 받았다면, 다음과 같이 해당 도메인의 등록 여부를 확인한다.
$ nslookup -type=ns nobreak.com
Server: ns.nobreak.com
Address: 0.0.0.0
nobreak.com nameserver = ns.nobreak.com
nobreak.com nameserver = ns2.nobreak.com
ns.nobreak.com internet address = 210.105.79.2
ns2.nobreak.com internet address = 210.105.79.3
해당 도메인에 대한 네임서버가 신청한 것과 같이 표시된다면, 등록이 바르게 진행된 것이다. 아직 등록이 안되었다면, 다음과 같은 메시지를 볼 수 있다.
*** local.name.server can't find nobreak.com.: Non-existent host/domain
"도메인 NOBREAK.COM을 신청하는데 어떻게 그 하부에 있는 NS.NOBREAK.COM, NS2.NOBREAK.COM을 사용할수 있습니까?" "NS.NOBREAK.COM은 NOBREAK.COM 도메인 신청이 완료된 후 네임서버에서 설정 해주어야 사용할 수 있지 않습니까?"라는 의문이 들 수 있는데, 어떤 도메인을 하위 도메인으로 위임하기 위한 네임서버 정보는 상위 도메인에서 관리되기 때문에 가능하다. (참고: "글루 레코드")
2.4. 인버스 도메인(Inverse Domain) 신청
인버스 도메인은 IP에 대해 해당 도메인을 역으로 찾을 수 있도록 하는 서비스이다. 보통 ISP(Internet Service Provider)에서 IP를 할당받을 때 같이 신청한다. 다음과 같이 인버스 도메인에 대한 네임서버가 in-addr.arpa 네임스페이스에 등록되어 있는지 확인한다.
$ nslookup -type=ns 79.105.210.in-addr.arpa (C Class 210.105.79.x를 할당 받았을 경우)
Server: ns.nobreak.com
Address: 0.0.0.0
79.105.210.in-addr.arpa nameserver = ns.nobreak.com
79.105.210.in-addr.arpa nameserver = ns2.nobreak.com
ns.nobreak.com internet address = 210.105.79.2
ns2.nobreak.com internet address = 210.105.79.3
만약 다음과 같은 메시지가 나온다면, 인버스 도메인 등록이 안되어 있는 것이므로, 해당 ISP에 신청하여야 한다.
*** ns.nobreak.com can't find 79.105.210.in-addr.arpa.: Non-existent host/domain
다음은 nobreak.com 도메인에 대한 가상 네트워크 구성도 이다.
Figure 2-1. 네트워크 구성도
네트워크엔 서버가 3대 연결되어 있다. DNS를 구축하기 전에, 그림과 같이 미리 각 서버에 호스트명과 IP를 부여하자. 보통 네임서버는 ns(primary), ns2(secondary)를 호스트명으로 사용하고, IP 1(할프로 받았을 경우엔 129)을 라우터 혹은 스위치, 2를 NS, 3을 NS2에 할당한다. 도메인 NOBREAK.COM은 앞서 등록기관에 신청하였으니, NS.NOBREAK.COM, NS2.NOBREAK.COM에 네임서버 설정을 하면 된다.
2.5.1. BIND-4 부트 파일 named.boot
BIND-4 부트 파일 named.boot는 BIND 시동시 참조되며, 네임 데몬이 필요로 하는 환경정보와 운영할 도메인에 대한 Primary/Secondary 설정이 기술된다. 일반적으로 시스템의 /etc/named.boot에 위치하며, 대부분의 유닉스 스타트업 스크립트는 부트 파일이 존재하면 시동시 BIND를 자동으로 구동한다. 부트 파일상의 모든 엔트리는 반드시 1열 에서 시작하여야 하며 ';'은 주석을 의미한다.
directory /var/named
directory 엔트리는 관련 파일들이 위치한 경로를 나타낸다. 이 경로는 부트 파일에 나타나는 파일들의 베이스 경로로 작용한다. 따라서 파일들은 본 경로를 기준으로 상대경로 표기해야 하며 여기서는 /var/named 디렉토리를 베이스 디렉토리로 한다. (대부분의 시스템 기본 베이스 경로는 /var/named, /etc/named 혹은 /etc/namedb이다)
cache . named.root
cache 레코드는 말 그대로의 캐쉬가 아니라 루트 네임서버 정보가 들어있는 데이터베이스 파일을 나타낸다. BIND는 타 도메인 정보를 루트 네임서버에서부터 추적하는데, 이 루트 네임서버에 대한 정보를 본 파일에서 참조하게 된다. /var/named/named.root와 같이 베이스 디렉토리에 위치시키면 된다.
캐쉬 파일은 Internic(현재는 존재하지 않고 일부 서비스만이 남아있다)에서 배포하며 ftp://ftp.rs.internic.net/domain/named.root 에서 구할 수 있다. 루트 네임서버 목록이 자주 수정되진 않지만 조금씩 바뀌기 때문에, 한달 걸러 한번씩은 업데이트 해줄 필요가 있다. 스크립트를 Cron으로 정기적으로 수행해 캐쉬 파일을 업데이트하는 것도 좋은 방법이다.
primary nobreak.com zone-nobreak.com
해당 도메인에 대해 Primary 네임서버로 동작함을 말한다. 예는 nobreak.com 도메인에 대해 본 서버가 Primary 이며, 데이터베이스 파일은 /var/named/zone-nobreak.com 임을 나타낸다.
secondary nobreak.com 210.105.79.2 sec-nobreak.com
도메인에 대해 Secondary 네임서버로 동작한다. 세 번째 필드는 Primary 네임서버의 IP 주소이고, 네 번째 필드는 Primary에서 전송 받은 zone 파일이 저장될 파일명이다. 210.105.79.2로부터 nobreak.com 도메인의 데이터베이스를 전송(Zone Transfer)받아 /var/named/sec-nobreak.com로 관리함을 뜻한다.
Figure 2-1의 네트워크에 대한 부트 파일은 다음과 같이 작성될 수 있다.
* NS.NOBREAK.COM(Primary NS)의 /etc/named.boot 파일
directory /var/named
cache . named.root
primary 0.0.127.in-addr.arpa zone-0.0.127.in-addr.arpa ; loopback
primary 79.105.210.in-addr.arpa zone-79.105.210.in-addr.arpa ; Reverse ZONE
primary nobreak.com zone-nobreak.com ; Forward ZONE
0.0.127.in-addr.arpa는 loopback 주소 127.0.0.1를 위한 것이다. loopback 주소가 사용되지 않는 시스템은 없기 때문에, 'primary 0.0.127.in-addr.arpa ...'와 같은 라인은 네임서버마다 갖고 있다. 그 다음 두 라인이 할당받은 C Class IP 블락 210.105.79와 도메인 nobreak.com 을 위한 설정이다.
* NS2.NOBREAK.COM(Secondary NS)의 /etc/named.boot 파일
directory /var/named
cache . named.root
primary 0.0.127.in-addr.arpa zone-0.0.127.in-addr.arpa
secondary 79.105.210.in-addr.arpa 210.105.79.2 sec-79.105.210.in-addr.arpa
secondary nobreak.com 210.105.79.2 sec-nobreak.com
Secondary 네임서버 설정이다. loopback은 Primary로 놓아둔다. Secondary의 설정은 이것이 전부이다. (/var/named/zone-0.0.127.in-addr.arpa는 있어야 함)
Secondary는 해당 도메인의 Primary에 접속하여 데이터 베이스를 전송받아, sec-79.105.210.in-addr.arpa, sec-nobreak.com으로 저장, 관리한다.
2.5.2. BIND-8 부트 파일 named.conf
BIND-4와 BIND-8의 관련 파일 작성법중 유일하게 차이가 나는 부분이 바로 이 부트 파일이다. BIND-8 부트 파일의 기본적인 구성은 BIND-4와 비슷하지만, 많은 부분 추가 확장되었기 때문에, 이를 수용하고 앞으로의 추가사항을 손쉽게 적용할 수 있도록 파일 포맷이 변경되었다. 그리고 구버젼 부트 파일과의 혼동을 막기위해 named.conf로 리네임 되었다. 어떻게 보면 C 언어의 문법과 매우 흡사한 것을 알 수 있다. 설정을 좀더 세밀하게 할 수 있도록 작성법이 바뀌었을 뿐, BIND-4의 부트 파일과 크게 다를 것은 없다. 다음은 앞서 작성한 BIND-4 기반 부트 파일을 BIND-8에 맞게 변환한 예이다. 일반적으로 BIND-8 기반의 부트 파일은 다음에 나열된 레코드정도만이 활용되지만, 재미난 부분이 많으므로 좀더 깊숙히 알고 싶다면 http://www.isc.org/products/BIND/docs/ 를 참고하기 바란다.
다음은 Primary 네임서버를 위한 부트 파일이다.
* NS.NOBREAK.COM(Primary NS)의 /etc/named.conf 파일
// 이것은 주석이다. BIND-8에서 ';'은 주석이 아니라, 라인의 끝을 의미한다.
options {
directory "/var/named"; // Zone 파일의 베이스 디렉토리
dump-file "/var/tmp/named_dump.db"; // Dump 파일이 생성되는 경로
statistics-file "/var/tmp/named.stats"; // 통계 파일이 생성되는 경로
pid-file "/var/run/named.pid"; // 프로세스 ID가 담긴 파일 생성 경로
};
logging { // 불필요한 정보를 로그파일에 남기지 않는다.
category lame-servers { null; };
category cname { null; };
category response-checks { null; };
category notify { null; };
};
zone "." IN { // 캐쉬 파일
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" IN { // localhost를 위한 Primary 도메인 설정
type master;
file "zone-0.0.127.in-addr.arpa";
};
zone "79.105.210.in-addr.arpa" IN { // 할당 IP 블락에 대한 Reverse Zone
type master;
file "zone-79.105.210.in-addr.arpa";
};
zone "nobreak.com" IN { // 도메인 nobreak.com 에 대한 Forward Zone
type master;
file "zone-nobreak.com";
};
Secondary 네임서버를 위한 부트 파일은 다음과 같이 작성된다.
* NS2.NOBREAK.COM(Secondary NS)의 /etc/named.conf 파일
options {
directory "/var/named";
};
logging {
category lame-servers { null; };
category cname { null; };
};
zone "." IN {
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" IN { // localhost를 위한 Primary 도메인 설정
type master;
file "zone-0.0.127.in-addr.arpa";
};
zone "79.105.210.in-addr.arpa" IN { // Reverse Zone에대한 Secondary 설정
type slave;
file "sec-79.105.210.in-addr.arpa";
masters { 210.105.79.2; }; // Primary NS의 IP 주소
};
zone "nobreak.com" IN { // nobreak.com 의 Secondary 설정
type slave;
file "sec-nobreak.com";
masters { 210.105.79.2; };
};2.5.3. 리소스 레코드(Resource Record)Zone 파일은 Forward, Reverse 두 가지로 구분된다. Forward Zone은 도메인에 대한 IP 정보를 갖고 있는 데이터베이스이고, Reverse Zone은 IP에 대한 도메인정보를 갖는 데이터베이스이다. 앞서 named.boot 파일에 네임서버가 loopback, 79.105.210.in-addr.arpa, nobreak.com 도메인에 대해 Primary로 동작하도록 설정하였다. 이중 zone-0.0.127.in-addr.arpa와 zone-79.105.210.in-addr.arpa가 Reverse Zone 파일이고, zone-nobreak.com이 Forward Zone 파일이다. Zone 파일은 BIND-4와 BIND-8에서 작성법이 동일하다.
먼저 Figure 2-1의 네트워크 구성에 따라 Forward Zone 파일 zone-nobreak.com을 작성하여 보자.
2.5.3.1. SOA 레코드 (Start Of Authority)
Zone 파일은 항상 SOA 레코드로 시작한다. SOA 레코드는 해당 도메인, nobreak.com에 대해 네임서버가 인증(authoritative)된 자료를 갖고 있음을 의미하며, 자료가 최적의 상태로 유지, 관리될 수 있도록 한다.
nobreak.com. IN SOA ns.nobreak.com. hostmaster.nobreak.com. ( 1998122800 ;Serial 21600 ;Refresh ( 6 hours) 1800 ;Retry (30 minutes) 1209600 ;Expire (14 days) 86400) ;Minimum ( 1 day)1열에는 해당 Zone 파일에 대한 도메인명이 들어간다. 도메인명 끝의 도트를 잊지 말자. 다음과 같이 도메인명 대신 '@' 표시를 사용하여도 된다.
@ IN SOA ns.nobreak.com. hostmaster.nobreak.com. (IN(Internet)은 클래스명이다. HS, HESIOD, CHAOS와 같은 클래스도 존재하지만, 일반적으로 사용되지 않으므로 항상 IN이 사용된다고 생각하자.
SOA 다음엔 Primary 네임서버와 관리자 Email 주소가 들어간다. hostmaster.nobreak.com. 이 Email 주소인데, 일반적 Email 표기법에서 '@'를 도트로 바꾸어 쓰면 된다. 본 Email은 해당 도메인의 콘택 포인트(Responsible Person)로서 도메인에 문제가 발생할 경우 이를 리포팅하는 용도로 사용된다. Namespace를 쫓으며 도메인 오류를 점검하는 lamers 와 같은 도구들은 문제가 검출되었을 때 본 Email로 통지하여 준다.
다음 괄호로 둘러싸인 부분엔 Serial, Refresh, Retry, Expire, Minimum 5개의 시간(초) 필드가 놓인다. Minimum을 제외한 4개 필드는 Secondary 네임서버를 제어하기 위한 값이다. 기본 단위는 '초'이고, 단위기호 M(Minute), H(Hour), D(Day), W(Week)를 붙여 30M, 8H, 2D, 1W와 같이 사용할 수도 있다.
Serial: Serial은 Secondary가 Zone 파일의 수정여부를 알 수 있도록 하기 위함이다. Secondary는 백업본의 Serial이 Primary의 Serial보다 작을 경우 Zone 파일을 재전송 받는다. 따라서 Zone 파일이 수정된 후 Serial이 변경되지 않는다면, Secondary는 백업카피를 업데이트하지 않음을 유의하자. Secondary가 없다면 Serial은 의미가 없지만 그렇다 할지라도 Zone 파일이 수정되었을 때 Serial을 증가하는 것은 좋은 습관이다.
Serial의 표기는 증가하는 임의 숫자보단 일반적으로 최종 수정일을 YYYYMMDDNN의 형식으로 표기한다. YYYYMMDDNN 연도 표기법은 4294년까지 표기 가능하다.
Refresh: Primary측의 Zone 데이터베이스 수정여부를 Secondary가 검사하는 주기이다. 네트워크의 변경이 잦아 Zone파일이 자주 수정된다면, 3H(10800) 정도로 설정한다. Zone이 안정되는 시점에서는 일반적으로 6H(21600) - 12H로 설정한다.
Retry: Secondary측에서, Primary와 연결이 안될 경우, 재 시도 시간 주기이다. Refresh 기간 보다 적을때 의미가 있으며, 대부분의 경우 30M(1800) - 1H로 설정한다.
Expire: Secondary가 Expire로 지정된 시간동안 Primary에 연결하지 못할 경우, 오래된 백업카피의 자료가 더 이상 유효하지 않다고 보고, 해당 도메인에 대한 답변을 하지 않는다. 이 값을 너무 낮게 책정하는 것은 좋지 않다. 보통 1W - 2W(1209600)로 설정한다.
Minimum: 타 네임서버가 본 Zone에 기술된 자료를 갖고 갔을 경우, 그 자료에 대한 유효기간(캐쉬에 살아있는 시간)을 설정한다. TTL(Time To Live)값이 명시되지 않은 레코드는 본 값을 기본으로 갖게 된다. 특정 레코드가 변경되었을 때, 이것이 인터넷에 전파되어 업데이트되는 주기는 전적으로 이 Minimum 값에 의존한다. 일반적으로 SOA에서는 1D(86400)를 설정하여 전체 레코드에 적용하고, 잦은 변경이 예상되는 레코드만 명시적으로 1H - 3H 정도로 낮추는 방법을 사용한다. 0은 캐싱을 하지 말라는 의미이다.
2.5.3.2. NS(Name Server) 레코드
NS 레코드로 해당 도메인에 대한 네임서버를 다음과 같이 나타낸다.
nobreak.com. IN NS ns.nobreak.com. IN NS ns2.nobreak.com.또 다른 NS의 활용으로는, 거대 도메인에서 서브 도메인을 다른 네임서버로 위임할 때이다. Namespace상의 가지연결은 이 NS 레코드로 이루어 지는데, 거대 도메인일 경우 해당하는 부분이므로, 여기서는 해당 도메인에 대한 위임 정보만을 나타낸다고 알아두자. 도메인 위임에서 자세히 다룬다.
2.5.3.3. A(Address) & CNAME(Canonical Name) 레코드
A 레코드는 도메인에 IP를 부여한다. 다음 설정을 보자. mail과 power에 A 레코드로 IP를 매핑 하였다. (mail과 mail.nobreak.com. 은 동일하게 해석된다.)
; Host addresses mail.nobreak.com. IN A 210.105.79.2 power IN A 210.105.79.103 ; Aliases www IN CNAME power.nobreak.com. ftp IN CNAME wwwCNAME 레코드는 도메인에 대한 또 다른 이름이 가능하도록 한다. 예에서는 power.nobreak.com, www.nobreak.com, ftp.nobreak.com은 모두 같은 IP 210.105.79.103을 갖게 된다. ftp와 같이 CNAME이 CNAME을 포인팅 하는 경우는, 여러 DNS 관련 자료에서 다르게 얘기되고 있지만, 이것은 가능하다. CNAME은 포인팅하는 오리지널 도메인의 레코드를 모두 상속받기 때문에, CNAME으로 설정된 도메인은 추가 레코드를 갖을 수 없음을 유의한다. 또한, MX, NS 등의 레코드에도 CNAME으로 설정된 도메인을 넣어서는 안된다. 반드시 주의하여야 한다. CNAME의 잘못된 사용은 BIND 로그를 유심히 관찰하지 않으면 찾기 어려우므로, 확실히 할 수 없다면 CNAME으로 설정된 레코드를 아예 다른 레코드의 인자로 놓지 않는 것이 좋다. 숙련된 도메인 메니저 중에서도 트래픽과, 퍼포먼스라는 측면에서 CNAME을 전혀 사용하지 않는 경우도 있다. (참고: CNAME의 사용에 관해)
ftp IN CNAME www ; (X) CNAME엔 추가레코드를 갖을 수 IN MX mail ; 없다. power IN MX 10 mail ; (X) MX에 CNAME으로 설정된 mail IN CNAME ns ; 레코드가 올 수 없다.2.5.3.4. MX(Mail eXchanger) 레코드
MX 레코드는 해당 호스트의 메일 라우팅 경로를 조정한다. 다음과 같이 설정되어 있을 경우, account@nobreak.com 으로 보내어 지는 편지는 실제 mail.nobreak.com. 으로 전송된다. 만약 mail.nobreak.com. 에 연결할 수 없다면, 다음 우선순위인 power.nobreak.com 으로 편지를 배송하게 된다. MX Priority_Number 와 같이 사용하며, Priority_Number의 숫자는 적을수록 우선순위가 높다. MX 알고리즘에서 자세히 다룬다.
nobreak.com. IN MX 10 mail.nobreak.com. IN MX 20 power.nobreak.com. mail.nobreak.com. IN A 210.105.79.2 power.nobreak.com. IN A 210.105.79.103다음과 같이 MX 레코드에 CNAME으로 설정된 도메인을 넣으면 안된다. 이럴 경우 몇몇 MTA(Mail Transfer Agent: sendmail)는 메일 라우팅 경로를 찾지 못하여, 메일을 주고받을 수 없다. 이는 송신인이 사용하는 MTA의 종류와 버전에 의존적이므로, 경험 많은 도메인 메니저가 아니면 문제의 원인을 진단하기도 어렵다. 반드시 주의하자.
nobreak.com. IN MX 10 mail.nobreak.com. ; (X) 잘못된 사용 mail.nobreak.com. IN CNAME power.nobreak.com. power.nobreak.com. IN A 210.105.79.1032.5.3.5. PTR(Pointer) 레코드
PTR 레코드는 IP 주소에 대해 도메인명을 매핑하여 주며, Reverse Zone 파일에서 사용된다. 다음은 IP 210.105.79.2에 대한 설정 예이다.
2.79.105.210.in-addr.arpa. IN PTR ns.nobreak.com.Forward Zone에서는 다수의 도메인이 A(혹은 CNAME) 레코드를 통해 같은 IP를 갖을 수 있지만, PTR 레코드는 중복이 허용되지 않기 때문에, 해당 IP에 대한 대표 도메인명 하나만을 설정하여야 한다.
2.5.3.6. 기타 레코드들
Zone 데이터베이스에 필요한 레코드들은 위에 나열한 것만으로도 충분하지만, 더 많은 레코드들이 존재한다. 다음에 반드시 필요하지는 않으나, 종종 사용되는 레코드를 소개한다. 더 자세한 정보가 필요하다면 RFC1035, RFC1183, RFC2163을 참고하자.
power IN A 210.105.79.103 IN HINFO "Sun Sparc Ultra 5" "Solaris 2.6" IN TXT "Nobreak's Primary Server" IN TXT "WWW, FTP is now available" IN RP hostmaster.nobreak.com. hostinfo.nobreak.com. hostinfo IN TXT "Seung-young Kim, +82-42-864-4440/1"HINFO(Host INFOrmation) 레코드는 두 개의 문자열(CPU 정보, OS 정보)을 갖으며 시스템 정보를 나타낸다. 문자열에 공백이 포함되어 있을 경우에는 반드시 큰따옴표를 사용하여야 한다.
TXT(TeXT) 레코드는 텍스트 정보를 갖으며 중첩되어 사용될 수 있다. RP(Responsible Person)는 담당자의 정보를 표시하는데, Email 주소(@를 도트로 치환한)와, 담당자 정보(TXT 레코드를 갖는 도메인을 포인팅함)를 갖는다. HINFO를 포함한 몇몇 레코드는 보안을 이유로 사용치 말아야 한다는 의견도 있다.
Figure 2-1의 네트워크 구성에 대한 Forward Zone 파일 zone-nobreak.com은 다음과 같이 작성될 수 있다.
* nobreak.com 도메인에 대한 Forward Zone 파일 /var/named/zone-nobreak.com @ 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인버스 도메인을 위한 Reverse Zone 파일 zone-79.105.210.in-addr.arpa은 다음과 같이 작성된다.
* Reverse Zone 파일 /var/named/zone-79.105.210.in-addr.arpa @ 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. ; IP-Domain mapping here 1 IN PTR router.nobreak.com. 2 IN PTR ns.nobreak.com. 3 IN PTR ns2.nobreak.com. 103 IN PTR power.nobreak.com.loopback 주소를 위한 Reverse Zone 파일 또한 다음과 같이 작성된다. IP 127.0.0.1을 localhost. 로 매핑하는 것이 전부이므로, 본 파일은 어느 네트워크에서나 비슷하게 작성될 것이다.
* loopback을 위한 Reverse Zone 파일 /var/named/zone-0.0.127.in-addr.arpa @ 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. ; IP-Domain mapping here 1 IN PTR localhost.Zone 파일에서의 도메인 표기는 반드시 FQDN 표기법을 따라야 한다. BIND는 도트로 끝나지 않는 문자열은 호스트명으로 처리하므로, ns.nobreak.com 을 ns.nobreak.com.nobreak.com. 으로 해석한다. 따라서 ns.nobreak.com. 과 같이 도트를 붙인 FQDN으로 표기하거나, ns 와 같이 호스트명만 사용하여야 한다. 도트를 빼먹는 실수는 매우 빈번히 발생하므로, 주의하자.
2.5.4.1. 호스팅 업체를 위한 Zone 데이터베이스 예제
호스팅업체의 경우 다음과 같이 다수의 도메인을 하나의 Zone 데이터베이스로 관리할 수가 있다. 만약, 호스팅 도메인별로 별도의 Zone을 유지한다면, 호스팅 서버의 IP 변화와 같이 관련된 모든 Zone이 수정되어야 하는 상황이 오지 않기를 기도하거나, 반나절을 편집기와 씨름할수 있는 끈기를 배워야할 것이다. 여기서 소개하는 팁은 사용자가 많은 호스팅 업체일수록 유용하게 활용될 수 있으며, 도메인 추가/수정/삭제에 드는 시간과 노력을 절약할 수 있을 것이다.
* named.boot (BIND-4) primary netbsd.org zone-default primary openbsd.org zone-default ... primary freebsd.org zone-freebsd.org ; 별도의 추가 도메인이 필요한 경우 ...* named.conf (BIND-8) zone "netbsd.org" IN { type master; file "zone-default"; }; zone "openbsd.org" IN { type master; file "zone-default"; }; ... zone "freebsd.org" IN { type master; file "zone-freebsd.org"; }; ...* zone-default @ IN SOA ns.nobreak.com. hostmaster.nobreak.com. ( 1999030601 ;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 A 210.105.79.39 IN MX 10 @ IN MX 20 mqueue.nobreak.com. www IN CNAME @ telnet IN CNAME @ ftp IN CNAME @ mail IN CNAME @ pop IN CNAME @ news IN CNAME news.nobreak.com.* zone-freebsd.org $INCLUDE zone-default ftp.kr IN A 147.46.102.39 www.kr IN CNAME @
(0) (0)메일에 관련된 잡담..... 제2화 (DNS 는 모냐.~~ 난 Reverse DNS가 몬지 몰라~)
Dev Server/DNS Server Admin 2006/12/22 00:01메일과 관련된 DNS 이야기...
사실 메일에 관련된 일을 하다 보면 정말 많은 분야의 잡다한 지식을 두루 알아야만 일을 진행하는데
무리가 없다. 실례로 요즘 각 포탈 및 대부분의 회사에선 업무용 메일과 광고성 메일을 구분하기 위해
스팸 차단 시스템을 메일 시스템 최전방에 설치를 하고 이용하게 된다..
그런데 이런 스팸 차단 시스템이란 것이 각 업체별로 차단 기준을 설정하여 운영하고 있기 때문에 곤란을 격는 경우가 상당히 자주 발생 한다..
그중 가장 많이 사용되는 방법중 하나가 메일발신서버의 IP Address 로 해당 메일 발송서버의 도메인을 확인하는 기능 그러니 Reverse DNS Query 를 많이 애용하곤 한다.
해당기능은 메일을 발송하는 발신자 서버의 ip address 로 리버스 dns를 확인하여 해당 메일서버가 유효한 서버인지를 확인한는 방법으로 가장 일반적인 방법이다.
그런데 이 리버스 쿼리를 모르는 사람들도 상당히 있다는 것이 문제이다.
해당시스템이 리버스 쿼리가 유효한가를 확인할 수 있는 가장 쉬운 방법중 하나는
[시작] --> [실행] --> [cmd 입력 엔터] 하여 command prompt 를 실행한 후
nslookup 확인하고자하는 ip [엔터]를 눌러서 정보를 확인하는 방법이다.
이렇게 해서 호스트명이 풀어져서 제대로 출력이 되면 정상적인 메일 서버에서 메일이 온것으로 판단하여
스팸으로 처리 하지 않는 방법이다.
이번에 우리 미주에 있는 서버가 Resvers DNS가 정상적으로 등록되지 못해서 문제가 좀 있었다..
일반적으로는 정방향/역방향 조회가 될수 있도록 등록만 하면 되는데 사용하는 IP 대역대와
해당 도메인에 대한 Resvere DNS 를 설정할수 있는 권한을 ROOT DNS에서 위임을 받았느냐에 따라서
등록되는 방법이 다르다..
Resvere DNS 를 등록하는 방법은 바로전 포스트에 등록되어 있으니 참고하여 등록하기 바라며
또한 자신의 DNS등록에 문제가 없는지 점검할수 있는 아주 정말 정말 아주~~~~
유용한 사이트 하나를 소개 한다..
라는 사이트 인데 DNS설정 및 정보를 확인할수 있는 사이트 이다.. 자신이 확인하고자 하는 정보를
일목요연하게 확인할수 있으니 DNS에 관련된 정보를 확인하고자 하시는 분들은 꼭 방문해보시길..
음.. 물론 영어다.. 왜 한글화된 사이트는 없는 걸까~~~~
이번에 DNS관련 문제가 한가지 또 있었는데. 이에 대해선 다음에 살짝 적어보기로 하자.. 이만..
(0) (0)
|
(0) (0)
|
(0) (0)전달자를 설명하기 위하여 다음을 가정합니다.
고객사의 네임서버로 설정된 NT서버의 IP를 203.255.113.33 이라 하자.
아래의 내용은 고객사의 네임서버에서 전달자를 설정하는 방법입니다.
아래의 203.255.112.4는 아이네트의 네임서버이지만, 여기서는 고객사의
또 다른 네임서버일수도 있다
[그림1]
1. 고객사의 NT 네임서버 셋팅후 서버 IP를 오른쪽 마우스로 클릭한후 등록정보를 선택한다.
[그림2]
2. [전달자]탭을 설정하면 몇가지 설정해주어야 할 부분이 있다.
[그림3]
[전달자]
전달자사용
이 부분을 체크할경우
1. 클라이언트 A에서 자신이 지정한 네임서버에게 name resolution을 요구한다.
2. 네임서버는 자신의 캐시영역과 존영역에서 name resolution을 할수있는지 확인하고
분석이 된다면 클라이언트 A에 전달한다.
3. 안된다면, 전달자로 설정된 네임서버에게 name resolution을 해달라고 요청한다.
이때, 전달자에게 연결이 안될 경우 (네트웍 다운, 전달자 네임서버다운, 전달 패킷 손실)
에는 바로 클라이언트에서 지정한 네임서버가 계층적 DNS 분석을 하게됩니다.
4. 전달자로 지정된 네임서버는 자신의 캐시영역에 있을경우 name resolution을 해서 그 내용을
클라이언트에서 지정한 네임서버에게 돌려준다.
5. 캐시영역에 없을 경우에는 마치 자신에게 문의가 들어온것 처럼 DNS의 계층구조를
분석하여 name resolution을 해준후 그내용을 클라이언트에서 지정한 네임서버에게 돌려준다.
6. 만약, name resolution이 실패할경우 클라이언트에서 지정한 네임서버에게 실패했다는 메세지
(Not Found)를 보낸다.
7. 클라이언트에서 지정한 네임서버는 더이상 name resolution을 하지 않는다.
슬레이브 서버로 운영
이 부분을 체크하면, 위의 3번처럼 여러 이유때문에 전달자에게 연결이 안될경우,
자신이 계층적 DNS 분석을 하지 않게 됩니다.
즉, 전달자에게 name query를 전달해주는 역할만 하게되고, 연결이 안될경우에는
name resolution을 못하게 됩니다.
그러므로, 체크를 하지 마시기 바랍니다.
예를 들어 설명하기로 하겠습니다.
위의 그림에서 사용자가 클라이언트 A를 사용하고 있다고 가정하자.
클라이언트 A는 203.255.113.33 네임서버를 사용하고 있다.
(제어판 -> 네트워크 -> TCP/IP -> DNS 구성 -> 찾을DNS서버주소 에
203.255.113.33이 적혀있다.)
A에서 웹브라우저를 띄우고, http://www.cs.nuri.net/이라고 쳤을 경우
1. 클라이언트 A는 네임서버로 지정된 203.255.113.33에게 위 도메인의 IP를 물어봅니다.
2. 203.255.113.33은 www.cs.nuri.net에 대한 IP를 자신의 캐시영역및 존영역에서 찾아보고
IP를 찾을경우 : IP값을 클라이언트 A에 전달해준다.
못찾을 경우 : 전달자로 설정된 203.255.112.4 로 IP값을 찾아달라고 보낸다.
(전달자가 설정이 안되어있다면 여기서 203.255.113.33이 바로
계층적 DNS구조상에서 IP를 찾기위해 네임서버로 작동한다.)
전달자로 요구를 하더라도 전달자인 203.255.112.4 가 아무런 대답을
안할 경우 (203.255.112.4 다운, 네트웍 다운, 전달 패킷 손실 등 )는
203.255.113.33이 직접 계층적 DNS 분석을 하게됩니다.
3. 203.255.112.4 번도 자신의 캐시영역및 존영역에서 www.cs.nuri.net에 대한 IP를 찾아보고
IP를 찾을경우 : 자신의 캐시영역에 남겨두면서 203.255.113.33 에게 전달해주고,
203.255.113.33의 캐시영역에 남게되면서 클라이언트 A에 전달이 된다.
못찾을 경우 : 203.255.112.4 번이 IP를 찾기위해 계층적 DNS 구조를 분석한다.
이렇게 계층적 DNS구조를 분석하여
IP를 찾을경우 : 자신의 캐시영역에 남겨 두면서 203.255.113.33 에게 전달해주고,
203.255.113.33의 캐시영역에 남게되면서 클라이언트 A에 전달이 된다.
못찾을 경우 : 203.255.113.33 에게 찾지못했다는 메세지(Not found)를 전달한다.
203.255.113.33은 더 이상의 계층적 DNS 분석을 하지 않는다.
그렇다면 왜 전달자를 사용하는가 ?
DNS 네임서버의 목적은 도메인명을 IP address로 바꾸어 주는데 있다.
캐시영역이 큰 네임서버를 전달자로 지정을 해놓을경우, 많은 도메인에 대한 IP가
이미 캐시영역에 올라와 있으므로 IP address로 빨리 바꿀수 있다.
이 경우 고객사의 클라이언트에서는 빠르게 IP를 얻을수 있고(결국 빠르게 외부홈페이지 및
이트에 연결), 불필요한 외부 트래픽을 줄일수 있게 된다.
아이네트의 네임서버중 하나를 전달자로 이용할수 있습니까?
현재 네임서버로 사용하고 있는 서버들중 203.255.112.4 를 전달자로 지정하여 사용하시면
빠른 name resolution을 하실수 있습니다
(0) (0) 8.1. NSLOOKUP 네임서버를 운영하고 관리하는데 있어 문제를 발견하고 해결하기 위해 Resolver의 입장으로 네임서버를 시험해볼 필요가 있다. 대부분의 시스템에 기본 설치되어 있는 nslookup은 dig와 함께 가장 널리 사용되는 네임서버 질의 도구로써, 도메인 메니저의 기본 무기중 하나이다. $ nslookup Default Server: ns.nobreak.com Address: 210.105.79.2 > exit nslookup은 실행후 대화형 프롬프트 '>'를 표시하고 /etc/resolv.conf에 정의된 첫 번째 네임서버를 기본 질의 서버로 설정한다. nslookup은 BIND와 달리 하나의 서버만을 질의에 사용하기 때문에 'Default NS -> Timeout -> Error'와 같이 동작한다.
|
(0) (0)>현재 ISP 업체로 부터 30개정도 아이피를 임대받아 거래처 호스팅을 하고 있습니다.
>최근 호스팅중인 업체들의 아이피가 블랙아이피로 등록되어 메일을 차단당하는 사태가 발생하여 확인해 본 결과
>Reverse DNS설정이 되어있지 않아 발생되어진 문제인것 같습니다.
>
>http://www.dnsstuff.com/tools/ptr.ch?ip=xx.xx.xx.xx 를 이용하여 검색한 결과..
>
>(zone: xx.xx.in-addr.arpa.) B클래스 Reverse DNS까지는 결과를 보여주나
>C클래스의 Reverse DNS부터 정보가 출력되지 않는것을 보니 저희에게 아이피를 임대해준 업체가 아마도 Reverse DNS를 등록하지
>않았나 하는 생각이 듭니다.
오랜만에 올라온 질문이네요 ^^
요즘 이런질문을 한번에 해결해주는 사이트를 만드는 중인데 그때는 저대신 사이트가 쉽게 답해줄수있을거 같습니다.^^
><질문1>
>현재 저희 업체도 자체 DNS를 운영중인데 거기에 Reverse DNS를 등록한 것으로는 안되는 건가요??
>저희 DNS에 설정한 xx.xx.xx.in-addr.arpa. 리버스 파일의 설정확인을 해봤는데 오류가 없습니다.
=> 답변1. 자체DNS서버에서만 Reverse 등록한것만으로는 되지 않습니다.
리벌스역시 DNS와 동일하게 동작합니다.
도메인이 등록되지 않고 자체 네임서버에서만 있으면 다른곳에서 찾아오지 못하죠?
그것과 같이 리벌스 역시 상위부터 제대로 등록이 되어 있어야 하고 위임이 되어 있어야 합니다.
><질문2>
>위의 문제를 어떻게 해야해야 될까요? 제가 생각하는 것처럼 저희 아이피를 임대해준 회사에 전화해서 Reverse DNS 등록을
>요청하는게 맞는건가요??
답변 =>
임대해준 회사에 전화해서 리벌스 등록을 요청하는게 맞습니다.
리벌스 등록을 요청하는것과 귀사의 네임서버로 위임을 받는 두가지 방법이 있습니다.
위임은 NIC에서 ISP까지 위임되어 있는데 국내의 경우 C-Class단위로 위임을 해주기 때문에
ip를 32개 할당받은것이면 ISP에 리벌스 등록을 요청하는것이 맞습니다.
코넷의 경우 ISP(예:코넷)까지만 위임을 받은상태이면, http://dns.kornet.net 사이트 접속해서, 고객문의클릭하여,
리벌스 설정요청으로 글을 올려주시면 됩니다.
위임의 경우 C-Class단위인경우 코넷에 요청하여, NIDA에서 직접 귀사의 네임서버로 위임을 받아 운영할수 있습니다
><질문3>
>한국통신 DNS설정후 도메인 질의를 하면 Non-authoritative answer라고 뜨고 결과를 출력해 주는데 무슨뜻이고, 어떤 경우에 뜨는건가요??
답변 =>
Non-authoritative answer 는 해당 네임서버에서 Zone설정이되어 운영중이지 않는 도메인의 경우,
한국통신 DNS서버가 해당 네임서버에서 정보를 가져오는 경우 나오는 응답입니다.
KT 168.126.63.1에는 도메인설정이 없는 Cache서버니까, 네이버나 다른 사이트 어떤것을 질의하더라도 해당 네임서버가서 응답을 가져오므로 Non-authoritative answer로 응답합니다.
authoritative answer는 PC에서 지정한 DNS서버에 해당 도메인이 설정되어 있어 바로 응답을 줄때 나오는 응답입니다.
차이점을 아시겠죠 ^^
<추가질문>DNS서버에 zone파일 세팅할적에 호스팅중인 업체가 많은데요~ 일일이 IN NS ns.aaa.com 하고 ns IN A 111.111.111.111 요거 설정해야하나요 ?
추가 답변=> 설정해야합니다. Zone File은 형식에 맞게 작성되어야 합니다.
다른 업체의 Zone File을 복사해 쓰세요 ^^
최근에는 규격이 더욱엄격해져서 whois정보와 Zone의 ns정보가 틀리면 질의를 하지 않는경우도 있습니다.
설정오류는 ns설정오류가 아주 많습니다.
---------------------------------------------------------------------------------------------------
부가 설명. 메일서버를 운영하신다면 제대로된 리벌스 설정과 SPF설정은 반드시 해야합니다.
아래 설정처럼 Zone File 맨아래에 반드시 SPF설정하여 운영하시기 바랍니다.
naver.com. IN TXT "v=spf1 ip4:220.95.234.208 ip4:61.74.70.0/23 ip4:222.122.16.0/24 ip4:220.73.156.0/24 ip4:211.218.150.0/24 ip4:211.218.151.0/24 ip4:211.218.152.0/24 ip4:218.145.30.0/24 ~all"
daum.net. IN TXT "v=spf1 ip4:211.43.197.0/24 ptr ~all"
> dig naver.com txt
; <<>> DiG 8.3 <<>> naver.com txt
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;; naver.com, type = TXT, class = IN
;; ANSWER SECTION:
naver.com. 56m41s IN TXT "v=spf1 ip4:220.95.234.208 ip4:61.74.70.0/23 ip4:222.122.16.0/24 ip4:220.73.156.0/24 ip4:211.218.150.0/24 ip4:211.218.151.0/24 ip4:211.218.152.0/24 ip4:218.145.30.0/24 ~all"
> dig daum.net txt
; <<>> DiG 8.3 <<>> daum.net txt
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
;; QUERY SECTION:
;; daum.net, type = TXT, class = IN
;; ANSWER SECTION:
daum.net. 6h27m6s IN TXT "v=spf1 ip4:211.43.197.0/24 ptr ~all"
다행히 제가 아는 질문만 올려주셔서 감사합니다. ^^ 제가 요즘 쪼금 바빠서 이거저거 테스트할시간은 없었거든요 ^^
DNS전문가 사이트 운영자 topasvga 올림 ^^
(0) (0)
댓글을 달아 주세요