DNS8分で読める•日本語 Edition100% クライアントサイド実行

DNSの仕組みとネームサーバーの動作原理を徹底解説

ドメインネームシステムの階層的名前解決、ルートサーバー、A/AAAA/MX/TXTレコード、およびDNS-over-HTTPS (DoH)の暗号化を解説。

Curious-Techie Engineering Team認証著者

Web Protocols & Security Architecture Research

公開日: 2026年1月15日

•

更新日: 2026年9月1日

•8分で読める

準拠仕様:RFC 9110(IETF)

査読者: Curious-Techie Architecture Peer Review Group

主要な疑問 • 即時アーキテクチャ回答

DNSの仕組みとネームサーバーの動作原理を徹底解説

直接の回答

DNSの仕組みとネームサーバーの動作原理を徹底解説

ドメインネームシステムの階層的名前解決、ルートサーバー、A/AAAA/MX/TXTレコード、およびDNS-over-HTTPS (DoH)の暗号化を解説。

アーキテクチャの要点:

DNSは人間が読みやすいドメイン名を機械がルーティング可能なIPアドレス（IPv4/IPv6）へ変換します。
名前解決は、リカーシブリゾルバ → ルートサーバー → TLDサーバー → 権威DNSサーバーの階層構造で行われます。
主要レコードには A (IPv4)、AAAA (IPv6)、CNAME (別名)、MX (メール)、TXT (認証)があります。

標準規格ソース: Curious-Techie Architectural Specification & RFC Standards✓ 技術アーキテクチャ検証済み

TL;DR — 設計・エンジニアリングの要点

DNSは人間が読みやすいドメイン名を機械がルーティング可能なIPアドレス（IPv4/IPv6）へ変換します。
名前解決は、リカーシブリゾルバ → ルートサーバー → TLDサーバー → 権威DNSサーバーの階層構造で行われます。
主要レコードには A (IPv4)、AAAA (IPv6)、CNAME (別名)、MX (メール)、TXT (認証)があります。
現代のDNSは、盗聴を防ぐために DoH (RFC 8484) や DoT (RFC 7858) を用いて通信を暗号化します。

// 基本概念

中核概念とアーキテクチャ構造

Recursive Resolver

Resolver

The server (often ISP or public like 1.1.1.1 / 8.8.8.8) that iteratively queries the DNS hierarchy on behalf of the client.

Root Nameservers

Infrastructure

13 root server IP identities (managed by IANA/ICANN) at the pinnacle of the DNS hierarchy serving root zone hints.

TLD Nameserver

Hierarchy

Maintains delegations for specific domain extensions (.com, .org, .dev, .io) and points to authoritative nameservers.

Authoritative Nameserver

Authority

The final destination holding master zone files with definitive DNS records for a domain.

Time-to-Live (TTL)

Caching

32-bit unsigned integer specifying seconds a record may be cached before re-querying authoritative sources.

DNSSEC

Security

Cryptographic authentication of DNS responses using asymmetric keys (KSK, ZSK) to eliminate spoofing.

処理プロセス • 実行シーケンス

DNSの仕組みとネームサーバーの動作原理を徹底解説の動作原理と仕組み

直接の回答:

When a browser requests a domain, the local operating system stub resolver checks local memory and hosts files. If uncached, it dispatches a recursive query over UDP port 53. The recursive resolver systematically walks down the hierarchical tree: first querying a root nameserver for the TLD delegation, then querying the TLD nameserver for the authoritative delegation, and finally querying the authoritative server for the exact record.

Local Cache Check

Browser checks internal DNS cache, OS socket cache (e.g. systemd-resolved), and hosts file.

getaddrinfo("curious-techie.com", NULL, &hints, &res);

Recursive Resolver Query

The OS dispatches a recursive query to configured resolvers (e.g., 1.1.1.1 or internal VPC resolver).

dig +trace curious-techie.com

Root Hints Query

Resolver contacts a Root Nameserver (.); receives referral NS records for the .com TLD.

;; Query: curious-techie.com A
;; Referral to: a.gtld-servers.net.

TLD Nameserver Query

Resolver queries TLD nameserver for .com; receives authoritative NS records and glue records.

;; NS Delegation: ns1.curious-techie.com. (Glue: 198.51.100.53)

Authoritative Record Retrieval

Resolver queries authoritative nameserver directly; receives authoritative A/AAAA record with TTL.

