Skip to content

Domain Name System

도메인 네임 시스템(Domain Name System, DNS)는 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하기 위해 개발되었다. 특정 컴퓨터(또는 네트워크로 연결된 임의의 장치)의 주소를 찾기 위해, 사람이 이해하기 쉬운 도메인 이름을 숫자로 된 식별 번호(IP 주소)로 변환해준다. 도메인 네임 시스템은 흔히 "전화번호부"에 비유된다. 인터넷 도메인 주소 체계로서 TCP/IP의 응용에서, www.example.com과 같은 주 컴퓨터의 도메인 이름을 192.168.1.0과 같은 IP 주소로 변환하고 라우팅 정보를 제공하는 분산형 데이터베이스 시스템이다.

Categories

DNS Servers

  • Berkeley Internet Name Domain (BIND; bind9; bind)
  • PowerDNS (pdns)
  • nsupdate
  • Pi-hole - Pi-hole은 광고와 추적을 차단하는 데 주로 사용되지만, 네트워크의 로컬 DNS 서버로도 훌륭하게 작동합니다. 설정이 간단하며 웹 인터페이스를 통해 쉽게 관리할 수 있습니다.
  • Dnsmasq - hosts 파일에 있는 정보를 그대로 DNS 설정 파일로 사용 할 수 있다.
  • Unbound - NLnet Labs의 검증, 재귀 및 캐싱 DNS 확인자 제품입니다. BSD 라이센스에 따라 오픈 소스 형태로 무료로 배포됩니다.
  • NSD
  • CoreDNS (CNCF) - 컨테이너 환경에서 자주 사용된다.
  • RethinkDNS - Serverless DNS resolver
  • MaraDNS - 서비스 테스트에 사용할 수 있는 간단한 Windows 용 DNS 서비스

Domain Registr

Domain name registrar 항목 참조. 간단히, (문자 그대로) 도메인 등록 대행자 이다.

Tools

DNS 서브도메인 이름

대부분의 리소스 유형에는 RFC 1123에 정의된 대로 DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다. 이것은 이름이 다음을 충족해야 한다는 것을 의미한다.

  • 253자를 넘지 말아야 한다.
  • 소문자와 영숫자 - 또는 . 만 포함한다.
  • 영숫자로 시작한다.
  • 영숫자로 끝난다.

RFC 1123 레이블 이름

일부 리소스 유형은 RFC 1123에 정의된 대로 DNS 레이블 표준을 따라야 한다. 이것은 이름이 다음을 충족해야 한다는 것을 의미한다.

  • 최대 63자이다.
  • 소문자와 영숫자 또는 - 만 포함한다.
  • 영숫자로 시작한다.
  • 영숫자로 끝난다.

RFC 1035 레이블 이름

몇몇 리소스 타입은 자신의 이름을 RFC 1035에 정의된 DNS 레이블 표준을 따르도록 요구한다. 이것은 이름이 다음을 만족해야 한다는 의미이다.

  • 최대 63개 문자를 포함
  • 소문자 영숫자 또는 -만 포함
  • 알파벳 문자로 시작
  • 영숫자로 끝남

사용 포트

UDP 53포트

TCP 53포트

  • Zone Transfer 시 사용 (Master와 Slave DNS간 동기화 할때 사용한다)
  • Message 정보가 512바이트보다 클 경우 사용됨
  • 네임서버는 최대 7개 이상 NS 레코드를 사용하지않도록 한다.
  • 동일 호스트에 대한 A레코더는 30개 넘지 않도록한다. 넘으면 TCP로 재질의

DNS Records

A

A record란 domain name에 하나의 IPv4 Address가 있음을 의미합니다. 하나의 도메인(서브나 루트 포함)에 해당하는 IP 주소의 값을 가지고 있습니다. 

dev.test.me -> 123.456.789.123 // 해당 도메인의 IP 주소
test.me -> 987.654.321.123     // 해당 도메인의 IP 주소

AAAA

IPv6 주소

MX

MX 레코드는 메일 연결에 사용됩니다. 입력된 정보를 변경/삭제할 경우 해당 서비스 사용이 변경/중단될 수 있으니, 설정한 메일 정보를 반드시 확인하세요.

