example.comだけで、なぜ相手に届く？

「60歳から始めるホワイトハッカーへの道」第5回です。


前回はTCP/IPについて勉強し、MacBook Proのターミナルから、 

ping -c 4 example.com

を実行しました。


ここで一つ疑問が出てきました。

第2回では、ネットワーク上の通信相手を識別するためにIPアドレスが使われると勉強しました。

ところが私はIPアドレスを入力していません。

入力したのは、 

example.com

だけです。


なぜこれだけで相手が分かるんだ？

ここで登場するのがDNSです。



DNSはインターネットの電話帳？

DNSはDomain Name System（ドメイン・ネーム・システム）の略です。

人間にとって、Webサイトを見るたびにIPアドレスを覚えて入力するのは大変です。


そこで、 

example.com
 ↓ 
DNS
 ↓ 
IPアドレス

というように、私たちが覚えやすいドメイン名を、コンピューターが通信に利用できるIPアドレスへ結び付ける仕組みがあります。


よく「DNSはインターネットの電話帳」と説明されます。

名前から電話番号を探す電話帳のように、ドメイン名から通信先を探す、と考えると初心者の私にもイメージしやすいです。



MacでDNSを実際に確認してみる

説明を読むだけでは面白くないので、今回もMacBook Proのターミナルを使って確認してみます。

まず、 

nslookup example.com

を実行してみます。


MacBook-Pro ~ % nslookup example.com

Server: 2404:7a86:1cc6:4a00:1e7c:98ff:fecb:bca0

Address: 2404:7a86:1cc6:4a00:1e7c:98ff:fecb:bca0#53


Non-authoritative answer:

Name: example.com

Address: 172.66.147.243

Name: example.com

Address: 104.20.23.154


結果にはDNSサーバーの情報や、example.comに対応するアドレスなどが表示されます。

普段ブラウザでWebサイトを開いている裏側で、このように名前とIPアドレスが結び付けられているわけです。



digというコマンドも使ってみる

DNSを調べているとdigというコマンドもよく登場します。

Macのターミナルから、 

dig example.com

と実行してみます。


MacBook-Pro ~ % dig example.com


; <<>> DiG 9.10.6 <<>> example.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28254

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1


;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;example.com. IN A


;; ANSWER SECTION:

example.com. 94 IN A 172.66.147.243

example.com. 94 IN A 104.20.23.154


;; Query time: 14 msec

;; SERVER: 2404:7a86:1cc6:4a00:1e7c:98ff:fecb:bca0#53(2404:7a86:1cc6:4a00:1e7c:98ff:fecb:bca0)

;; WHEN: Mon Sep 28 11:02:21 JST 2026

;; MSG SIZE  rcvd: 72


今度は、かなり詳しい情報が表示されます。

最初に見た感想は、


「また知らない英語がいっぱい出てきた（笑）」


でした。

でも今の段階では全部理解する必要はありません。

まずはANSWER SECTIONを探してみます。

そこを見ると、問い合わせたドメインに対してDNSからどのような回答が返ってきたのか確認できます。



自分のRailsブログを実際にDNSで調べてみる

ここまで調べて、一つ思いつきました。

私はRailsでこの「rails-fumiblog」を作り、Herokuで公開しています。


それなら自分のブログをDNSで調べてみればいい。

MacBook Proのターミナルから実際に、 

dig www.rails-fumiblog.com

を実行してみました。


すると、ANSWER SECTIONにこんな結果が表示されました。 

www.rails-fumiblog.com. 
CNAME 
cellular-antlion-....herokudns.com. 

herokudns.com. 
A 13.248.xxx.xxx 
A 3.33.xxx.xxx 
A 76.223.xxx.xxx 
A 15.197.xxx.xxx

※読みやすくするため一部を省略しています。


おお、Herokuが出てきた！

これは自分で作ったブログなので、Herokuを使って公開していることは当然知っています。

でもブラウザから、 

https://www.rails-fumiblog.com

へアクセスするとき、その裏側でDNSがどのように関係しているのかを意識したことはありませんでした。


CNAMEって何だ？

結果を見ると、 

CNAME

という、また知らない言葉が出てきました（笑）。

CNAMEは、あるホスト名を別のホスト名の別名として対応付けるDNSレコードです。

今回の結果では、 

www.rails-fumiblog.com
 ↓ 
CNAME
 ↓ 
○○○.herokudns.com

となっています。


つまり、自分のブログで使っているwww.rails-fumiblog.comという名前から、Heroku側のDNS名へつながっていることを実際に確認できました。



今度は「A」という文字が出てきた

