반응형

 

1. 도메인 조회 구조에 대한 이해

● 구조

 

인터넷상에서 사용되는 도메인은 전 세계적으로 고유하게 존재하는 이름정해진 규칙 및 체계에 따라야 하며, 임의로 변경되거나 생성될 수 없다.

 

인터넷상의 모든 도메인은 ".(dot)" 또는 루트(root)라 불리는 도메인 아래에 그림과 같이 나무를 거꾸로 위치시킨 역트리(Inverted tree)구조로 계층적으로 구성되어 있다.

 

루트 도메인 바로 아래의 단계를 1단계 도메인 또는 최상위도메인(TLD, Top Level Doamin)이라고 부르며, 그 다음 단계를 2단계 도메인(SLD, Second Level Domailn)이라고 한다.

 

 

 질의 과정

 

① 웹 브라우저에 www.naver.com을 입력하면 먼저 Local DNS에게 "www.naver.com"이라는 hostname에 대한 IP 주소를 질의하여 Local DNS에 없으면 다른 DNS name 서버 정보를 받음(Root DNS 정보 전달 받음)

 

 Root DNS 서버에 "www.naver.com" 질의

 

 Root DNS 서버로 부터 "com 도메인"을 관리하는 TLD (Top-Level Domain) 이름 서버 정보 전달 받음

 

 TLD "www.naver.com" 질의

 

 TLD에서 "name.com" 관리하는 DNS 정보 전달

 

 "naver.com" 도메인을 관리하는 DNS 서버에 "www.naver.com" 호스트네임에 대한 IP 주소 질의

 

 Local DNS 서버에게 www.naver.com에 대한 IP 주소를 222.122.195.6 응답

 

 Local DNS www.naver.com에 대한 IP 주소를 캐싱을 하고 IP 주소 정보 전달

 

Recursive Query : Local DNS 서버가 여러 DNS 서버를 차례대로 (Root DNS 서버 -> com DNS 서버 -> naver.com DNS 서버) 질의해서 답을 찾아가는 과정

 

 

2. named.conf 옵션에 대한 이해

 

변경 전 : listen-on port 53 {127.0.0.1;};

변경 후 : listen-on port 53 {any;};

기본설정은 127.0.0.1(localhost)에게만 listen하기 때문에 외부 접속은 불가능

따라서 서버에 설정된 모든 IP에 대해 listen 하기 위해 any로 변경

 

변경 전 : allow-query {localhost;};

변경 후 : allow-query {any;};

네임서버에 설정된 도메인만 응답하도록 설정

변경 전에는 localhost만 응답, 변경 후에는 네임서버에 설정된 도메인 전체 응답

 

변경 전 : recursion no

변경 후 : recursion yes

변경 후에 여러개의 네임서버가 존재 할 경우 순차적으로 질의 후 다시 1차 네임서버로 질의 할 것인지 선택

master 서버는 필요, slave 서버는 필요 X

 

변경 전 allow-transfer {none;}; => 모두 deny

변경 후

allow-transfer {any;}; => 모두 허용

allow-transfer {127.0.0.1; 121.254.171.242;}; => 특정 IP만 허용

allow-transfer {key rndckey;}; => rndc key 사용

 

dnssec-enable yes/no

기존의 DNS에 공개키 암호화 방식의 보안기능을 추가 부여하여 DNS의 보안성을 대폭 강화 여부 설정

 

forward first; (or only;)

네임서버로 오는 질의를 특정 호스트로 포워딩

First 는 네임서버로 들어오는 질의를 forwarders로 지정한 외부 서버에서 먼저 처리하고 적절한 해답을 찾지 못할 경우 로컬에서 처리

Only 는 네임서버로 들어오는 질의를 forwarders 로 지정한 외부에서만 해결

 

Forwarders {IP Address;}

forward를 처리할 외부 서버의 IP 주소를 정의

 

3. zone 파일 분석

 

1행

$TTL 60 (60 : 1)

: 이곳에 설정한 도메인에 대한 정보를 다른 네임서버에서 읽어간 다음 읽어간 네임서버측에 얼마동안 보관하고 있을 것인가를 설정하는 항목

 

2

@ : ORIGIN을 의미하는 특수문자로 public domain 을 의미

IN : 다음으로 나오는 우측 설정을 사용한다는 의미

SOA : ns1.oooooo.com 도메인 네임서버에 대한 모든 정보를 가지고 있으며 관리자는 root.oooooo 이라는 메일로 설정함을 의미

 

 주의할 점 : 도메인 이름을 적은 다음에는 항상 .() 루트 도메인을 표시

ns1.oooooo.com => ns1.oooooo.com.oooooo.com

ns1.oooooo.com. => ns1.oooooo.com

 

3

serial : 시리얼값 변경 내용으로 slave 서버가 master 서버의 zone 파일을 업데이트 할 지 결정

serial 값이 기존의 값보다 증가 하였을 경우 slave 서버 에서 master 서버의 zone 파일을 다시 전송 받음 (YYYYMMDDnn 으로 기본 설정)

 

4

refresh : 보조 네임서버가 주 네임서버에 접속하는 시간 (1D : 하루)

 

5

retry : refresh에 지정된 주기로 체크하다가 장애 등으로 인해 접속 실패시 다시 시도할 시도 간격 (1W : 1시간)

목적 상 refresh 값 보다 적어야 함

 

6

expire : 주네임서버에서 데이터가 없으면 파기하는 기간(1W : 1)

 

7