TXT

이메일 발신자와 애플리케이션별 값을 확인하는 용도

  • SPF 레코드를 입력하고자 하는 경우 위 TXT 레코드란에 입력해 주세요.
  • 사용하는 도메인이 스팸으로 차단되는 것을 방지하기 위하여 SPF 레코드 등록을 권장합니다.
  • 올바른 SPF를 적용하기 위해 SPF Record 작성 도우미를 이용하여 SPF 레코드 등록을 권장합니다. [SPF Record 작성 도우미]
  • SPF 레코드값의 올바른 입력 예 : 아래 2가지 예제와 같은 형식으로 입력하시기 바랍니다.
    • v=spf1 include:spf.hiworks.co.kr ~all / v=spf1 ip4:211.243.118.50 ~all
    • TXT레코드에는 @, ^, <, >, ?, `(어퍼스트로피)를 입력할 수 없습니다.

CNAME

CNAME = Canonical Name의 줄임말로 하나의 도메인에 다른 이름을 부여하는 방식을 의미합니다. 도메인 이름의 또 다른 이름으로 생각하면 됩니다. CNAME 정보는 메일, 블로그 연결 등에 사용됩니다. 

blog.test.me -> test.me // test.me의 또 다른 도메인명
www.test.me -> test.me  // test.me의 또 다른 도메인명

설정시 아래와 같이 입력하면 된다. 

answer CNAME youthful-nightingale-07aa0b.netlify.com.

PTR

IP주소를 도메인 주소에 맵핑

SRV 레코드

서버를 식별하는 애플리케이션별 값.

(Gabia 에서) SRV 레코드 설정 시, 대상 값 입력 내용 끝에 .을 입력하셔야 정상 세팅 됩니다. 

sipdir.online.lync.com.

SPF

(권장되지 않음) <- ??? 왜? amazon route 53에서 그러더라

NAPTR

DDDS 애플리케이션에서 사용

CAA

도메인에 대해 SSL/TLS 인증서를 생성할 수 있는 CA 제한

NS

호스팅 영역의 이름 서버

DS

DNSSEC에 대한 신뢰 체인을 설정하는 데 사용되는 위임 서명자 (Delegation Signer)

DNSSEC

이메일 서버는 DNS를 사용하여 메시지를 라우팅하기 때문에 이메일 서버는 DNS 인프라 내의 보안 문제에 취약합니다. 2014년 9월에 CMU의 연구자들은 Yahoo!, Hotmail, Gmail 서버를 통해 보내려던 이메일이 악성 메일 서버로 라우팅되는 것을 발견했습니다. 공격자들이 응답을 수락하기 전에 자격 증명을 확인하지 않는 DNS의 수십 년 된 취약점을 악용한 것입니다.

해결책은 DNS에 인증을 추가하여 신뢰를 더하는 DNSSEC라는 프로토콜입니다. DNS 확인자가 blog.cloudflare.com를 찾는 경우, .com 네임 서버는 확인자가 Cloudflare에 대한 반환된 레코드를 검증하도록 지원하고, Cloudflare는 블로그에 대한 반환된 레코드를 검증하도록 지원합니다. 루트 DNS 네임 서버는 .com을 검증하는 데 도움을 주며, 루트가 게시한 정보는 루트 서명식을 포함한, 철저한 보안 절차를 거칩니다.

DNSSEC의 가벼운 소개

DNSSEC는 기존의 DNS 레코드에 암호화 서명을 추가하여 안전한 DNS 시스템을 만듭니다. 이러한 디지털 서명은 A, AAAA, MX, CNAME 등과 같은 일반적인 레코드 유형과 함께 DNS 네임 서버에 저장됩니다. 관련된 서명을 점검함으로써 요청된 DNS 레코드가 권한 있는 네임 서버에서 왔으며 중간자 공격으로 삽입된 가짜 레코드와 달리 전송 중 경로에서 변경되지 않았음을 확인할 수 있습니다.

서명 검증을 용이하게 하기 위해 DNSSEC는 다음과 같이 몇 가지 새로운 DNS 레코드 유형을 추가합니다.

  • RRSIG - 암호화된 서명이 들어 있습니다
  • DNSKEY - 공개 서명 키가 들어 있습니다
  • DS - DNSKEY 레코드의 해시가 들어 있습니다
  • NSEC, NSEC3 - DNS 레코드의 명시적 존재 부정에 적합합니다
  • CDNSKEY, CDS - 상위 구간의 DS 레코드 수정을 요청하는 하위 구간에 적합합니다.

SOA

DNS '권한 시작'(SOA) 레코드는 관리자의 이메일 주소, 도메인이 마지막으로 업데이트된 시간, 새로 고침 사이에 서버가 대기해야 하는 시간 등 도메인 또는 영역에 대한 중요한 정보를 저장합니다.

모든 DNS 영역에는 IETF 표준을 준수하기 위해 SOA 레코드가 필요합니다. SOA 레코드는 영역 전송에도 중요합니다.

마지막 구두점(.)의 의미

거의 알려지지 않은 사실이지만 정규화된(명백한) DNS 도메인 이름 끝에 점이 있습니다. DNS 서버를 운영하는 사람들은 일반적으로 이것을 알고 있지만 (후행 점을 놓치면 DNS 구성이 작동하지 않을 수 있음) 일반 대중은 일반적으로 알지 못합니다. 끝에 점이 없는 도메인 이름은 정규화되지 않았으며 모호할 수 있습니다. 이는 1987년 DNS 사양인 RFC 1034에 문서화되어 있습니다. 

Since a complete domain name ends with the root label, this leads to a
printed form which ends in a dot.  We use this property to distinguish between:

   - a character string which represents a complete domain name
     (often called "absolute").  For example, "poneria.ISI.EDU."

   - a character string that represents the starting labels of a
     domain name which is incomplete, and should be completed by
     local software using knowledge of the local domain (often
     called "relative").  For example, "poneria" used in the
     ISI.EDU domain.

NXDOMAIN

NXDOMAIN을 나타내는 오류 메시지가 표시되면 도메인 이름을 확인할 수 없음을 의미합니다. 이것은 논리적으로 액세스하려는 사이트를 탐색 할 수 없음을 의미합니다.

Extensible Provisioning Protocol (EPP)

DNS에서 EPP (Extensible Provisioning Protocol) 상태 코드는 도메인 등록 및 관리에 사용되는 프로토콜의 응답 코드입니다. DNS 자체에서는 EPP 상태 코드를 직접적으로 반환하지 않지만, 도메인 등록기관과의 상호작용을 통해 EPP 상태를 확인할 수 있습니다.

EPP 상태 코드는 보통 도메인의 등록 상태를 나타내며, WHOIS 정보나 등록기관의 API를 통해 확인할 수 있습니다.

EPP 상태 코드를 확인하는 방법

whois 명령어를 사용하여 도메인의 WHOIS 정보를 조회할 수 있습니다. 등록된 도메인에 대한 EPP 상태 코드가 WHOIS 응답에서 제공될 수 있습니다. 

whois example.com | grep -i status

Example

아래는 Wikipedia에 나오는 예시입니다. 아래처럼 해당하는 도메인의 TYPE이 뭔지에 따라서 가지고 있는 Value가 다릅니다.

NAME

TYPE

VALUE

bar.example.com

CNAME

foo.example.com

foo.example.com

A

192.0.2.23

Fully qualified domain name

전체 주소 도메인 네임(Fully Qualified Domain Name, FQDN)은 호스트 이름과 도메인 이름을 포함한 전체 도메인 이름을 일컫는 용어이다.

CentOS에서 아래의 명령어로 확인할 수 있다. 

$ hostname --fqdn

구조

도메인 이름 공간

도메인 이름 공간은 도메인 이름을 트리 형태로 구성한 것이다. 트리의 각 노드는 0개 이상의 리소스 레코드(resource record)를 가진다. 트리는 루트 존(root zone)에서 시작하여 여러개의 하위 존으로 나뉜다. 각 DNS 존은 하나의 권한있는 네임서버(authoritative nameserver)에 의해 관리되는 노드들의 집합이다. (하나의 네임서버가 여러개의 존을 관리할 수도 있다.)

관리 권한은 분할되어서 새로운 존을 형성할 수 있다. 이 때 기존의 도메인 이름 공간의 일부분이 서브도메인 형태로 다른 네임서버에 권한이 위임된다고 한다. 그리고 기존의 존은 새로운 존에 대한 권한을 잃게 된다.

도메인 이름 형성

도메인 이름 형성에 관한 규칙은 RFC 1035, RFC 1123, RFC 2181에 정의되어 있다. 도메인 이름은 한개 이상의 부분(레이블)로 이루어 지고, 점으로 구분하여 붙여 쓴다. (예: example.com)

작동 방식

Public DNS

공용 DNS 목록을 나열한다.

Google Public DNS
IPv4: 8.8.8.8, 8.8.4.4
IPv6: 2001:4860:4860::8888, 2001:4860:4860::8844
DNS0
인터넷을 안전하게 사용하기 위한 유럽의 공용 DNS
https://www.dns0.eu/
  • 무료, 독립적이고, GDPR 준수하는 재귀 DNS 리졸버
  • EU의 시민 및 조직을 보호하기 위해 보안에 중점을 둠
  • dns0.eu 와 193.110.81.0 / 185.253.5.0 주소를 사용
  • 27개의 유럽 도시, 55개의 데이터 센터, 62대의 서버에 퍼져 있는 빠르고 분산된 DNS 인프라 스트럭쳐
  • DNS-over-HTTPS/TLS/QUIC/HTTP3, DDR Encrypted Upgrade를 지원
  • 보안에 민감한 환경을 위한 ZERO 서버 (193.110.81.9, 185.253.5.9) : 휴리스틱을 이용해 악성 도메인을 원천 차단
    • Newly Registered Domains (NRD) : 등록된지 30일 이하의 도메인 차단
    • Newly Active Domains (NAD) : 휴면 상태였다가 갑자기 활성화되는 도메인 차단
    • Domain Generation Algorithms (DGA) : 도메인 생성 알고리듬을 이용한 도메인들을 차단
    • IDN Homographs : 특정 문자만 바꿔서 다른 도메인인척 하는 도메인 차단 (라틴 문자 "e"를 키릴 문자 "е"로 대체하는 등)
    • Typosquatting : 오타를 이용한 도메인 차단 (google.com 대신 gooogle.com)
    • DNS Rebinding : Private IP 주소가 포함된 DNS 응답을 자동 차단해서 공격자가 인터넷을 통해 로컬장치를 제어하는 것을 방지
    • Dynamic DNS (DDNS) : 동적 DNS를 이용해 다른 서비스 인척 하는 경우가 있어서 차단
    • Cryptojacking : 다른 사람의 기기를 이용해서 암호화폐 마이닝 하는 것도 차단
    • Parked Domains : 싱글 페이지로 도메인 파킹 해둔 경우 종종 의심스럽거나 위험한 콘텐츠를 제공하므로 차단
    • High-risk Top-level Domains (TLD) : 공격자들이 선호하는 TLD 등을 차단
  • 아이들에게도 안전하게 필터링 해주는 DNS 별도 제공 (193.110.81.1, 185.253.5.1)
    • 성인 웹사이트 차단
    • 주요 검색엔진에서 음란물 필터링
    • 유튜브 영상에서 성인 비디오 차단
    • 데이팅 웹/앱 차단
    • 복합 콘텐츠(일부만 성인용인) 사이트 차단
    • 토렌트/불법복제 사이트 차단
    • 대부분의 광고 차단
  • NextDNS 공동 창업자들이 세운 프랑스의 비영리 재단에서 운영

Documentations

RFC 1034
DOMAIN NAMES - CONCEPTS AND FACILITIES
https://www.rfc-editor.org/rfc/rfc1034
RFC 1035
DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
https://www.rfc-editor.org/rfc/rfc1035

Favorite site

Online Tools