DNS 레코드를 간단히 알아보아요

구글에는 Google 관리 콘솔 도구 상자 라는 서비스가 있습니다.

이 서비스에서 dig 메뉴로 들어가면 입력한 도메인의 DNS레코드를 확인할 수 있습니다.

DNS레코드가 무엇인지 차례대로 알아볼까요?

DNS란?

DNS(Domain Name System)은 지도 애플리케이션으로 비유할 수 있습니다.

화정역과 가장 가까운 와플대학🧇👩‍🎓에 가기 위해 네이버 지도에서 ‘화정역 와플캠퍼스’를 검색한다고 가정해봅시다.

(본 포스팅은 와플대학과 아무런 관련이 없습니다.😌)

즉시 위치 정보가 나오는 것을 확인할 수 있습니다.

여기서 주목할 점은, 

저는 ‘와플대학 화정캠퍼스’라고 검색했는데 ‘경기 고양시 덕양구 화정동 965 1층 105-3호’라고 정확히 주소가 나왔다는 점입니다.

그러니까 ‘와플대학 화정캠퍼스’의 진짜 주소는 ‘경기 고양시 덕양구 화정동 965 1층 105-3호’인 것이죠.

하지만 생각해봅시다.

과연 사용자가 화정역에 있는 와플대학을 찾아갈 때마다 ‘경기 고양시 덕양구 화정동 965 1층 105-3호’을 기억할 수 있을까요?

솔직히 사용자는 ‘와플대학 화정캠퍼스’를 더 기억하기 쉬워할 겁니다.

• 기억하기 쉬운 이름 : 와플대학 화정캠퍼스
• 실제 주소 : 경기 고양시 덕양구 화정동 965 1층 105-3호

그리고 네이버지도는 ‘와플대학 화정캠퍼스’를 검색했을 때, 멋지고 간편하게 ‘경기 고양시 덕양구 화정동 965 1층 105-3호’을 결과로 보여주었습니다.

이처럼, 사용자가 기억하기 쉬운 ‘와플대학 화정캠퍼스’를 정확한 주소인 ‘경기 고양시 덕양구 화정동 965 1층 105-3호’로 찾아주는 네이버 지도의 역할을

DNS도 동일하게 수행합니다.

lifeoncloud.kr 블로그의 정확한 IP주소는 183.111.199.159 입니다.

하지만 방문자는 물론, 블로그 주인인 저조차도 183.111.199.159 을 기억하기 쉽지 않습니다.

하지만 DNS 덕분에 주소창에 183어쩌고저쩌고가 아닌 도메인네임을 넣어 접속할 수 있습니다.

오늘은 이런 DNS의 레코드 타입을 알아보도록 하겠습니다.

DNS 레코드 설명

A

A레코드는 특정 도메인에 매핑하는 IP주소(IPv4)를 알려줍니다.

간단히 말해, A record는 “ ‘lifeoncloud.kr’의 IP 주소가 ‘183.111.199.159’이다.”라고 말하는 역할을 합니다.

A레코드

기본적이고, 분명한 방법입니다. 

최종적으로 가야할 183.111.199.159 주소를 바로 가리키니까요.

Google 관리 콘솔 도구 상자에서 보면 아래와 같은 형식으로 레코드가 나오는 것을확인할 수 있습니다.

터미널에서는 nslookup 라는 네트워크 명령어를 통하여 도메인의 IP주소를 알 수 있습니다.

잠깐! nslookup은 무엇일까요?

name server lookup. 

nslookup은 여러 운영체제에서 사용할 수 있는 네트워크 관리 명령줄 도구입니다.

nslookup을 사용하면 도메인네임, IP주소, 기타 DNS레코드를 알 수 있습니다.

방법

nslookup {도메인}

예시

→ nslookup lifeoncloud.kr

Server: 1.214.68.2
Address: 1.214.68.2#53

Non-authoritative answer:
Name: lifeoncloud.kr
Address: 183.111.199.159

위의 Server, Address 는 제 컴퓨터에 연결된 DNS 서버의 주소를 말합니다.

아래의 Name, Address 는 도메인 lifeoncloud.kr 의 IP주소를 보여주고 있습니다.

nslookup -type=a {도메인} 명령어로 도메인의 A레코드를 바로 확인할 수 있습니다.

방법

nslookup -type=a {도메인}

예시

→ nslookup -type=a lifeoncloud.kr

Server: 1.214.68.2
Address: 1.214.68.2#53


Non-authoritative answer:
Name: lifeoncloud.kr
Address: 183.111.199.159

A레코드는 반드시 일대일 매칭이 될 필요는 없습니다.

일대다, 다대일도 가능합니다.

예를 들면, 도메인 하나에 IP주소 여러개를 할당할 수 있습니다.