curious-techie.com. 300 IN A 198.51.100.1

Response & Client Cache

Resolver caches the answer for 300 seconds and returns IP to browser; TCP handshake begins.

Connect to 198.51.100.1:443 -> SYN / SYN-ACK

実装コード例 • ベストプラクティス

DNSの仕組みとネームサーバーの動作原理を徹底解説の実務における実装方法

Querying DNS Records via dig Command

bash

# Query IPv4 Address (A Record)
dig +noall +answer curious-techie.com A

# Query Mail Exchange (MX Record) with Priority
dig +noall +answer curious-techie.com MX

# Trace Complete Iterative Resolution Path
dig +trace curious-techie.com

# Inspect Authoritative SOA Serial and Timers
dig curious-techie.com SOA

エンジニアリング詳細: The dig (Domain Information Grok) utility sends raw DNS query packets and displays flags, answer sections, and TTL counters.

Configuring BIND Zone File Syntax (RFC 1035)

zonefile

$TTL 3600
@       IN  SOA ns1.example.com. admin.example.com. (
                2026100501 ; Serial YYYYMMDDNN
                7200       ; Refresh (2h)
                3600       ; Retry (1h)
                1209600    ; Expire (2w)
                300        ; Negative Cache TTL (5m)
)
; Nameservers
@       IN  NS  ns1.example.com.
@       IN  NS  ns2.example.com.

; Host Records
@       IN  A     198.51.100.1
@       IN  AAAA  2001:db8::1
www     IN  CNAME curious-techie.com.

; Email Verification
@       IN  MX 10 mail.example.com.
@       IN  TXT   "v=spf1 include:_spf.example.com ~all"

エンジニアリング詳細: Standard RFC zone syntax declaring Start of Authority (SOA), nameservers, IPv4/IPv6 address records, CNAME aliases, and SPF text records.

本番環境アーキテクチャ • 実用ケース

本番環境でのDNSの仕組みとネームサーバーの動作原理を徹底解説の適用理由と構成

Global CDN Anycast Routing

Cloudflare / AWS CloudFront routing users to nearest edge point-of-presence (PoP).

GeoDNS and Anycast BGP announce identical IP addresses from hundreds of locations; resolvers receive localized routes.

Zero-Downtime Blue/Green Deployments

Migrating production traffic between Kubernetes clusters across cloud providers.

Lower DNS TTL to 60 seconds 48 hours prior to migration; adjust Weighted CNAME records to gradually shift percentages.

Email Deliverability & Anti-Spoofing

Preventing phishing domains from impersonating corporate transactional emails.

Publishing strict SPF, DKIM (public key TXT record), and DMARC (p=reject) policy records at domain apex.

アンチパターンと回避策

DNSの仕組みとネームサーバーの動作原理を徹底解説でよくある設計上の過ちと誤解

アンチパターン: Placing a CNAME record at domain apex (@ root domain)

影響: Violates RFC 1034 section 3.6.2; breaks MX, NS, and SOA records on apex domain.

推奨される修正策: Use ALIAS / ANAME record virtualization or native Apex flattened routing provided by modern DNS providers.

アンチパターン: Modifying production DNS records with an 86400s (24h) TTL active

影響: Users stay routed to decommissioned backends for up to 24 hours due to aggressive downstream caching.

推奨される修正策: Pre-lower TTL to 300 seconds at least 24 hours before planned infrastructure maintenance.

アンチパターン: Failing to increment SOA serial number after editing zone records

影響: Secondary slave nameservers fail to detect zone changes; zone transfer is never initiated.

推奨される修正策: Always increment the 10-digit SOA serial (format: YYYYMMDDNN) with every zone edit.

脅威モデル分析 • 攻撃ベクトル

DNSの仕組みとネームサーバーの動作原理を徹底解説のセキュリティ上のリスクと脆弱性

DNS Cache Poisoning (Kaminsky Attack)

CWE-348 / Kaminsky Flaw

脆弱性: Attacker injects forged answers into resolver cache before authoritative response arrives.

防御・緩和策: Implement UDP source port randomization and DNSSEC cryptographic signature validation.

DNS Amplification DDoS

OWASP Top 10 Denial of Service

脆弱性: Open resolvers amplify small spoofed UDP requests into massive response floods targeting victim IPs.

