私たちは、ここ数年間、さまざまな Linux サーバー (Ubuntu) と Windows+Linux クライアントを使用してオフィス ネットワークを正常に運用してきました。1 つのサーバーは、DNSmasq 軽量 DNS サーバー パッケージを使用して内部 DNS サーバーとして機能します。
$ nslookup machine.domain.comそして今日、コマンドは機能するが、機能しないことがわかりました
$ nslookup machine.domain.com/--> 存在しないドメイン / NXDOMAIN
これは、Ubuntu マシンでも Windows マシンでも発生しました。
これは、単にここで (つまり、「nslookup」や「host」などのコマンドを使用する場合)、末尾のスラッシュがドメイン名の一部 (つまりトップレベル ドメインが「com/」) とみなされるからでしょうか。それとも、内部 DNS サーバーの設定ミスを示しているのでしょうか。
明らかに、ブラウザは「通常」このスラッシュを正しく処理します。つまり、DNS ルックアップにスラッシュなしのドメイン名だけを使用して、答えを取得します。ここで「通常」と書いたのは、ちょうど今日、Ubuntu 22.04 LTS の新規インストールにインストールされた新しい Firefox で、ブラウザのアドレス バーにスラッシュ (つまりmachine.domain.com/) を入力すると、奇妙なことに上記の NXDOMAIN エラー メッセージが表示されてしまったからです。
さらに奇妙なことに、末尾のスラッシュを削除して検索が成功した後でのみ、「スラッシュ付きアドレス」でも機能し始めました。この後者の動作は Firefox のキャッシュによって発生している可能性があります...
どなたか、私に何かアドバイスをいただけませんか? これは、DNS の仕組みに関する私の理解不足 (つまり、末尾のスラッシュやそれに続くパスが実際には「別のドメイン」を指している) と Firefox のバグ (つまり、インストールされている Firefox バージョンの DNS クエリに誤ってスラッシュが含まれている) の組み合わせなのでしょうか? ありがとうございます!
答え1
標準が混在しています。ハイパーテキスト転送プロトコル (HTTP) では、「スラッシュ」の使用が正しいです。
HTTP 準拠のアドレスは、プロトコル定義、それに続く完全修飾ドメイン名 (FQDN)、および Uniform Resource Indicator (URI) から形成されます。
例えばhttps://sub.domain.tld/uri/of/the/resource/being/requested
プロトコル: https (TLS カプセル化 HTTP プロトコル) FQDN: sub.domain.tld URI: /uri/of/the/resource/being/requested
一方、DNSはFQDNを到達すべきIPアドレスに解決することのみを目的としています。例：
FQDN: one.one.one.one ipv4: 1.1.1.1
トップレベルドメインは、FQDN の一部、つまり.区切り文字に続く最後の部分です (例: .com .co.uk .siteetc...)。
nslookupつまり、渡されるドメインが解決に失敗する理由は、 が/文字通り解釈されるのに対し、どのブラウザも が何であるかを認識するためです。これは、HTTP プロトコルの一部です。
nslookupは解決を試み、どのブラウザも入力をFQDNとURIsub.domain.tld/に「まとめる」sub.domain.tld/
これで少しは明確になったかと思います
答え2
ここで述べたようにリンク(microsoft) ドメインには、アルファベット文字、数字、および「-」記号のみを含めることができます。
それ以外は違法です(正しくはありません。@Patrick Mevzek によって正しく訂正されています)、nslookup はおそらくこれを解析しないか、DNS サーバーがこのようなばかげた要求を正当に拒否します :)
スラッシュの後の Web ブラウザで発生する内容は DNS の一部ではなく、nslookup はこれを理解しません。
たとえば、curl はエラーを出力せず、これを Web サーバーのルートとして認識します。
curl example.com/
<!doctype html>
<html>
<head>
<title>Example Domain</title>