반대로, 도메인 여러개에 IP 주소를 하나 할당할 수도 있습니다.

이 경우엔 HTTP헤더의 HOST필드에 도메인을 명시하여 웹서버를 구분하여 서비스 할 수 있습니다.

NS

Name Server 레코드.

네임서버 레코드는 

“ ‘lifeoncloud.kr’ 도메인을 관리하는 네임서버는 ‘ns2.cafe24.co.kr.’ 입니다.”

라고 말하는 역할을 합니다.

잠깐! 네임서버는 무엇일까요? 

네임서버는 도메인 이름과 IP주소를 서로 상호전환 시켜주는 서버를 말합니다.

대부분 도메인네임 하나당 2개 이상의 네임서버를 가지고 있습니다.

이번엔 네임서버를 물어봅시다.

방식

nslookup -type=ns {도메인}

예시

→ nslookup -type=ns lifeoncloud.kr

Server: 1.214.68.2
Address: 1.214.68.2#53


Non-authoritative answer:
lifeoncloud.kr nameserver = ns1.cafe24.com.
lifeoncloud.kr nameserver = ns2.cafe24.com.
lifeoncloud.kr nameserver = ns2.cafe24.co.kr.
lifeoncloud.kr nameserver = ns1.cafe24.co.kr.

Authoritative answers can be found from:

가용성을 위하여 네임서버를 4대 돌리고 있는 것을 볼 수 있습니다.

이번엔 lifeoncloud.kr 의 IP를 해당 네임서버에 직접 물어볼까요?

방식

nslookup {도메인} {네임서버 주소}

예시

→ nslookup lifeoncloud.kr ns1.cafe24.com.

Server: ns1.cafe24.com.
Address: 112.175.246.231#53

Name: lifeoncloud.kr
Address: 183.111.199.159

Non-authoritative answer 없이, 바로 A레코드가 나오는 것을 확인할 수 있습니다.

잠깐! Non-authoritative answer 는 무엇일까요? 

왜 A레코드를 질의했을 땐 나오고 네임서버를 질의하면 안 나오는거죠?🤨

Non-authoritative answer란, 현재 도메인이 실제로 사용하고 있는 DNS서버가 아닌, 다른 DNS서버에서 저장한 캐시를 보여주었다는 뜻입니다.

실제로 사용하고 있는 네임서버를 딱 지정해서 보여주니 Non-authoritative(신뢰할 수 없는) 답변이 없는 것이죠.

만약 호스팅케이알, 호스트센터 등 도메인 구입업체에서 구입한 도메인을 클라우드의 DNS서비스에서 관리하고 싶다면 도메인의 NS레코드를 클라우드의 DNS서비스가 제공하는 NS레코드(네임서버 정보)로 업데이트해야 합니다.

예를 들어, 가비아에서 구입한 도메인을 GCP의 Cloud DNS에서 관리하고 싶으시다면, 다음 절차를 따르시면 됩니다.

1단계: GCP Cloud DNS에서 관리하려는 도메인에 대해 DNS 영역을 생성합니다.

2단계: 가비아에서, 도메인의 네임서버 정보를 GCP의 Cloud DNS 네임서버 정보로 업데이트합니다.

참고: https://cloud.google.com/dns/docs/zones/zones-overview?hl=ko

AAAA

AAAA 레코드는, A레코드와 똑같은 역할을 수행합니다.

차이점은 IPv4 주소 체계에서 쓰이는 A레코드와 달리, AAAA레코드는 IPv6 주소 체계에서 쓰인다는 점입니다.

CNAME

CNAME 레코드는 

“ ‘test.lifeoncloud.kr’는  ‘lifeoncloud.kr’를 바라보고 있습니다.”라고 말하는 역할을 합니다. 

만약 도메인 구조가 아래와 같이 서브도메인 구조로 되어있다고 생각해봅시다.

• lifeoncloud.kr
  • test.lifeoncloud.kr
  • mail.lifeoncloud.kr

그리고 DNS 레코드가 아래와 같이 설정되어 있다고 생각해봅시다.

A 레코드에 의하여, lifeoncloud.kr 은 183.111.199.159 을 가리키게 됩니다.

lifeoncloud.kr ⇒ 183.111.199.159

CNAME 레코드에 의하여, test.lifeoncloud.kr 은 lifeoncloud.kr 을 가리키게 됩니다.

그리고 다시 A레코드에 의하여, lifeoncloud.kr 은 183.111.199.159 을 가리키게 됩니다. 

test.lifeoncloud.kr ⇒ lifeoncloud.kr ⇒ 183.111.199.159

mail.lifeoncloud.kr도 마찬가지 입니다.

mail.lifeoncloud.kr ⇒ lifeoncloud.kr ⇒ 183.111.199.159