さらにHeroku側の名前を見ると、 

A 13.248.xxx.xxx 
A 3.33.xxx.xxx 
A 76.223.xxx.xxx 
A 15.197.xxx.xxx

と表示されています。


このAレコードは、ホスト名とIPv4アドレスを対応付けるDNSレコードです。

ここで、第2回で勉強したIPアドレスにつながりました。 

www.rails-fumiblog.com
 ↓ 
DNS
 ↓ 
HerokuのDNS名
 ↓ 
IPv4アドレス

こうやって自分のブログを題材にすると、DNSが単なる教科書の話ではなくなってきます。



Query timeは160msec

今回の結果には、 

Query time: 160 msec

とも表示されました。

ちなみに、apple(www.apple.com)は、14msec !!!


DNSへの問い合わせに対して、今回の実行では160ミリ秒で回答が返ってきたということです。

普段ブラウザでブログを開いているときには、こんな処理を意識することはありません。

でも裏側では、名前から通信先を探すための仕組みが動いている。


ホワイトハッカーの勉強を始めなければ、自分のブログをこんな視点で見ることはなかったと思います。



5年間使ってきたRailsが教材になってきた

最初はホワイトハッカーについて何も分からない状態から始めました。

ところが勉強を進めるにつれて、 

rails-fumiblog
 ↓ 
ドメイン
 ↓ 
DNS
 ↓ 
Heroku
 ↓ 
IPアドレス
 ↓ 
HTTPS
 ↓ 
Rails

という流れが少しずつ見えてきました。

これまで5年間使ってきたRailsそのものが、ネットワークやセキュリティを勉強するための教材になりそうです。



DNSサーバーはどうやって答えを知っている？

ここでまた疑問です。

DNSサーバーは世界中すべてのドメインとIPアドレスを、一台のコンピューターで管理しているのでしょうか？


もちろん、そんな単純な仕組みではありません。

DNSでは大まかに、 

自分のMac
 ↓ 
DNSリゾルバー
 ↓ 
ルートネームサーバー
 ↓ 
TLDネームサーバー（.comなど）
 ↓ 
権威DNSサーバー
 ↓ 
必要なDNS情報

というように、役割の違うDNSサーバーが協力して情報を探します。


さらに一度調べた情報をキャッシュとして一定時間保存することで、毎回最初から問い合わせなくても済む仕組みがあります。

このあたりは少し難しくなってきたので、今は「DNSは一台の巨大な電話帳ではない」と覚えておくことにします。



DNSとセキュリティは関係ある？

ホワイトハッカーを目指して勉強しているので、気になるのはやはりセキュリティとの関係です。


DNSは「この名前なら、こちらへ通信してください」という重要な情報を扱っています。

ということは、その情報が偽物だったらどうなるのでしょう？


本物だと思ってアクセスしたのに、別の場所へ誘導される可能性も考えられます。

調べてみると、

DNSキャッシュポイズニング

DNSスプーフィング

DNSSECなど

また知らない言葉が出てきました。


いきなり攻撃方法へ進むのではなく、まず正常なDNSの仕組みを理解してから、後の回で安全な学習環境を使ってセキュリティについて勉強していこうと思います。



ここまでの知識がつながってきた

ドメイン名 example.com
 ↓ 
DNS
 ↓ 
IPアドレスを調べる
 ↓ 
通信相手が分かる
 ↓ 
TCP/IPで通信
 ↓ 
ポート番号でサービスを区別

IPアドレス、ポート番号、TCP/IP、DNS。

一つずつ勉強したときには別々の言葉でしたが、少しずつ一本につながってきました。

これが今回のシリーズで一番面白いところかもしれません。



今回覚えたこと

  • DNSはドメイン名とIPアドレスを結び付ける仕組み
  • DNSは「インターネットの電話帳」と例えられる
  • Macではnslookupやdigを使ってDNS情報を確認できる
  • DNSには複数の種類のサーバーが関係している
  • DNSにはキャッシュという仕組みがある
  • DNSはセキュリティを学ぶ上でも重要


次回はHTTPとHTTPSへ

DNSによって通信先のIPアドレスが分かりました。

では、その相手とWebブラウザはどのように会話しているのでしょう？

ブラウザを見ると、 

https://www.rails-fumiblog.com

の先頭にはhttpsがあります。


第3回では80番がHTTP、443番がHTTPSと勉強しました。

でも、HTTPとHTTPSは具体的に何が違うのでしょう？


次回は「HTTPとHTTPSの違いとは？自分のRailsブログへの通信をMacから見てみる」をテーマに勉強します。