テクノロジー|なぜDNSはいまだに学ぶのが難しいのか？

たとえばDNS。DNSは 使われており、インターネット上のすべてのウェブサイトで使われています。そして、かなり安定しています。多くの点で、30年前とまったく同じように機能しています。

しかし、DNSの問題を自信を持ってデバッグする方法を見つけ出すのに何年もかかりましたし、他のプログラマーがDNSの問題のデバッグで苦労しているのをたくさん見てきました。では、何が起こったのでしょうか？

DNS問題のトラブルシューティングを学ぶことがなぜ難しいかについて、いくつか考えてみました。

DNSがとても難しいというわけではありません。

そして、DNSの学習上の難しさを感じているのは私だけではありません！私は何年もの間、多くの経験豊富なプログラマーの友人とDNSの問題について議論してきました：

• ウェブサイトに簡単なDNSの変更を加えることを恐れません。
• または、DNSの仕組みの基本的な事実について混乱している場合
• あるいは、DNSの基本はよく知っているが、私のように知識の盲点がある場合。

では、もし私たちが皆DNSで同じ問題に直面しているとしたら、何が起こっているのでしょうか？なぜ多くの人にとってDNSの学習が難しいのでしょうか？

多くのシステムが隠されています

お使いのコンピューターでDNSリクエストを開始する場合、基本的なプロセスは次のようになります：

1. コンピューターは「リゾルバ」と呼ばれるサーバーにリクエストを出します。
2. リゾルバはそのキャッシュをチェックし、「権威ネームサーバ」と呼ばれる他の多くのサーバにリクエストを行います。

以下はその一部です：

• パーサーのキャッシュ。その中身は？
• コンピュータ上でDNSリクエストを行うためのライブラリコードはどれですか これらのオプションはすべて、わずかに動作が異なり、設定、キャッシュ方法、利用可能な機能などが異なります。例えば、musl DNSは 80 TCPをサポートしていませんでした。
• リゾルバと権威ネームサーバ間の対話。もし、リクエスト中に下流に照会たすべての権威ネームサーバーとその応答を正確に記録するトレースを魔法のように手に入れることができれば、DNSの問題の多くは非常にシンプルになると思います。

隠れたシステムとの付き合い方

ここでは、隠されたシステムを処理する方法をいくつか紹介します：

• 2023、「かまぼこ型」のアプローチを試み、通常は隠されているシステムの一部を見せました。
• DNSを拡張して、"デバッグ情報 "セクションを含めるとクールだと思います。

拡張DNSエラーは良好

拡張DNSエラーは、DNSサーバーが追加のデバッグ情報を提供するための新しい方法です。以下に例を示します：

$ dig @8.8.8.8 xjwudh.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 89330
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 215
; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)
;; QUESTION SECTION:
;xjwudh.com.			IN	A
;; AUTHORITY SECTION:
com.			900	IN	SOA	a.gtld-servers.net. nstld.verisign-grs.com.  
;; Query time: 92 msec
;; SERVER: 8.8.8.8#.8.8) (UDP)
;; WHEN: Sat Jul :45 EDT 2023
;; MSG SIZE rcvd: 161

ここでは、存在しないドメインをリクエストし、拡張子のエラーメッセージ EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)取得しています。これが何を意味するのかよく分かりませんが、このように追加のデバッグ情報が表示されるのはとてもクールです。

上記を見るためには、新しいバージョンのdigをインストールする必要があります。

紛らわしいツール

DNSの詳細の多くは隠されていますが、ディグツールを使うことで何が起こっているのかを知ることができます。

例えば、与えられたDNSリゾルバがキャッシュに特定のレコードを持っているかどうかを決定するために、dig +norecurseを使うことができます。応答がキャッシュされていない場合、8.8.8.8はSERVFAIL応答を返すように見えます。

以下は google.com 操作例です：

$ dig +norecurse @8.8.8.8 google.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61153
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 215
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 21 IN A .4.602
;; Query time: 57 msec
;; SERVER: 8.8.8.8#.8.8)
;; WHEN: Fri Jul :45 EDT 2023
;; MSG SIZE rcvd: 55

これは homestarrunner.com 例です：

$ dig +norecurse @8.8.8.8 homestarrunner.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 75577
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 215
;; QUESTION SECTION:
;homestarrunner.com.		IN	A
;; Query time: 52 msec
;; SERVER: 8.8.8.8#.8.8)
;; WHEN: Fri Jul :01 EDT 2023
;; MSG SIZE rcvd: 47

google.comでは通常のNOERRORレスポンスが返ってきますが、homestarrunner.comではSERVFAILレスポンスが返ってくることがわかります。これは、homestarrunner.comにDNSレコードがないわけではなく、キャッシュされていないだけです。

しかし、このようなアウトプットに慣れていないと、本当に読みにくい！私が奇妙に感じた点をいくつか挙げてみましょう：

1. 問題がおかしい。
2. スペースのタイポグラフィが変。
3. 変な感じMSG SIZE rcvd: 47
4. ADDITIONAL SECTION: セクションに1つのレコードがあると書かれていますが、表示されていません。

