TL;DR
- FQDN を名前解決した IP アドレスをブラウザに入力してもアクセスできないことが多い
- その理由のほとんどは CDN、もしくは VPS などのサーバー環境で複数の FQDN が同じ IP アドレスに割り当てられているため
- 典型的な説明はそのままでいいんだけれども、”では簡単に試してみましょう” がやりづらくなっています
はじめに
某社のインターンの準備を眺めていたのですが、名前解決に関する典型的な説明が今となっては少しわかりづらいというか、そのまんまでは理解ができない状況にあるなぁと思ったので書いてみた次第です。
FQDN (example.co.jp とか example.com とか) にアクセスするためには、まずは名前解決をして、その結果得られた IP アドレスにアクセスする、というのが一般的な説明かと思います。
ただ、実際にブラウザにその IP アドレスを入力したところで、アクセスできないサイトが大多数なのではないでしょうか。
試してみる
まずは試してみましょう。
ブラウザでもいいのですが、画像が多くなっちゃうので PowerShell を使ってみます。
最初に、名前解決からですね。
> Resolve-DnsName www.microsoft.com
Name Type TTL Section NameHost
---- ---- --- ------- --------
www.microsoft.com CNAME 474 Answer www.microsoft.com-c-3.edgekey.net
www.microsoft.com-c-3.edgekey. CNAME 474 Answer www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
net
www.microsoft.com-c-3.edgekey. CNAME 474 Answer e13678.dscb.akamaiedge.net
net.globalredir.akadns.net
Name : e13678.dscb.akamaiedge.net
QueryType : AAAA
TTL : 5
Section : Answer
IP6Address : 2600:140b:1c00:1491::356e
Name : e13678.dscb.akamaiedge.net
QueryType : AAAA
TTL : 5
Section : Answer
IP6Address : 2600:140b:1c00:14a6::356e
Name : e13678.dscb.akamaiedge.net
QueryType : A
TTL : 15
Section : Answer
IP4Address : 23.221.141.222
なんかいろいろ出てきましたが、とりあえず 23.221.141.222 に通信すればよさそうな気はします。
> Invoke-WebRequest http://23.221.141.222
Invoke-WebRequest:
Invalid URL
Invalid URL
The requested URL "[no URL]", is invalid.
Reference&
https&
なんかダメそうですね。
HTTPS も試してみます。
> Invoke-WebRequest https://23.221.141.222
Invoke-WebRequest: The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch
ちょっと雰囲気が変わりましたが、まぁダメそうです。
一旦先に答えを示した後に、細かいところを説明していきます。
ここでは -Headers パラメーターを使って、Host ヘッダーを指定することで、200 OK、つまりアクセスできるようになりました。
> Invoke-WebRequest https://23.221.141.222 -Headers @{ "Host" = "www.microsoft.com" }
StatusCode : 200
StatusDescription : OK
Content :
!DOCTYPE html>"http://schemas.microsoft.com/CMSvNext"
xmlns:md="http://schemas.microsoft.com/mscom-data" lang="en-us"
xmlns="http://www.w3.org/1999/xhtml">…
なぜアクセスできないのか
“アクセスできないサイトが大多数なのでは” と書きましたが、その技術的な背景はいくつか考えられます。
- VPS (Virtual Private Server) などのサーバー環境では、1 つの IP アドレスに対して複数の FQDN が割り当てられていることが多い
- さくらの VPS などで見られますが、www.example.co.jp と www-test.example.co.jp を同じ IP アドレスに割り当てるようなケースです
- 中小企業だとこちらのパターンがたぶん多い
- CDN (Content Delivery Network) を利用しているサイトでは、どの FQDN に対するアクセスかに応じてバックエンドを振り分けている
- DDoS 対策や WAF、そもそもの Web サイトの負荷分散のために CDN を利用していることが多い
- 多くの大企業の Web サイトやコンシューマー向けサイトはほとんどこちらのパターンかと
どちらも結局ほぼ同じような理由なのですが、OSI モデルというところの L3 の IP アドレスベースでは、どの FQDN にアクセスするかがわからないため、エラーを吐いているようなものです。
L7 になると、HTTP ヘッダーの Host ヘッダーに FQDN が含まれているため、どの FQDN にアクセスするかがわかるので、それをもとにどうすればいいのかサーバー側で判断が可能、ということですね。
名前解決に関する説明は間違っているのか
じゃあ、”名前解決してその IP アドレスに通信する” という説明が間違っているかというと、そういうわけではありません。
上に書いてあるとおり、PC やスマートフォンは、指定された FQDN を名前解決し、その結果の IP アドレスは L3 ヘッダーに含まれています。
この部分は OS の担当する範囲ですね。
加えて、ブラウザーは指定された FQDN を L7 の HTTP ヘッダーの Host ヘッダーに含めて、サーバーにアクセスします。
この部分はブラウザーの担当する範囲です。
ということで、典型的な説明は間違っていないのですが、じゃあそれをブラウザを使って試してみましょう、という説明はもうほとんど成立しません、というのが現状です。
たまたまいくつか試してみて、以下のような状況があることは確認しています。
- ドムドムハンバーガー (domdomhamburger.com)
- Google (www.google.co.jp)
- Yahoo! JAPAN (www.yahoo.co.jp)
HTTPS で IP アドレスでアクセスするとエラー
余談ではあるのですが、FQDN を名前解決、ブラウザでテスト、を繰り返していると、まずは画面が赤くなるというか、証明書エラーが出ることが多いです。
これは、HTTPS 通信をする際に、サーバー側から証明書が提示されますが、それに IP アドレスを含んでいるケースはほとんどないからですね。
いくつかの Web サイトでは、それでもアクセスする、というやや危険な方法をとることで、そこから正式な Web サイトにリダイレクトしているケースも見られました。
まとめ
ということで、FQDN を名前解決した IP アドレスをブラウザに入力してもアクセスできない理由と、試してみた結果について書いてみました。
名前解決に関する典型的な説明は間違っていないものの、じゃあそれをうまく説明する方法は別途考えないと、従来からの説明では通用しないケースがほとんどだよ、ということでした。
Views: 0
