/12分で読めます

DNSとは?Domain Name Systemの仕組みを解説

Webサイトを開く、emailを送る、appを使う。そのたびにDNSは裏側で動いています。DNSはgoogle.comのような名前を、computerが通信に使うIP addressへ変換します。

DNSとは?

DNS、つまりDomain Name Systemは、internet全体に分散した命名systemです。人間が読みやすいdomain nameをIP addressへ変換します。

DNSがなければ、google.comのような名前ではなく、142.250.80.46のようなaddressを覚える必要があります。

DNSは1980年代にPaul Mockapetrisによって作られ、RFC 1034とRFC 1035で標準化されました。拡大するinternetに対応できなかった古いHOSTS.TXT方式を置き換えました。

DNSが存在する理由

DNSがあるのは、人間は名前を覚えやすく、networkは数値でtrafficをrouteするからです。DNSは次を提供します。

  • 人にやさしい名前 - IP addressではなくgithub.comと入力できます。
  • Indirection - domainはbookmarkやlinkを変えずに新しいserverへ向けられます。
  • Load balancing - 1つの名前を複数のIP addressへresolveできます。
  • Email routing - MX recordsがmail serverへemailの配送先を伝えます。
  • Domain verification - TXT recordsはservice、certificate、SPF、DKIM、DMARCでdomain ownershipを証明します。

DNS Resolutionの仕組み

BrowserがIP addressを必要とすると、recursive resolverがDNS hierarchyをたどって答えを探します。

You type: www.example.com

1. Browser cache
   If the answer is cached and not expired, use it.

2. Operating system cache
   The OS checks its DNS cache and hosts file.

3. Recursive resolver
   Your ISP resolver or a public resolver checks its cache.

4. Root name server
   Resolver asks: where are the .com servers?

5. TLD name server
   Resolver asks .com: where are example.com's nameservers?

6. Authoritative name server
   Resolver asks example.com's nameserver: what is www.example.com?

7. Answer
   Resolver caches the result and returns the IP address to your device.

DNSの階層構造

DNSは逆さまのtreeのように構成され、domain nameを右から左へ読んでいきます。

                    . (root)
                    |
           ---------------------
          .com       .org      .net       top-level domains
           |          |         |
       example    wikipedia   cloud      second-level domains
           |          |         |
         www         en        api       subdomains

Full domain: www.example.com.
The final dot represents the DNS root.
Level管理者
Root.ICANNとroot server operators
TLD.com, .org, .net, .thTop-level domain registries
Second-level domainexample.comregistrar経由のdomain owner
Subdomainwww, api, mailDNS recordsを通じたdomain owner

DNS Record Typesの解説

DNSは用途ごとに異なるrecord typeを保存します。

A      example.com.       93.184.216.34
AAAA   example.com.       2606:2800:220:1:248:1893:25c8:1946
CNAME  www.example.com.   example.com.
MX     example.com.       10 mail.example.com.
TXT    example.com.       "v=spf1 include:_spf.example.com ~all"
NS     example.com.       ns1.example.com.
Record目的
A名前をIPv4 addressへ対応付けるexample.com -> 93.184.216.34
AAAA名前をIPv6 addressへ対応付けるexample.com -> 2606:...
CNAME別の名前へのaliasを作るwww -> example.com
MXdomainのemail配送先を指定する10 mail.example.com
TXTverificationやemail security用のtextを保存するSPF, DKIM, DMARC, ownership checks
NSauthoritative nameserversを列挙するns1.example.com
SOAzone authorityとtiming dataを保存するserial, refresh, retry, expire, TTL
CAAcertificateを発行できるCAを制御するletsencrypt.org allowed

CNAMEの制限

CNAMEは同じnameにある他のrecordと共存できません。そのため多くのDNS providerはroot-domain hosting向けにALIASやANAME recordsを提供しています。

DNS CachingとTTL

DNS answerはlookupを速くするためにcacheされます。cache durationはTTL、つまりTime To Liveで制御され、secondsで指定されます。

  • 300秒のような短いTTLは、変更を早く反映したいときに役立ちます。
  • 3600秒や86400秒のような長いTTLは、DNS trafficを減らしspeedを改善します。
  • 計画的なmigration前には24-48時間前にTTLを下げ、変更が安定したら再度上げます。