CNAME 레코드 용도

lifeoncloud.kr 의 IP주소인 183.111.199.159 가 서버 이전 등으로 변경되었다고 생각해봅시다.

만약 test, mail 도  각각 A 레코드를 지정해두었다면, 세개 모두 A레코드를 변경해주었어야 했을 겁니다.

하지만, CNAME을 이용하여 test, mail 를 lifeoncloud.kr 을 가리키게 설정해두었다면,

실제로는 lifeoncloud.kr 의 A레코드만 변경하면 됩니다.

이처럼 CNAME은 IP주소가 자주 바뀌는 상황에서 유용하게 사용할 수 있습니다.

MX

Mail Exchanger 레코드. 

해당 도메인을 메일 주소로 갖는 메일 서버를 MX레코드를 통해서 선언할 수 있습니다.

MX레코드가 해당 도메인에 설정되어 있어야, 해당 도메인을 이메일 주소로 사용할 수 있습니다.

MX레코드는 일반적으로 도메인을 구입한 회사 홈페이지(예: 호스팅케이알, Cafe24, 가비아 등)에서 설정할 수 있습니다.

아래 명령어로 도메인의 MX레코드를 확인할 수 있습니다.

방식

nslookup -type=mx {도메인}

예시

→ nslookup -type=mx lifeoncloud.kr

Server: 1.214.68.2
Address: 1.214.68.2#53

Non-authoritative answer:
lifeoncloud.kr mail exchanger = 10 ALT3.ASPMX.L.GOOGLE.COM.
lifeoncloud.kr mail exchanger = 5 ALT2.ASPMX.L.GOOGLE.COM.
lifeoncloud.kr mail exchanger = 5 ALT1.ASPMX.L.GOOGLE.COM.
lifeoncloud.kr mail exchanger = 10 ALT4.ASPMX.L.GOOGLE.COM.
lifeoncloud.kr mail exchanger = 1 ASPMX.L.GOOGLE.COM.

Authoritative answers can be found from:

SOA

Start of Authority 의 약어.

SOA레코드는 네임서버가 해당 도메인에 관하여 인증된 데이터를 가지고 있음을 의미합니다.

SOA레코드가 없는 도메인은 네임서버에서 정상적으로 동작하지 않습니다.

SOA레코드는 도메인당 1개입니다.

아래 명령어로 도메인의 SOA레코드를 확인할 수 있습니다.

방식

nslookup -type=soa {도메인}

예시

→ nslookup -type=soa lifeoncloud.kr

Server: 1.214.68.2
Address: 1.214.68.2#53

Non-authoritative answer:
lifeoncloud.kr
origin = lifeoncloud.kr
mail addr = postmaster.lifeoncloud.kr
serial = 20190914
refresh = 10800
retry = 3600
expire = 3600000
minimum = 43200

Authoritative answers can be found from:

SOA레코드 설명

• origin : 도메인에 대한 기본 호스트네임
• mail addr : 관리자의 이메일 주소. 일반적인 이메일 형식인 @가 아니라 마침표가 들어있음.
• serial : 도메인의 갱신 버전 번호. 일반적으로 날짜(YYYYMMDD)형식.
• refresh : 도메인 영역의 데이터 갱신 여부를 체크하는 주기(초 단위)
• retry : (장애 등의 이유로)refresh 주기로 체크하지 못했을 경우, 체크를 재시도하는 주기(초 단위)
• expire : retry의 주기로 체크를 수차례 반복하다가, 도메인을 더이상 신뢰할 수 있는 영역이라고 간주하지 않아 서비스를 중단하는 최대 기한. 
• minimum : 도메인을 찾을 수 없는 경우, 네임 서버가 도메인의 부재정보를 캐싱하는 시간

PTR

Pointer 레코드.

A레코드의 반대 방향인 레코드입니다.

A레코드가 도메인네임에 대한 질의를 IP로 응답한다면, PTR레코드는 IP에 대한 질의를 도메인네임으로 응답합니다.

A레코드와 달리, PTR레코드는 1개의 IP에 1개의 도메인네임만 가질 수 있습니다.

PTR 레코드

TXT

TeXT 레코드의 줄임말.

TXT레코드는 DKIM, DMARC, SPF레코드를 설정하거나 사이트 확인용으로 쓰이는둥, 여러 목적으로 쓰일 수 있습니다.

형식

example.com.   IN   TXT   "This domain name is reserved for use in documentation"

예시

lifeoncloud.kr. 1799 IN TXT "v=spf1 include:_spf.google.com ~all"

SPF레코드란?

SPF(Sender Policy Framework)는 도메인의 이메일을 보내도록 승인된 메일 서버를 명시하는 이메일 인증 방법입니다. 