防御・緩和策: Disable open recursive resolver access on public IPs; configure Response Rate Limiting (RRL).

Subdomain Takeover

CWE-284 Improper Access Control

脆弱性: Dangling CNAME record points to abandoned cloud storage bucket or decommissioned SaaS service.

防御・緩和策: Audit DNS records continuously; remove CNAME targets immediately upon resource decommissioning.

診断ワークフロー • 根本原因解決

DNSの仕組みとネームサーバーの動作原理を徹底解説のエラー診断とトラブルシューティング

発生症状とエラーの兆候: NXDOMAIN returned for valid domain in production

根本原因の技術的分析:

Typo in authoritative zone file
Registrar nameservers pointing to wrong NS records
Negative caching in local resolver

本番環境検証済み修正手順: Query authoritative server directly with `dig @ns1.yournameserver.com domain.com A` to bypass intermediary resolver caching.

発生症状とエラーの兆候: SERVFAIL returned intermittently across global regions

根本原因の技術的分析:

DNSSEC validation failure due to expired RRSIG key
Authoritative nameservers timing out or firewall dropping UDP 53
Zone transfer failure

本番環境検証済み修正手順: Validate DNSSEC chain of trust using `delv domain.com` or online DNSViz to detect broken delegation signers.

発生症状とエラーの兆候: DNS changes visible locally but not globally (Propagation Lag)

根本原因の技術的分析:

Downstream public resolvers honoring prior high TTL cache duration
Stale OS local resolver cache

本番環境検証済み修正手順: Flush local resolver cache (`ipconfig /flushdns` or `resolvectl flush-caches`); query authoritative servers directly.

技術ナレッジベース • 即時回答

DNSの仕組みとネームサーバーの動作原理を徹底解説に関するよくある質問

Q:What is the difference between an Authoritative and a Recursive DNS server?

直接の回答:An Authoritative server holds the definitive master records for a specific domain. A Recursive server acts as an intermediary, querying authoritative servers across the global hierarchy on behalf of client devices and caching the answers.

Authoritative servers (e.g. Cloudflare, Route53, BIND) answer "Who owns this domain and what is their IP?". Recursive resolvers (e.g. 1.1.1.1, Google 8.8.8.8, ISP resolvers) answer the client request by iteratively walking the tree from root hints downward.

Q:Why can’t a CNAME record co-exist with other record types at the domain root?

直接の回答:RFC 1034 section 3.6.2 dictates that if a CNAME record exists at a node, no other data records may exist for that node. Placing a CNAME at apex eliminates mandatory SOA and NS records.

Because the root apex (@) requires an SOA record and at least two NS records for zone validity, an RFC-compliant nameserver cannot bind a CNAME to the apex. Modern DNS hosts resolve this via proprietary ALIAS/ANAME record synthetic flattening.

Q:Does DNS use UDP or TCP port 53?

直接の回答:DNS uses UDP port 53 for standard queries under 512 bytes (or up to 4096 bytes with EDNS0) to minimize latency. It falls back to TCP port 53 for truncated payloads (TC flag set), zone transfers (AXFR), and large DNSSEC responses.

Standard queries use stateless UDP to avoid connection handshake round trips. If an answer exceeds the buffer size, the server sets the TC (Truncation) bit in the header, prompting the client to retry over TCP port 53.

セクション 12 • 対話型ユーティリティ

用語集

A Record

Address record mapping a fully qualified hostname to a 32-bit IPv4 address.

AAAA Record

Quad-A record mapping a hostname to a 128-bit IPv6 address.

CNAME

Canonical Name record aliasing one hostname to another canonical hostname.

MX Record

Mail Exchange record specifying SMTP mail servers and numerical priority values.

SOA Record

Start of Authority record containing primary nameserver, admin email, serial number, and zone timers.

Authoritative Sourcing & Verification

References & Primary Sources

Every source below directly substantiates technical statements and protocol behaviors explained in DNSの仕組みとネームサーバーの動作原理を徹底解説. Curious-Techie prioritizes official Internet standards (IETF RFCs, W3C Recommendations, WHATWG specifications) and established security bodies (OWASP, NIST). Zero sponsored or secondary links.