全体的に、ディグのアウトプットは、意図的にデザインされたものではなく、その場しのぎで書かれ、時間をかけて進化していった脚本のように感じられます。

紛らわしい道具を扱うためのいくつかのアイデア：

• 出力の解釈。例えば、 digの使い方についての 記事を書きましたが、そこではdigの出力と、デフォルトでより短い出力を与えるように設定する方法について説明しています。
• よりユーザーフレンドリーな新しいツールを作成します。 例えば、DNSには dog、doggo 、.NETがあります。これらのツールはとてもクールだと思いますが、個人的には使っていません。なぜなら、もう少し高度な操作をしたいときがあり、私の知る限り、dogもdoggoも+norecurseをサポートしていないからです。 私は1つのツールですべてをこなしたいので、digにこだわっています。 機能の幅が広いdigを置き換えるのは大仕事でしょう。
• digの出力をもっとユーザーフレンドリーに。もし私がC言語プログラミングが得意だったら、digのプルリクエストに+humanフラグを追加して、より構造化された読みやすい方法で長い形式の出力をフォーマットする、おそらく以下のようなものを書いてみるかもしれません：

$ dig +human +norecurse @8.8.8.8 google.com 
HEADER:
 opcode: QUERY
 status: NOERROR
 id: 61153
 flags: qr ra
 records: QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
QUESTION SECTION:
 google.com.			IN	A
ANSWER SECTION:
google.com. 21 IN A .4.602
ADDITIONAL SECTION:
 EDNS: version: 0, flags:; udp: 215
EXTRA INFO:
 Time: Fri Jul :01 EDT 2023
 Elapsed: 52 msec
 Server: 8.8.8.8:53
 Protocol: UDP
 Response size: 47 bytes

これにより、見出し、質問、回答、追加セクションなど、DNS回答の構成がより明確に表示されます。

そして、何も「単純化」していません！より構造化された方法でフォーマットされているだけで、まったく同じ情報です。代替DNSツールに対する私の最大の不満は、分かりやすくするために情報を削除することが多いことです。このようなツールにも確かに役割はありますが、私はすべての情報を見たいのです！しかし、私はすべての情報を見たいのです！私はそれが明確かつ簡潔な方法で表示されることを望んでいます。

よりユーザーフレンドリーなコマンドラインツールを設計する方法については、過去40年間に多くのことが学ばれてきました。

dig +yaml

digに関するちょっとしたメモ：新しいバージョンのdigは+yaml出力フォーマットをサポートしています。

奇妙な罠がいくつかあります。

DNSには、比較的一般的でありながら、独学では学びにくい奇妙な問題がいくつかあります。以下はその例です：

• ネガティブ・キャッシュ： 述べたように、DNSレコードが存在しないドメインにアクセスすべきではないと気づくのに5年ほどかかりました。なぜなら、そのレコードの 存在しない 情報がキャッシュされ、そのキャッシュは数時間更新されないからです。
• getaddrinfo 違い：TCP DNSは doggomuslでサポートされていませんでした。
• TTLを無視するリゾルバ：DNSレコードにTTLを設定した場合、一部のリゾルバはそのTTL設定を完全に無視し、24時間など長い期間レコードをキャッシュします。
• Nginxの設定を誤ると（このように）、DNSレコードが永久にキャッシュされます。
• KubernetesのDNSが遅くなるこのトーク 原因。

奇妙な罠への対処法

これに対する完璧な答えはありません。奇妙な罠の知識を得るのはとても難しいことで、人々が自分で何度も再発見しなければならないのは馬鹿げていると感じます。

いくつかアイデアをご紹介しましょう：

• トピックを説明するときに、誰かがトリッキーなことについて言及していると、とても助かります。たとえば、Josh Comeau 氏の『Getting Started with Flexbox』では、私が長年にわたって何度も遭遇してきたこの問題の説明を見つけて、この Minimum Size Trapについて説明しています。
• コミュニティがコンパイルした共通トラップをもっと見たいですね。 例えば、Bash用の共通トラップ集はとても素晴らしいものです。

DNSトラップのロギングで厄介なことの1つは、人によって遭遇するトラップが異なるということです。個人ドメインのDNSを3年ごとに設定するだけなら、異なる問題に遭遇するかもしれませんし、トラフィックの多いドメインを管理している人は別の問題に遭遇するかもしれません。

もっと単純な理由があります：

連絡の頻度が少ない

多くの人がDNSにほとんど触れたことがなく、3年に1度しかDNSを扱わないのであれば、学ぶのはさらに難しいでしょう！

この点で、メモ用紙は大いに役立つと思います。

実験しにくい

DNSは、あなたのドメイン名を台無しにしたくないので、実験するのが怖いかもしれません。 、このプロセスを少し簡単にするために作成されました。

以上です。

何がDNSを学びにくくしているのか、他のアイデアも聞きたいです。

を経由して