SPF 레코드를 사전에 설정하여 메일 서버 정보를 공개하면, 스푸핑을 방지할 수 있고, 수신자 측에서 스팸메일로 분류되는 것을 방지할 수 있습니다.

추가로 SPF에 대해 알아두어야할 점은 SPF레코드는 지원 중단(deprecated)되었다는 것입니다. 이제 SPF레코드는 TXT레코드에서 설정해야합니다.

The SPF record set type is deprecated. Use TXT records starting with v=spf1 instead. SPF type records are not used by modern email software. (SPF 레코드 모음 유형은 지원 중단되었습니다. ‘v=spf1’로 시작하는 TXT 레코드를 사용하세요. 최신 이메일 소프트웨어에서는 SPF 유형의 레코드를 사용하지 않습니다.)

출처 : GCP문서 > Cloud DNS > 레코드 관리

SPF records must now only be published as a DNS TXT Resource Record. (이제 SPF 레코드는 TXT 리소스 레코드로만 게시되어야 합니다.)

출처 : SPF – SPF Record Deprecated

SPF레코드와 TXT레코드의 차이점은 목적에 있습니다.

TXT레코드의 목적과 용도가 여러개인 반면, SPF레코드의 목적은 승인된 메일 서버를 명시하는 것에 있습니다.

스푸핑이란?

스푸핑(spoofing)은 발신자의 도메인을 위조하여 발신자의 도메인에서 전송된 것처럼 보이는 위조 메일을 보내는 것을 말합니다. 스푸핑은 유해 소프트웨어를 전송하거나, 사용자를 속여서 민감한 정보를 제공하도록 하는 등의 악의적인 목적으로 사용됩니다.

예를 들면 제가 받은 스푸핑 메일으로는 아래와 같은 내용이 있었습니다.🤦🏻‍♀️

안녕!

내가 지금 네 계정으로 너한테 이메일 보낸거 보여?

그래, 뭐 간단히 말하면 내가 네 기기에 마음껏 접속할 수 있다는 소리지.

지난 몇 달 동안 널 계속 지켜보고 있었어.

어떻게 지켜봤냐고? 그게 말이지, 넌 네가 접속했던 성인 사이트에 있던 악성 소프트웨어에 감염됐거든.

(이하 협박하면서 비트코인으로 돈 보내라는 내용)

SRV

Service 레코드.

SRV 레코드는 서비스를 호스팅하는 서버의 위치(호스트 이름 및 포트 번호)를 식별하는데 사용되는 DNS 레코드입니다. 

예를 들면, 서버의 특정 포트에서 비디오나 오디오 연결을 하려면 SIP 프로토콜을 사용하는데, 이 SIP 프로토콜에 SRV레코드가 들어갑니다.

GSLB(Global server load balancing)에서 특정 포트를 지정할 때에도 사용합니다.

linuxer님의 한마디 : SRV레코드는 GSLB 페일오버 등 가중치와 포트를 이용한 사용처가 많습니다.

형식

_service._proto.name. TTL class SRV priority weight port target.

형식 설명

• service : 서비스 이름. 앞에 언더바(_)가 붙습니다.
• proto : 서비스의 전송 프로토콜. 일반적으로 TCP 또는 UDP이며, 앞에 언더바(_)가 붙습니다.
• name :이 레코드가 적용되는 도메인 이름. 점으로 끝납니다.
• TTL : 표준 DNS TTL(Time to Live)
• class : 표준 DNS class. 
• SRV : 레코드 유형. 항상 SRV라고 씁니다.
• priority : 대상 호스트의 우선 순위입니다. 값이 낮을수록 선호도가 높습니다
• weight : 우선 순위가 같은 레코드에 대한 상대적 가중치. 값이 높을수록 선택될 가능성이 높습니다.
• port : 서비스의 포트.
• target : 서비스를 제공하는 시스템의 정식 호스트 이름. 점으로 끝납니다.

예시

_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.

SRV 레코드가 쓰이는 곳

• CalDAV
• Kerberos
• LDAP
• POP
• IMAP

참고 링크

알면 도움되는 링크

• Google ToolBox
• 후이즈검색 
• ping.pe 
• InfoByIp.com
• 책 <IT 엔지니어를 위한 네트워크 입문> 

참고한 자료

• 스티븐 님 블로그 > [이해하기] DNS(Domain Name Server) 
• 위키피디아 > CNAME record  
• Simple DNS Plus > DNS Record types 
• DNS – NSLOOKUP what is the meaning of the non-authoritative answer? 
• Q. SOA 레코드 필드 값은 어떤 기준으로 어떻게 설정해야 하나? 
• SRV record 
• Microsoft > Verify that SRV DNS records have been created – Windows Server