[1]IETFPrimary SpecificationRFC 1034 • Section 3 & 4
Verified Primary Source
RFC 1034: Domain Names — Concepts and Facilities
Technical Claim Supported:
Establishes the hierarchical distributed domain name space, authoritative name servers, root zone topology, and zone delegations.
Source URI: https://datatracker.ietf.org/doc/html/rfc1034
[2]IETFPrimary SpecificationRFC 1035 • Section 3.2 (Resource Records)
Verified Primary Source
RFC 1035: Domain Names — Implementation and Specification
Technical Claim Supported:
Defines standard DNS Resource Record wire structures (A, CNAME, MX, NS, PTR, SOA) and port 53 UDP/TCP protocol formats.
Source URI: https://datatracker.ietf.org/doc/html/rfc1035
[3]IETFPrimary SpecificationRFC 8484 • Section 3 & 4
Verified Primary Source
RFC 8484: DNS Queries over HTTPS (DoH)
Technical Claim Supported:
Standardizes encrypted DNS query transmission inside HTTP/2 and HTTP/3 HTTPS streams to prevent ISP eavesdropping and on-path manipulation.
Source URI: https://datatracker.ietf.org/doc/html/rfc8484

Semantic Internal Links (GEO)

DNSの仕組みとネームサーバーの動作原理を徹底解説

TL;DR — 設計・エンジニアリングの要点

中核概念とアーキテクチャ構造

Recursive Resolver

Root Nameservers

TLD Nameserver

Authoritative Nameserver

Time-to-Live (TTL)

DNSSEC

DNSの仕組みとネームサーバーの動作原理を徹底解説の動作原理と仕組み

Local Cache Check

Recursive Resolver Query

Root Hints Query

TLD Nameserver Query

Authoritative Record Retrieval

Response & Client Cache

DNSの仕組みとネームサーバーの動作原理を徹底解説の実務における実装方法

Querying DNS Records via dig Command

Configuring BIND Zone File Syntax (RFC 1035)

本番環境でのDNSの仕組みとネームサーバーの動作原理を徹底解説の適用理由と構成

Cloudflare / AWS CloudFront routing users to nearest edge point-of-presence (PoP).

Migrating production traffic between Kubernetes clusters across cloud providers.

Preventing phishing domains from impersonating corporate transactional emails.

DNSの仕組みとネームサーバーの動作原理を徹底解説でよくある設計上の過ちと誤解

DNSの仕組みとネームサーバーの動作原理を徹底解説のセキュリティ上のリスクと脆弱性

DNS Cache Poisoning (Kaminsky Attack)

DNS Amplification DDoS

Subdomain Takeover

DNSの仕組みとネームサーバーの動作原理を徹底解説のエラー診断とトラブルシューティング

発生症状とエラーの兆候: NXDOMAIN returned for valid domain in production

発生症状とエラーの兆候: SERVFAIL returned intermittently across global regions

発生症状とエラーの兆候: DNS changes visible locally but not globally (Propagation Lag)

DNSの仕組みとネームサーバーの動作原理を徹底解説に関するよくある質問

Q:What is the difference between an Authoritative and a Recursive DNS server?

Q:Why can’t a CNAME record co-exist with other record types at the domain root?

Q:Does DNS use UDP or TCP port 53?

関連概念＆詳細解説

おすすめの関連開発者ツール

Test & Verify with DNS Lookup

Test & Verify with WHOIS Lookup

Test & Verify with Domain Intelligence

Test & Verify with IP Address Checker

面接対策Q&A（実務スキル評価）

Q: How does DNS over HTTPS (DoH) prevent ISP snooping?

Q: What is a DNS Glue Record?

実践ハンズオン診断ラボ

Interactive DNS Record Lookup Lab

Domain Intelligence & Security Audit

用語集

References & Primary Sources

関連技術エコシステムと次の学習ステップ

おすすめの関連開発者ツール

DNS Lookup & Propagation Tool

WHOIS & RDAP Domain Intelligence

関連技術解説記事

DNS vs DNS-over-HTTPS (DoH): Privacy & Security

Troubleshooting: DNS Returns NXDOMAIN Error

関連する技術Q&A

What Happens When a DNS TTL Expires?

Can a CNAME Record Point to an IP Address?

Why Can't a CNAME Record Coexist With Other Records at the Zone Apex?

開発者向け規格・仕様リファレンス

DNS Resource Records Reference Matrix

DNS Response Codes (RCODEs) Reference

次のステップへ進む

DNS Resolution & Propagation Lab