minimum : 도메인 정보를 다른 네임서버에서 가져갔을 때에 가져간 도메인정보를 얼마나 보관하고 있을 것인가에 대한 시간 값(3H : 3시간)

TTL값이 명시되지 않은 레코드는 Minimum 값을 기본으로 갖게 됨

9

IN : internet 클래스를 나타냄

NS : 도메인의 네임서버 정보를 나타냄

ns1.oooooo.com. : 네임서버 도메인을 ns1.oooooo.com으로 지정

 

11

IN : internet 클래스를 나타냄

MX 10 : 우선순위가 빠른 10번의 mail..com. 에서 메일을 수신oooooo

mail.oooooo.com. : mail.oooooo.com 도메인으로 메일을 메일서버로 지정

 

12

IN : internet 클래스를 나타냄

TXT :소유한 도메인에 간단한 텍스트 데이타를 입력하는 기능

v=spf1 : 사용하고 있는 SPF의 버전

IP4 : 허용하고있는 모든 서버 IP주소

-all : 위 목록 이외의 다른 곳에서 보낸 메일을 받아들이지 않음

 

15

ns1 : nameserver 1을 의미

IN : internet 클래스

A : 해당 호스트가 어떤 아이피를 가르키는지를 설정 (A다음엔 IP가 와야함)

 

※ 9~ 19행 처럼 첫번째 항목에 @나 아무것도 입력하지 않으면 네임서버 환경설정 파일에서 설정한 도메인(oooooo.com)으로 인지함

 

 

4. zone 파일 추가 하여 조회 해보기 (TXT 레코드와 SPF 정책 개념)

 

(1) TXT 레코드 값 설정 / 개념

TXT 레코드 란 ?

: 도메인 외부의 소스에 텍스트 정보가 포함된 DNS 레코드 유형

 

TXT 레코드를 사용하여 피싱, 스팸, 기타 악의적인 활동을 방지할 수 있다.

 

TXT 레코드는 도메인 이름을 임의의 텍스트 문자열에 매핑하는 데 사용된다. 특히 SPF(Sender Policy Framework) 및 DKIM(DomainKeys Identified Mail)과 같은 이메일 구성과 관련된 여러 애플리케이션에서 사용된다.

 

DNS 표준은 여러 문자열을 포함하는 하나의 TXT 레코드를 허용하며 각각의 문자열 길이는 최대 254자까지 가능하다. 여러 문자열이 사용되는 경우 이러한 문자열은 클라이언트에 의해 연결되고 단일 문자열로 처리된다.

 

Azure DNS REST API를 호출할 때 각 TXT 문자열을 별도로 지정해야 한다. Azure Portal, PowerShell 또는 CLI 인터페이스를 사용할 때는 레코드당 하나의 문자열을 지정해야 하며 필요한 경우 자동으로 254자 세그먼트로 나뉜다.

 

TXT 레코드 집합은 여러 레코드를 포함할 수 있으며 각각의 레코드는 여러 문자열을 포함할 수 있다. Azure DNS는 모든 레코드가 결합된 각 TXT 레코드 집합에서 총 문자열 길이를 최대 1024자까지 지원한다.

 

dig 명령어로 gmail.com 에대한 TXT 레코드 조회

 

dig 명령어로 redirect 되어있는 _spf.google.com TXT 레코드 조회

 

 

dig 명령어로 include 되어있는 _netblocks.google.com 의 TXT 레코드 의 spf 정책 도메인 확인

 

 

(2) SPF 정책

SPF(스팸 처리 방지) 레코드SPF(스팸 처리 방지) 레코드란?

 

스팸 발송자는 도메인에서 전송된 것처럼 보이는 이메일을 보낼 수 있으며, 이를 위장이라고 한다. 내 도메인 호스트에 SPF(Sender Policy Framework) 레코드를 추가하면 수신자가 이메일이 내 도메인에서 전송되었으며 위장된 메일이 아니라는 것을 알 수 있다. 일반적으로 메일 발송 관련하여 ‘발송자의 메일 서버 정보와‘메일 서버 정보’가 일치하는지 확인할 때 이용된다.

메일 발송 서버가 존재하는 경우에는 SPF와 TXT에 입력되어 있어야 한다.

 

SPF(스팸 처리 방지) 레코드 주의사항

SPF를 인식하지 못하는 버전의 메일 수신 서버에서는 TXT에 동일한 정보를 입력하지 않으면 스팸 메일로 처리해서 반송될 수 있다.

SPF와 TXT 두 개 레코드로 관리할 경우 동일한 정보로 관리해야 한다.

 

 

(3) TXT 레코드, SPF 정책 추가(zone 파일 추가)

 

12번 행

v=spf1 : 사용하고 있는 SPF의 버전

ip4 : ipv4 규약의 ip 주소와 비교

특정 ip 지정(121.254.171.244) : 메일서버에서 메일이 나가지만 웹서버에서도 회원 가입, 패스워드 문의, 각종 정보 전송등 메일이 발송되기 때문에 자기 도메인에서 외부로 발송되는 모든 IP에 대한 SPF등록이 이루어져야 함

 

all은 레코드 값의 가장 뒤에 지정, 앞의 설정 이 외의 나머지를 의미

-all (fail) 앞의 조건과 맞지 않으면 거부

~all (softfail) 앞의 조건과 맞지 않으면 특정 헤더를 남기고 통과

+all (pass) 무조건 통과, 기본값(+)

?all (neutral) 신경쓰지 않음

 

 

반응형

+ Recent posts