DNS 기술, 용어, 구성요소 컨셉에 대한 소개
21 Sep 2018
1 소개
DNS 또는 도메인 네임 시스템은 종종 웹 사이트와 서버를 구성하는 방법을 배우는 데 매우 어려운 부분입니다. DNS 작동 방식을 이해하면 웹 사이트에 대한 액세스 구성과 관련된 문제를 진단하는 데 도움이 되며 뒤에서 일어나는 일에 대한 이해를 넓힐 수 있습니다.
이 가이드에서는 DNS 구성과 관련된 기본 DNS 개념에 대해 설명합니다. 도메인을 해결하거나 제어판에서 도메인을 설정하기 위해 자체 서버를 설정하기 전에 이 모든 기능이 실제로 어떻게 작동하는 지에 대한 기본 개념을 살펴 보겠습니다.
해결(resolve) : 도메인 네임을 통해서 ip 주소를 얻어내는 것. 도메인 네임을 해결(resolve) 해야한다는 것은 도메인 네임을 바탕으로 ip 주소를 알아야 한다는 뜻.
2 도메인 용어
우리는 용어를 정의함으로써 시작해야 합니다. 이러한 주제 중 일부는 다른 컨텍스트에서 익숙하지만 도메인 네임과 DNS에 대해 언급 할 때는 다른 컴퓨팅 영역에서 너무 자주 사용되지 않는 용어가 많이 사용됩니다. 용어 설명을 시작하겠습니다.
2.1 DNS(Domain Name System)
더 일반적으로 “DNS”로 알려진 도메인 네임 시스템은 사람이 읽기 쉽도록 이름을 고유 주소로 해결할 수 있는 네트워킹 시스템입니다.
2.2 Domain Name
도메인 네임은 우리가 인터넷 자원과 연관시키는 데 익숙한 인간 친화적인 이름입니다. 예를 들어 ‘google.com’은 도메인 네임입니다. 어떤 사람들은 “google” 부분이 도메인이라고 말하지만 일반적으로 결합된 형식을 도메인 네임이라고 부를 수 있습니다.
2.3 IP Address
IP 주소는 네트워크 주소 지정 가능 위치라고 합니다. 각 IP 주소는 네트워크 내에서 고유해야 합니다. 우리가 웹 사이트에 관해 말할 때 이 네트워크는 전체 인터넷입니다.
가장 일반적인 주소 형식인 IPv4는 네자리 숫자로 쓰여지고 각 세트는 최대 세자리 숫자로 구성되며 각 집합은 점으로 구분됩니다. 예를 들어 “111.222.111.222”는 유효한 IPv4 IP 주소 일 수 있습니다. DNS를 사용하여 이름을 해당 주소에 매핑하므로 네트워크에서 방문하려는 각 장소에 대한 복잡한 숫자 집합을 기억할 필요가 없습니다.
2.4 Top-Level Domain
최상위 도메인 또는 TLD는 도메인의 가장 일반적인 부분입니다. 최상위 도메인은 오른쪽으로 가장 먼 부분입니다 (점으로 구분). 일반적인 최상위 도메인은 “com”, “net”, “org”, “gov”, “edu”및 “io”입니다.
최상위 도메인은 도메인 네임의 관점에서 계층 구조의 맨 위에 있습니다. 특정 파티(업체)는 ICANN (Internet Corporation of Assigned Names and Numbers)이 관리하는 최상위 도메인을 관리합니다. 이러한 파티(업체)는 일반적으로 도메인 등록 기관을 통해 TLD에 따라 도메인 네임을 배포 할 수 있습니다.
2.5 Hosts
도메인 내에서 도메인 소유자는 개별 호스트를 정의 할 수 있습니다. 개별 호스트는 도메인을 통해 액세스 할 수 있는 별도의 컴퓨터 또는 서비스를 나타냅니다. 예를 들어, 대부분의 도메인 소유자는 자신의 웹 서버를 베어 도메인 (example.com)과 “host” 정의 “www”(www.example.com)를 통해 액세스 할 수 있도록 합니다.
일반 도메인 아래에 다른 호스트 정의를 가질 수 있습니다. “api”호스트 (api.example.com)를 통해 API에 액세스 하거나 “ftp” 또는 “files”(ftp.example.com 또는 files.example.com) 호스트를 정의하여 ftp 액세스 권한을 가질 수 있습니다. 호스트 이름은 도메인에 대해 고유한 이상 임의로 지정할 수 있습니다.
2.6 SubDomain
호스트와 관련된 주제는 하위 도메인입니다. DNS는 계층 구조에서 작동합니다. TLD는 그 아래에 많은 도메인을 가질 수 있습니다. 예를 들어 ‘com’ TLD 에는 ‘google.com’과 ‘ubuntu.com’이 모두 있습니다. “subdomain”은 더 큰 도메인의 일부인 도메인을 나타냅니다. 이 경우 “ubuntu.com”은 “com”의 subdomain 이라고 할 수 있습니다. 이것은 일반적으로 도메인이라고 부르며, “우분투” 부분은 SLD 라고 하며, 이는 두 번째 레벨 도메인을 의미합니다.
마찬가지로 각 도메인은 그 아래에 있는 “subdomains”을 제어 할 수 있습니다. 이것은 대개 subdomains이 의미하는 바입니다. 예를 들어 “www.history.school.edu”에서 학교 역사 부서의 하위 도메인을 가질 수 있습니다. ‘history’ 부분은 하위 도메인입니다.
호스트 이름과 하위 도메인의 차이점은 호스트가 컴퓨터 또는 자원을 정의하는 반면 하위 도메인은 상위 도메인을 확장한다는 것입니다. 도메인 자체를 세분화하는 방법입니다.
하위 도메인이나 호스트에 대해 이야기하든, 도메인의 가장 왼쪽 부분이 가장 구체적임을 알 수 있습니다. 이것은 DNS가 작동하는 방식입니다. 우리가 읽는 방식으로 것처럼 왼쪽에서 오른쪽으로 읽으면 가장 구체적인 것을 알 수 있습니다.
2.7 Fully Qualified Domain Name
FQDN이라고도하는 정규화 된 도메인 네임을 절대 도메인 네임이라고 합니다. DNS 시스템의 도메인은 서로에 대해 상대적으로 주어질 수 있으므로 다소 모호 할 수 있습니다. FQDN은 도메인 네임 시스템의 절대 루트와 관련하여 위치를 지정하는 절대 이름입니다.
즉, TLD를 포함한 각 상위 도메인을 지정합니다. 적절한 FQDN은 점으로 끝나며 DNS 계층 구조의 루트를 나타냅니다. FQDN의 예는 “mail.google.com.”입니다. 때로는 FQDN을 요구하는 소프트웨어는 끝 점이 필요하지 않지만 ICANN 표준을 준수하려면 후행 점이 필요합니다.
2.8 Name Server
네임 서버는 도메인 네임을 IP 주소로 변환하도록 지정된 컴퓨터입니다. 이 서버는 DNS 시스템에서 대부분의 작업을 수행합니다. 도메인 번역의 총 수는 어느 한 서버에 비해 너무 많기 때문에 각 서버는 다른 네임 서버로 요청을 리다이렉션하거나 책임지고 있는 하위 도메인의 하위 집합에 대한 책임을 위임 할 수 있습니다.
네임 서버는 “권한”을 가질 수 있습니다. 즉, 제어 하에있는 도메인에 대한 쿼리에 대한 응답을 제공합니다. 그렇지 않으면 다른 서버를 가리 키거나 다른 네임 서버의 데이터의 캐시된 복사본을 제공 할 수 있습니다.
2.9 Zone File
Zone File은 도메인 네임과 IP 주소 간의 매핑을 포함하는 간단한 텍스트 파일입니다. 이것은 DNS 시스템이 사용자가 특정 도메인 네임을 요청할 때 어떤 IP 주소가 접촉되어야 하는지를 마침내 찾는 방법입니다. Zone File은 네임 서버에 있으며 일반적으로 특정 도메인에서 사용 가능한 리소스 또는 해당 정보를 가져올 수 있는 리소스를 정의합니다.
2.10 Records
Zone File 내에서 레코드는 유지됩니다. 가장 간단한 형식에서 레코드는 기본적으로 리소스와 이름 간의 단일 매핑입니다. 이것들은 도메인 네임을 IP 주소에 맵핑 하고, 도메인에 대한 네임 서버를 정의하고, 도메인에 대한 메일 서버를 정의 할 수 있습니다.
3 How DNS Works
이제 DNS와 관련된 몇 가지 용어에 익숙해 졌으므로 시스템이 실제로 어떻게 작동하는지 살펴볼까요?
이 시스템은 높은 수준의 개요에서는 매우 간단하지만 세부 사항을 볼 때 매우 복잡합니다. 오늘날 전반적으로 우리가 알고 있는 인터넷의 채택에 필수적인 매우 신뢰할 수있는 인프라입니다.
3.1 Root Servers
앞서 말했듯이 DNS는 핵심적으로 계층적 시스템입니다. 이 시스템의 상단에는 “루트 서버”가 있습니다. 이 서버는 다양한 조직에 의해 관리되며 ICANN(Internet Assigned Names and Numbers)이 위임한 권한을 가집니다.
현재 작동중인 루트 서버는 13개입니다. 그러나 분당 해결해야하는 이름이 많기 때문에 이러한 각 서버는 실제로 미러링 됩니다. 이 설정에 대한 흥미로운 점은 단일 루트 서버의 각 미러가 동일한 IP 주소를 공유한다는 것입니다. 특정 루트 서버에 대한 요청이 있을 때 요청은 해당 루트 서버의 가장 가까운 미러로 라우팅됩니다.
이 루트 서버는 무엇을 할까요? 루트 서버는 최상위 도메인에 대한 정보 요청을 처리합니다. 따라서 하위 수준 네임 서버에서 해결할 수 없는 요청이 들어오는 경우 해당 도메인의 루트 서버에 쿼리가 수행됩니다.
루트 서버는 실제로 도메인이 호스팅되는 위치를 알 수 없습니다. 그러나 요청자에게 특별히 요청된 최상위 도메인을 처리하는 네임 서버로 지시자를 보낼 수 있습니다.
따라서 “www.wikipedia.org”에 대한 요청이 루트 서버에 만들어지면 루트 서버는 해당 레코드의 결과를 찾지 못합니다. 존 파일에서 “www.wikipedia.org”와 일치하는 목록을 확인합니다. 하나도 찾지 못 할 것입니다.
대신 “org” TLD에 대한 레코드를 찾고 요청 엔터티에 “org” 주소를 담당하는 네임 서버의 주소를 제공합니다
3.2 TLD Servers
그러면 요청자는 요청의 최상위 도메인을 담당하는 IP 주소 (루트 서버가 부여한)에 새 요청을 전송합니다. 따라서 예를 계속하기 위해 “org” 도메인에 대해 아는 책임이 있는 네임 서버에 요청하여 “www.wikipedia.org”의 위치를 알고 있는지 확인합니다.
다시 한 번 요청자는 존 파일에서 “www.wikipdia.org”를 찾습니다. 파일에서 이 레코드를 찾지 못합니다.
그러나 “wikipedia.org”를 담당하는 네임 서버의 IP 주소 목록을 찾을 수 있습니다. 이것은 우리가 원하는 대답에 훨씬 가까워지고 있습니다.
3.3 Domain-Level Name Servers
이 시점에서 요청자는 리소스의 실제 IP 주소를 알 수 있는 네임 서버의 IP 주소를 가집니다. 그것은 “www.wikipedia.org”를 해결할 수 있는지 다시 묻는 새로운 요청을 네임 서버에 보냅니다.
네임 서버는 존 파일을 검사하고 “wikipedia.org”와 연관된 존 파일을 찾습니다. 이 파일의 내부에는 “www”호스트에 대한 레코드가 있습니다. 이 레코드는이 호스트가 있는 IP 주소를 알려줍니다. 네임 서버는 요청자에게 최종 답을 리턴합니다.
3.4 What is a Resolving Name Server?
위의 시나리오에서 우리는 “요청자”를 언급했습니다. 이 상황에서 요청자는 무엇일까요?
거의 모든 경우에 요청자는 “resolving name server” 라고합니다. “resolving name server” 는 다른 서버에 질문하도록 구성된 서버입니다. 이는 기본적으로 이전 쿼리 결과를 캐시 하여 속도를 향상시키고 루트 서버의 주소를 알고 있어 아직 알지 못하는 것에 대한 요청을 해결 할 수 있는 중개자입니다.
기본적으로 사용자는 일반적으로 컴퓨터 시스템에 몇 개의 확인 네임 서버를 구성합니다. “resolving name server” 는 대개 ISP 또는 다른 조직에서 제공합니다. 예를 들어 Google은 사용자가 쿼리 할 수있는 DNS 서버를 제공합니다. 컴퓨터에서 자동 또는 수동으로 구성 할 수 있습니다.
브라우저의 주소 표시 줄에 URL을 입력하면 컴퓨터는 먼저 자원이있는 곳을 로컬에서 찾을 수 있는지 확인합니다. 컴퓨터의 “host” 파일과 몇 개의 다른 위치를 확인합니다. 그런 다음 요청을 “resolving name server”에 보내고 자원의 IP 주소를 수신 할 때까지 대기합니다.
resolve 네임 서버는 그 캐시에 대한 응답을 확인합니다. 찾지 못하면 위의 단계를 거칩니다.
resolving name server는 기본적으로 엔드 유저를 위한 요청 프로세스를 위임 받습니다. 클라이언트는 간단히 리소스가 어디에 있는지 resolving name server에게 요청 할 수 있어야 합니다. 그리고 resolving name server 가 조사하고 마침내 답을 구해줄 것이라고 확신해야 합니다.
4 Zone Files
위의 과정에서 “zone files”과 “records”에 대해 언급했습니다.
Zone file은 네임 서버가 알고 있는 도메인에 대한 정보를 저장하는 방법입니다. 네임 서버가 알고 있는 모든 도메인은 존 파일에 저장됩니다. 일반적으로 네임 서버로 들어오는 대부분의 resolving name server와 같이 재귀 쿼리를 처리하도록 구성된 경우 응답을 찾아서 반환합니다.
그렇지 않으면 요청한 당사자에게 다음에 보일 위치를 알려줍니다. 네임 서버의 존 파일이 많을수록 정식으로 응답 할 수있는 요청이 많아집니다.
zone file은 기본적으로 전체 DNS 명명 시스템의 하위 집합인 DNS “zone”을 설명합니다. 일반적으로 단일 도메인을 구성하는 데 사용됩니다. 여기에는 해당 도메인에 대한 자원의 위치를 정의하는 여러 레코드가 포함될 수 있습니다.
zone의 $ORIGIN 은 기본적으로 zone의 최상위 권한 수준과 동일한 매개 변수입니다.
따라서 zone 파일을 사용하여 “example.com.”을 구성하는 경우 $ORIGIN 은 example.com으로 설정됩니다.
이 파일은 zone file의 맨 위에 구성되거나 zone 파일을 참조하는 DNS 서버의 구성 파일에 정의 될 수 있습니다. 어느 쪽이든 이 매개 변수는 영역이 권위 있는 영역을 설명합니다.
마찬가지로 $TTL은 제공하는 정보의 “수명”을 구성합니다. 그것은 기본적으로 타이머입니다. 캐싱 네임 서버는 이전에 질의 된 결과를 사용하여 TTL 값이 만료 될 때까지 질문에 응답 할 수 있습니다.
5 Record Types
존 파일 내에서 우리는 다양한 레코드 유형을 가질 수 있습니다. 우리는 좀 더 보편적 인 (또는 필수 유형들) 몇 가지를 여기에서 다룰 것입니다.
5.1 SOA Records
SOA(Start of Authority) 레코드는 모든 존 파일에서 필수 레코드입니다. 파일의 첫 번째 실제 레코드 여야합니다. $ORIGIN 또는 $TTL 스펙이 위에 나타내는 경우도 있습니다. 또한 이해해야 할 가장 복잡한 것 중 하나입니다.
SOA 레코드의 시작은 다음과 같습니다.
domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
1h ; negative TTL
)
각 부분에 대한 설명을 해봅시다.
domain.com. :
이것은 zone의 root입니다. 존 파일이 ‘domain.com.’ 도메인 설명합니다. 종종 @으로 대신 사용 된 것을 볼 수 있는데, 이는 위에서 배운
$ORIGIN변수의 내용을 대체하는 자리 표시 자일뿐입니다.IN SOA:
“IN” 부분은 인터넷을 의미하며 많은 레코드에 표시됩니다. SOA는 Start of Authority 레코드임을 나타내는 지표입니다.
ns1.domain.com. :
이것은 이 도메인의 기본 마스터 네임 서버를 정의합니다. 네임 서버는 마스터이거나 슬레이브 일 수 있으며 동적 DNS가 구성되면 하나의 서버가 여기에 있는 “primary master” 여야합니다. 동적 DNS를 구성하지 않은 경우 이것은 마스터 네임 서버 중 하나입니다.
admin.domain.com.:
이 영역에 대한 관리자의 전자 메일 주소입니다. “@”는 이메일 주소의 점으로 대체됩니다. 전자 메일 주소의 이름 부분에 일반적으로 점이 있으면이 부분의 “"로 바뀝니다
(your.name@domain.com은 your\name.domain.com 이 됩니다).
12083:
이것은 존 파일의 일련 번호입니다. 영역 파일을 편집 할 때마다이 번호를 증가시켜 영역 파일이 올바르게 전파되도록 해야 합니다. 슬레이브 서버는 영역의 마스터 서버의 일련 번호가 자신의 시스템에 있는 것보다 큰지 확인합니다. 이 경우 새 존 파일을 요청하고 그렇지 않으면 원래 파일을 계속 제공합니다.
3h:
영역의 새로 고침 간격입니다. 이것은 존 파일 변경을 위해 마스터를 폴링하기 전에 슬레이브가 대기하는 시간입니다.
30m:
이 영역에 대한 재시도 간격입니다. 새로 고침주기가 끝났을 때 슬레이브가 마스터에 연결할 수 없으면이 시간 동안 기다린 후 마스터를 폴링하려고 시도합니다.
3w:
이것은 만료 기간입니다. 슬레이브 네임 서버가 이 시간 동안 마스터에 접속할 수 없는 경우, 더 이상 응답을 이 영역의 신뢰할 수 있는 소스로 반환하지 않습니다(
쓸모 없는 정보라고 알려준다는 뜻?).1h:
이것은 이 파일에서 요청 된 이름을 찾을 수 없는 경우 네임 서버가 이름 오류를 캐시하는 시간입니다.
5.2 A and AAAA Records
이 두 레코드는 호스트를 IP 주소에 매핑합니다. “A” 레코드는 호스트를 IPv4 IP 주소로 매핑하는 반면 “AAAA”레코드는 호스트를 IPv6 주소로 매핑하는 데 사용됩니다. 이 레코드의 일반적인 형식은 다음과 같습니다.
host IN A IPv4_address
host IN AAAA IPv6_address
따라서 SOA 레코드가 “ns1.domain.com”에서 기본 마스터 서버를 호출 했으므로 “ns1.domain.com” 주소가 “domain.com” 영역 내에 있으므로이 주소를 IP 주소의 주소로 매핑해야 합니다.
ns1 IN A 111.222.111.222
우리는 전체 이름을 말할 필요가 없음을 주목하십시오. FQDN 없이 호스트에 줄 수 있고 나머지는 DNS 서버가 $ORIGIN 값으로 채 웁니다. 그러나 의미론적이라고 느끼면 FQDN 전체를 쉽게 사용할 수 있습니다.
ns1.domain.com. IN A 111.222.111.222
대부분의 경우 여기에서 웹 서버를 “www”로 정의합니다.
www IN A 222.222.222.222
또한 기본 도메인이 해결되는 위치를 알려야 합니다. 우리는 이렇게 할 수 있습니다 :
domain.com. IN A 222.222.222.222
대신에 “@”를 사용하여 기본 도메인을 참조 할 수 있습니다.
@ IN A 222.222.222.222
또한 이 도메인 아래 서버에 명시적으로 정의되지 않은 것도 해결할 수 있습니다. 우리는 “*“와일드 카드로 이것을 할 수 있습니다 :
* IN A 222.222.222.222
이들 모두는 IPv6 주소에 대한 AAAA 레코드와 마찬가지로 잘 작동합니다.
5.3 CNAME Records
CNAME 레코드는 서버의 정규 이름에 대한 별칭을 정의합니다 (A 또는 AAAA 레코드로 정의 됨). 예를 들어 “server1”호스트를 정의한 A 이름 레코드를 갖고 이 호스트의 별칭으로 “www”를 사용할 수 있습니다.
server1 IN A 111.111.111.111
www IN CNAME server1
이러한 별칭에는 서버에 대한 추가 쿼리가 필요하기 때문에 성능 손실이 발생합니다. 대부분의 경우 A 또는 AAAA 레코드를 추가로 사용하여 동일한 결과를 얻을 수 있습니다. CNAME이 권장되는 한 가지 경우는 현재 영역 외부의 리소스에 대한 별칭을 제공하는 것입니다.
5.4 MX Records
MX 레코드는 도메인에 사용되는 메일 교환을 정의하는 데 사용됩니다. 이렇게 하면 이메일 메시지가 메일 서버에 올바르게 도착할 수 있습니다. 다른 레코드 유형과 달리 메일 레코드는 일반적으로 전체 영역에 적용되므로 호스트를 무언가에 매핑하지 않습니다. 따라서 일반적으로 다음과 같이 보입니다.
IN MX 10 mail.domain.com.
처음에는 호스트 이름이 없습니다. 또한 거기에 여분의 번호가 있음에 유의하십시오. 이것은 정의 된 메일 서버가 여러 개인 경우 컴퓨터가 메일을 보낼 서버를 결정하는 데 도움이되는 환경 설정 번호입니다. 숫자가 낮을수록 우선 순위가 높습니다. 일반적으로 MX 레코드는 A 또는 AAAA 레코드로 정의 된 호스트를 가리켜 야하며 CNAME에 의해 정의 된 호스트는 아닙니다.
따라서 두 개의 메일 서버가 있다고 가정 해 봅시다. 다음과 같은 레코드가 있어야합니다.
IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
이 예에서 “mail1” 호스트는 기본 전자 메일 교환 서버입니다. 다음과 같이 작성할 수도 있습니다.
IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
5.5 NS Records
이 레코드 유형은이 영역에 사용되는 네임 서버를 정의합니다. “존 파일이 네임 서버에 있다면, 왜 자신을 참조 할 필요가 있을까요?”라고 궁금해 할 것입니다. DNS를 매우 성공적으로 만드는 요소 중 하나는 여러 수준의 캐싱 입니다. 존 파일 내에서 네임 서버를 정의하는 한 가지 이유는 존 파일이 실제로 다른 네임 서버의 캐시 된 복사본에서 서비스되고 있다는 것입니다. 네임 서버 자체에 정의 된 네임 서버를 필요로 하는 다른 이유가 있지만 여기서는 다루지 않을 것입니다. MX 레코드와 마찬가지로이 매개 변수는 영역 전체의 매개 변수이므로 호스트를 차지하지 않습니다. 일반적으로 다음과 같이 보입니다.
IN NS ns1.domain.com.
IN NS ns2.domain.com.
하나의 서버에 문제가있는 경우 올바르게 작동하려면 각 영역 파일에 최소 두 개의 네임 서버가 정의되어 있어야합니다. 대부분의 DNS 서버 소프트웨어는 단일 네임 서버 만있는 경우 영역 파일을 유효하지 않은 것으로 간주합니다.
항상 그렇듯이 A 또는 AAAA 레코드가있는 호스트에 대한 매핑을 포함시킵니다.
IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233
사용할 수 있는 레코드 유형이 많이 있지만 설명한 유형들이 가장 일반적인 유형일 것입니다.
5.6 PTR Records
PTR 레코드는 IP 주소와 연관된 이름을 정의하는 데 사용됩니다. PTR 레코드는 A 또는 AAAA 레코드의 역입니다. PTR 레코드는 .arpa 루트에서 시작하여 IP 주소의 소유자에게 위임된다는 점에서 고유합니다. RIR (Regional Internet Registries)은 조직 및 서비스 공급자에게 IP 주소 위임을 관리합니다. 지역 인터넷 등록 기관에는 APNIC, ARIN, RIPE NCC, LACNIC 및 AFRICIC이 포함됩니다.
다음은 111.222.333.444에 대한 PTR 레코드의 예입니다.
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
IPv6 주소에 대한 PTR 레코드의이 예는 Google의 IPv6 DNS 서버 2001 : 4860 : 4860 :: 8888의 역순의 형식을 보여줍니다.
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.
-x 플래그가있는 명령 행 도구를 사용하여 IP 주소의 역 DNS 이름을 검색 할 수 있습니다.
다음은 dig 명령의 예입니다. +short 값은 출력을 역 DNS 이름으로 줄이기 위해 추가됩니다.
dig -x 8.8.4.4 +short
위의 dig 명령의 출력은 IP 주소의 PTR 레코드에있는 도메인 네임입니다.
google-public-dns-b.google.com.
인터넷상의 서버는 PTR 레코드를 사용하여 로그 이름에 도메인 네임을 배치하고 스팸 처리에 대한 정보를 제공하며 다른 장치에 대해 쉽게 읽을 수 있는 세부 정보를 표시합니다.
가장 일반적으로 사용되는 전자 메일 서버는 전자 메일을 받는 IP 주소의 PTR 레코드를 조회합니다. 원본 IP 주소에 PTR 레코드가 연결되어 있지 않으면 보내는 전자 메일이 스팸으로 간주 되어 거부 될 수 있습니다. PTR의 FQDN이 보내는 전자 메일의 도메인 네임과 일치하는 것은 중요하지 않습니다. 중요한 것은 일치하는 순방향 A 레코드가 있는 유효한 PTR 레코드가 있다는 것입니다.
일반적으로 인터넷의 네트워크 라우터에는 실제 위치와 일치하는 PTR 레코드가 제공됩니다. 예를 들어 뉴욕시 또는 시카고에 있는 라우터의 경우 ‘NYC’또는 ‘CHI’에 대한 참조를 볼 수 있습니다. 이것은 traceroute 또는 MTR을 실행하고 인터넷 트래픽이 사용하는 경로를 검토 할 때 유용합니다.
전용 서버 또는 VPS 서비스를 제공하는 대부분의 제공 업체는 고객이 자신의 IP 주소에 대해 PTR 레코드를 설정할 수 있는 기능을 제공합니다. Droplet의 도메인 네임이 지정되면 DigitalOcean에서 자동적으로 Droplet의 PTR 레코드를 지정합니다. 드롭 릿 이름은 생성 중에 지정되며 나중에 드롭 릿 컨트롤 패널의 설정 페이지를 사용하여 편집 할 수 있습니다.
참고 : PTR 레코드의 FQDN에 해당하는 일치하는 전달 A 레코드가 있어야 합니다. 예 : 111.222.333.444는 PTR이 server.example.com이고 server.example.com은 111.222.333.444를 나타내는 A 레코드입니다.
5.7 CAA Records
CAA 레코드는 도메인의 SSL/TLS 인증서를 발급 할 수있는 인증 기관 (CA)을 지정하는 데 사용됩니다. 2017 년 9월 8일부터 모든 CA는 인증서 발급 전에 이러한 기록을 확인해야 합니다. 레코드가 없으면 모든 CA가 인증서를 발급 할 수 있습니다. 그렇지 않으면 지정된 CA만 인증서를 발급 할 수 있습니다. CAA 레코드는 단일 호스트 또는 전체 도메인에 적용될 수 있습니다.
예제 CAA 레코드는 다음과 같습니다.
example.com. IN CAA 0 issue "letsencrypt.org"
호스트, IN 및 레코드 유형 (CAA)은 공통 DNS 필드입니다. 위의 CAA 관련 정보는 “letsencrypt.org” 부분의 0 문제입니다. 이것은 flags (0), tag (발행) 및 값 ( “letsencrypt.org”)의 세 부분으로 구성됩니다.
flags는 CA가 이해할 수 없는tag를 처리하는 방법을 나타내는 정수입니다.flags가 0이면 레코드가 무시됩니다. 1 인 경우 CA는 인증서 발급을 거부해야합니다.tag는 CAA 레코드의 목적을 나타내는 문자열입니다. 현재 CA는 특정 호스트 이름에 대한 인증서를 생성하고 와일드 카드 인증서를 승인하거나 iodef를 사용하여 CA가 정책 위반을보고 할 수 있는 URL을 정의하도록 CA에 권한을 부여 할 수 있습니다.values은 레코드의tag와 관련된 문자열입니다. 이슈와 발행물의 경우 일반적으로 권한을 부여 할 CA의 도메인이됩니다. iodef의 경우 연락 양식의 URL이거나 전자 메일 피드백의 mailto : 링크 일 수 있습니다.
다음 옵션을 사용하여 dig를 사용하여 CAA 레코드를 가져올 수 있습니다.
dig example.com type257
CAA 레코드에 대한 자세한 내용은 RFC 6844 참고하여 CAA 레코드를 만들고 관리하는 방법확인하세요.
결론 Conclusion
이제 DNS 작동 방식에 대해 꽤 잘 알고 있어야 합니다. 방법에 익숙해지면 일반적인 생각을 파악하기가 상대적으로 쉽지만 경험이 부족한 관리자가 관리하기가 어려울 수 있습니다.