DNSはrequestとresponseが同じ系形式のUDPパケットでやり取りされるプロトコルである。 で、実はdigがdnsプロトコルのパケット内容を忠実に再現しているのです。だから、これマスターするDNSがほぼ分かったということになります。
関連ドキュメント
ハンズオンの ハンズオンを紹介しているやつ rfsの読み方を説明している資料 ルートDNSの場所 digコマンドでの遊び方 digでの遊び方 dnsの全体像 dig関連
digの基本的なオプション +noedns : tcpで問い合わせ +norec : 非再起問い合わせを強制する。
qr : queryレスポンス rd : recursion desired : 再起問い合わせ要求。（Set by the sender of the request if the server should attempt to resolve the query recursively if it does not have an answer readily available.） ra : recursion available : 再起問い合わせ対応が可能か？（Set by the server to indicate whether or not recursive queries are allowed.） 基本的に、名前解決と言ったら8.8.8.8などのDNSキャッシュサーバが再起問い合わが実行して返してくれる。 しかし、権威DNSは再起問い合わせができないからね。 rdがついてもraがなかったら非再起問い合わせができないということになります。いくつかみてみましょうか？
いくつかDNSレコードを送ってみましょうか？
dig @1.1.1.1 +norec blog.ingenboy.com
; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @1.1.1.1 +norec blog.ingenboy.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21079
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;blog.ingenboy.com. IN A
;; Query time: 1 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Thu Aug 22 09:05:47 JST 2024
;; MSG SIZE rcvd: 46
+norecをつけたのでDNSサーバは非再起問い合わせで名前解決ができません。そのため、answer sectionがないわけですね。 つまり、名前解決できなかったわけです。それにもかかわらずGot answerって書いているのはタチが悪いよね。
dig @1.1.1.1 blog.ingenboy.com
; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @1.1.1.1 blog.ingenboy.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3244
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;blog.ingenboy.com. IN A
;; ANSWER SECTION:
blog.ingenboy.com. 3600 IN A 162.43.53.234
;; Query time: 219 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Thu Aug 22 09:07:13 JST 2024
;; MSG SIZE rcvd: 62
+norecを解除するといい感じで行けているのがわかります。 rdがついているのでrecursion desiredになっていることがわかります。 次、回されるのみてみましょうか。
dig @ns02.yahoo.co.jp long-blitzv2.g.yahoo.co.jp
; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @ns02.yahoo.co.jp long-blitzv2.g.yahoo.co.jp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3142
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8952e39cfce24b450100000066c6823b52e13689cdd80cac (good)
;; QUESTION SECTION:
;long-blitzv2.g.yahoo.co.jp. IN A
;; AUTHORITY SECTION:
g.yahoo.co.jp. 900 IN NS gns11.yahoo.co.jp.
g.yahoo.co.jp. 900 IN NS gns01.yahoo.co.jp.
;; Query time: 7 msec
;; SERVER: 118.151.254.149#53(ns02.yahoo.co.jp) (UDP)
;; WHEN: Thu Aug 22 09:11:39 JST 2024
;; MSG SIZE rcvd: 134
はい、Authority Sectionが出てきましたね。 これ何かというと、（ An list of name servers (NS records), used for resolving queries recursively.） ということです。Answer sectionがない代わりに、Authority sectionがあるわけです。で、こいつに聞けよーって話。 long-blitzv2.g.yahoo.co.jpは*.g.yahoo.co.jpの形になっていますね。 つまり、g.yahoo.co.jpのNSはgns11.yahoo.co.jpが持っていると言っています。聞いてみましょう ちなみに、こいつはraがついていないので、再起問い合わせができないサーバでした。
dig @gns11.yahoo.co.jp long-blitzv2.g.yahoo.co.jp の結果
dig @gns11.yahoo.co.jp long-blitzv2.g.yahoo.co.jp
; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @gns11.yahoo.co.jp long-blitzv2.g.yahoo.co.jp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16161
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;long-blitzv2.g.yahoo.co.jp. IN A
;; ANSWER SECTION:
long-blitzv2.g.yahoo.co.jp. 60 IN A 183.79.218.174
;; Query time: 1 msec
;; SERVER: 124.83.255.36#53(gns11.yahoo.co.jp) (UDP)
;; WHEN: Thu Aug 22 09:27:42 JST 2024
;; MSG SIZE rcvd: 71
なんと、AAがついています。これはAuthoritative Answerです。 つまり、権威からの返却です。すごい、、、。で、AレコードでIPアドレスが帰ってきているね、、、すごい！
ちなみに、広告に使われるdomainを名前解決してみると、
dig ads.yahoo.co.jp
; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> ads.yahoo.co.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58315
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ads.yahoo.co.jp. IN A
;; ANSWER SECTION:
ads.yahoo.co.jp. 146 IN CNAME long-blitzv2.g.yahoo.co.jp.
long-blitzv2.g.yahoo.co.jp. 57 IN A 118.151.253.212
;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Aug 22 09:31:42 JST 2024
;; MSG SIZE rcvd: 89
ちな、8.8.8.8に+norecでクエリ出すと上手くいかないことがある。
dig @8.8.8.8 +norec ads-search.yahooapis.jp
; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @8.8.8.8 +norec ads-search.yahooapis.jp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23454
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ads-search.yahooapis.jp. IN A
;; Query time: 10 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Thu Aug 22 09:36:44 JST 2024
;; MSG SIZE rcvd: 52
norecをつけないと上手くいく。そして、内容が時事刻々と変わっていくのも面白いね。はい。 118.151.253.211 -> 118.151.253.212 -> 183.79.218.174 って感じでね。
さてHTTPの話に戻るのだが、HTTPホストヘッダはなんのためにあるのか？ という話ですが、、chatgptと昨日お話しした結果をここにまとめておきますね。
DNSの名前解決について質問させてください。
名前解決でcnameが帰ってきた時、サーバのエンドポイントにアクセスされるhttpリクエストのホストヘッダーには名前解決される前のドメインが入っているという認識でいいですか？
＞はい、その通りです。CNAMEレコードはドメイン名を別のドメイン名にマッピングしますが、実際のHTTPリクエストでは、クライアントが最初に指定したドメイン名がホストヘッダーに含まれます。
つまり、クライアントがexample.comというドメインでリクエストを送信すると、DNSによってexample.comがexample.netに解決されてサーバに到達しても、HTTPリクエストのホストヘッダーには依然としてexample.comが含まれています。サーバ側でexample.netのリクエストを受け取ると、ホストヘッダーの値example.comに基づいて処理を行うことになります。
＞ということは、サーバ側のエンドポイントでは、一つの物理的なサーバで複数のドメインを処理できるという認識であっていますか？
＞はい、その認識で正しいです。１つの物理サーバで複数のドメインを処理できるのは、ホストヘッダーによるバーチャルホスティングのおかげです。サーバは、受け取ったリクエストのホストヘッダーをみて、どのドメインに対するリクエストかを判断し、それに応じた処理を行います。これにより、一つのサーバで複数のドメインやサイトを管理することができます。
ということだ、名前解決の結果、ip addressが提供されるわけだ。そして、そのIPにアクセスをしにいくわけだ。そして、ホストヘッダをつけてリクエストをするわけなので、nginxなどのwebサーバはホストヘッダによってエンドポイントを識別できるわけだ。楽しいね。
最後にDNSのレコード一覧見てみますか。 Aレコード：ドメイン名のIPを返す AAAAレコード：ドメイン名のIPv6を返す cnameレコード：ドメインのエイリアスを作成するために使用されます。用途は、入り口一つ、名前たくさん、を可能にすること。 NSレコード：名前解決先を教えてくれるレコード。このドメインに関しては、この人に聞いてくださいね、みたいなことができるようになるって話。
dig highpon.com mx
でmxレコード。
lymDPG4Q2915X:github-to-slack ly-2045409$ dig +norec @8.8.8.8 ingenboy.com
; «» DiG 9.10.6 «» +norec @8.8.8.8 ingenboy.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -»HEADER«- opcode: QUERY, status: SERVFAIL, id: 64451 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;ingenboy.com. IN A
;; Query time: 15 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Aug 08 19:44:07 JST 2024 ;; MSG SIZE rcvd: 41
最後のSERVERは、DNSを解決してくれたサーバ