前回はうさちゃんRabbit4000の投げたDNSクエリをRaspberry Pi 4上のDNSサーバでレスポンス。「行ってこい」できたところでその中身は良く見てなかったです。今回は前回と同じ設定のまま、クエリとレスポンスの中身をwiresharkで観察したいと思います。だいたいDNSパケットってUDPだったけ？わかってないデス。
※「うさちゃんと一緒」投稿順 Index はこちら
※Rabbitシリーズのマニュアルは、販売元のDigi社のページからダウンロードできます。
※実験には、Rabbit4000搭載のRCM4010モジュールを使用しています。ソフトウエアはDynamic C 10.72でコンパイルしています。
※対向するDNSサーバには、Raspberry Pi 4 model B（Raspberry Pi OS 64bit bullseye)にインストールしたdnsmasqを使用しています。
お相手が寝ていたときのうさちゃんの挙動
前回特段問題なくクエリに対してレスポンスが返ってました。ほとんど無意識に装置に電源入れて動かした後、うさちゃんからDNSクエリを投げたらレスポンスが返ってきませんでした。単純な理由です。ラズパイ側の dnsmasq が動いてなかった。おまぬけ。
しかし、DNSクエリを投げてもレスが返ってこないときのうさちゃんの挙動を観察できました。こんな感じ（うさちゃんのIPアドレスが192.168.2.59です。）
上記のようにクエリを投げて、レスポンスが返ってこないと、約２秒後にもう一回クエリを投げてます。それでおしまい、断念と。
初回のDNSクエリはこんなパケットです。
２回目のクエリの内容も初回同様ですが、wiresharkはちゃんと上のパケットの再送だと認識して、黄色でDNSヘッダを強調してくれてます。そして下の方をみるとオリジナルのリクエストは上のフレームよ、とリンクまで張ってくれてます。wiresharkさえあれば、なんとかなっちゃう感がアリ。
dnsmasqにカツを入れた後の正常なやりとり
ラズパイ側のdnsmasqにrestartかけた後のクエリとレスポンスが以下に。ようやく前回通りの正常動作です。192.168.2.59のうさちゃんから.126のラズパイにDNSクエリが行き、約１秒後にラズパイからうさちゃんにDNSレスポンスが返っているようです。
まずは、クエリ側からみていきます。IPの内側にいるのはUDPでした。うさちゃん側のポートは6158ですが、ラズパイ側のDSTポートは53です。53/udpというのがDNSの基本みたいっす。しかし「積み荷」が長いときは53/tcpだったり、UDPの拡張メカニズムEDNS0などというものも使われるらしいです。知らんけど。
ううむ、うさちゃんに53/tcpでレスポンス返したらどうなるのだろう？目を回すんじゃなかろうか？まあ、面白いので「そのうち」やってみたいと思いますが。
さてUDPの中に載っているのがDNSクエリであります。以下のダンプをみると、
-
- Flags: 0x0100 Standard query
- Questions: 1
- Answer RRs: 0
- Authority RRs: 0
- Additional RRs: 0
などとあります。１のFlagsについては後で調べますが、２のQuestionsは、このパケットに載っている「質問の数」みたいっす。例によって本サイトのURL１つを問いかけてますので質問は一つ。その後のAnswerは答えの数、このパケットは一方的な問いかけなので答えなどない、０だと。さらに３のAuthorityは、ラズパイ上のDNSサーバの「先」にあるもっと根本のDNSサーバ様の情報みたいです。またさらに追加情報があればAdditonalにも数が入るけれど問いかけている時点では、これまた０だと。
さて気になる Flags=0x0100がなんでStandard queryなんだという一件は、解読すると以下のようです。これまた wiresharkが解読してくれます。先頭ビットは0なのでこれはqueryだと、その後のオペコード４ビットがオール０なのでStandard queryだと（他のオペコードは知らんです。どこかネットに書いてあるハズ。）以下「再帰的」なところだけ１が立っておるようです。クエリを投げている「うさちゃん」はDNSの大きな木の最末端、その先のラズパイDNSサーバももっと上の「キャッシュしている」DNSサーバに問いかける立場なので「再帰的」ってことでいいかね。どうなんだろ。
ラズパイDNSからのレスポンス
さて上のクエリに対するレスポンスが以下に。お返事もUDPでしたね。短い（ペイロード４７バイト）から当たり前か。ラズパイ側のポート５３からうさちゃん側のポートに投げ返されてます。
DNSの中身をみています。DNSのパケットは行きも帰りも同じ形式です。レスポンスのFlagsは Standard query response, No errorだ、やったね（何が。）
Questionsは１。うさちゃんからの問いかけをそのままオウム返しに載せているみたいっす。Answerも１。ここに名前解決の結果が載っておるハズ（載ってますね。以下のとおり）
気になるFlags 0x8180の中身が以下に。先頭が１なのでresponse、オペコードはStandard queryで0のままなのね。そして再帰をお願いされた(Recursion desired)けど、再帰できる(Recursion available)と能力をお示しになっておられるようです。これであってる？
前回、行ってこい成功で「流した」パケットの中身をなでるだけでまた１回。Ethernetを流れるビットパターンを眺めるだけで意味が分かる境地にはほど遠いです（それは無理だ、多分。）でもWireshark使えばいいじゃん。だから忘れる。