DNS Propagation

DNS propagationとは、世界中のresolverで古いcached answersがexpireするまでにかかる時間です。

Change TypeTypical Timeメモ
A/AAAA update数分から48時間主に以前のTTLに依存します
Nameserver change24-72時間TLD-level NS recordsは長いTTLを持つことが多い
New subdomain数分から数時間通常は古いcacheがありません
MX update1-24時間移行中にemailが遅れる場合があります

DNS Security

従来のDNSはprivacyやauthenticationを前提に設計されていません。現代の拡張はsystemの異なる部分を改善します。

Without DNSSEC:
  Resolver asks: What is example.com?
  Attacker replies: It is 6.6.6.6
  Resolver has no built-in way to verify the answer.

With DNSSEC:
  Resolver checks cryptographic signatures.
  Fake answers fail validation and are rejected.
Technologyできることできないこと
DNSSECDNS recordsへ署名し、resolverがauthenticityを検証できるようにするDNS queryは暗号化しない
DoHDNS queryをport 443のHTTPSで送るDNSSECも使わない限りrecord署名は証明しない
DoTDNS queryをport 853のTLSで送るDNS trafficとして識別される可能性は残る

より良い保護には、DNSSECでauthenticityを高め、DoHまたはDoTで通信中のprivacyを高める組み合わせが有効です。

Public DNS Resolvers

ISP resolverの代わりにpublic resolverを使うこともできます。代表的な選択肢は次の通りです。

ProviderIPv4Features
Google8.8.8.8 / 8.8.4.4DNSSEC, DoH, DoT
Cloudflare1.1.1.1 / 1.0.0.1高速、privacy重視、DNSSEC, DoH, DoT
Quad99.9.9.9 / 149.112.112.112malicious domainsをblock、DNSSEC, DoH, DoT
OpenDNS208.67.222.222 / 208.67.220.220filtering optionsとDNSSEC

DNS問題のTroubleshooting

DNS問題があると、server自体は動いていてもdownしているように見えることがあります。よくある原因は次の通りです。

ProblemSymptomFix
Stale cacheDNS変更後も古いsiteが読み込まれるcacheをflushし、TTL expiryを待つ
Wrong nameserversdomainがresolveされないregistrarでNS recordsを確認する
Missing A/AAAA recordNXDOMAINまたはbrowser DNS errordomainまたはsubdomainのrecordsを追加する
Email not workingmessageがbounceする、または消えるMX, SPF, DKIM, DMARCを確認する
CNAME target wrongsiteが間違ったserviceを指すCNAME chainをtraceする

便利なDNS Commands

terminalからDNSをdebugするには、次のcommandsが便利です。

# nslookup
nslookup example.com
nslookup -type=MX example.com
nslookup example.com 8.8.8.8

# dig
dig example.com A
dig example.com MX
dig @8.8.8.8 example.com
dig +trace example.com
dig +short example.com

# Flush DNS cache on Windows
ipconfig /flushdns

DNS Recordsをすぐに検索

無料のDNS Checker toolで、任意のdomainのA、AAAA、CNAME、MX、TXT、NS、SOAなどのDNS recordsを確認できます。

DNS Checkerを試す

参考資料

  1. Mockapetris, P. (1987). RFC 1034 - Domain Names: Concepts and Facilities. https://datatracker.ietf.org/doc/html/rfc1034
  2. Mockapetris, P. (1987). RFC 1035 - Domain Names: Implementation and Specification. https://datatracker.ietf.org/doc/html/rfc1035
  3. Arends, R., et al. (2005). RFC 4033 - DNS Security Introduction and Requirements. https://datatracker.ietf.org/doc/html/rfc4033
  4. Hoffman, P. & McManus, P. (2018). RFC 8484 - DNS Queries over HTTPS (DoH). https://datatracker.ietf.org/doc/html/rfc8484
  5. ICANN. Root Server Technical Operations. https://root-servers.org/