53
名前解決のためのポートで、UDP と TCP の両方を使います。そして最近の Linux デスクトップでは既に systemd-resolved が握っているので、dnsmasq や Pi-hole が起動しません。
自分の環境の行をそのまま実行してください。ポートを掴んでいるプロセス名と、バインドしているアドレスが出ます。たいていはそれだけで答えが分かります。
sudo lsof -nP -i :53ここではあえて `-sTCP:LISTEN` を付けていません。UDP のソケットに LISTEN 状態はないので、このフィルタを足すと DNS のいちばん大事な半分が消えてしまいます。`-i :53` は両方のプロトコルを選びます。プロトコルが書いてあるのは NODE の列で、`TCP` か `UDP` と出ます。TYPE はアドレス族（`IPv4` / `IPv6`）なので、TYPE が同じ IPv4 の行が二つあっても、片方は TCP、もう片方は UDP ということが普通にあります。`UDP` の行には括弧付きの状態がなく、`TCP` の行には `(LISTEN)` が付きます。NAME の列がバインド先で、`127.0.0.1:53` はこのマシン専用、`*:53` は全インターフェイスです。`-n` と `-P` でホストもポートも数値のままになります。`sudo` なしでは root 所有のリゾルバはまったく出てきません。
sudo ss -tulnp 'sport = :53'`-t` と `-u` を並べて TCP と UDP の両方、`-l` で待ち受けソケットのみ、`-n` でポートを数値のまま、`-p` でプロセス名を出します。アドレスの列が答えのすべてです。`127.0.0.53:53` は systemd-resolved の stub で、二つ目のリゾルバが bind できない原因そのもの。`127.0.0.1:53` はローカル専用、`0.0.0.0:53` や `[::]:53` はネットワークに開いたサーバーです。UDP の行に接続状態が出ないのは正常で、エラーではありません。プロセス名は `users:(("systemd-resolve",pid=701,fd=12))` の形で出ますが、`sudo` なしだと自分の所有でないものは空欄です。
sudo netstat -tulnp | grep ':53 'iproute2 のないホスト向けの net-tools 版で、フラグの意味は同じです。PID/Program name の列は自分の所有でないソケットには特権が要りますし、man ページはこの値が信用できないと注記しています。パターン末尾の空白は消さないでください。ないと `:53` がマルチキャスト DNS の `:5353` にも当たります。まったく別のサービスです。
netstat -ano | findstr :53ここでは `-a` がいつも以上に効いてきます。Microsoft はこのフラグを「すべてのアクティブな TCP 接続と、コンピューターが待ち受けている TCP・UDP ポート」を表示するものと説明していて、UDP 側を出すのがまさにこれです。`-n` で数値のまま、`-o` で所有 PID が付き、`tasklist /FI "PID eq 1234"` で名前になります。ドメインコントローラーなら持ち主は `dns.exe` で、そこにいるのが正常です。部分一致には注意してください。`:53` は `:5353` や `:53000` にも当たります。
`nmap -Pn -sU -p 53 ns1.example.com` は UDP 側、つまり実際の問い合わせが流れる側を見にいきます。`-sU` は raw socket を使うので `sudo` が要ります。付けずに実行すると、パケットを 1 つも送らないまま `You requested a scan type which requires root privileges.` で止まります。TCP の 53 番を試すなら `-sU` を外し、そして両方試してください。片方だけ開いているファイアウォールは、典型的な「たまに失敗する」の製造機です。UDP の結果は TCP ほどはっきりしません。沈黙と破棄が区別できないので、nmap は断定せず `open|filtered` と報告し、`closed` になるのは ICMP の port unreachable が返ってきた場合だけです。実際に何が観測されたかは `--reason` で分かります。ただ、本当の答えが欲しいならスキャンより質問です。`dig @ns1.example.com example.com A` はレコードを返すか、タイムアウトするか、拒否されるかのどれかで、同じ情報がずっと曖昧さなく手に入ります。スキャンは自分が責任を持つホストにだけ。
| 出ているもの | 意味 |
|---|---|
dnsmasq: failed to create listening socket for port 53: Address already in use | systemd 系のディストリビューションなら、ほぼ確実に systemd-resolved の stub リスナーが 127.0.0.53:53 を既に持っています。上の Linux 用コマンドで確認したうえで、`/etc/systemd/resolved.conf` に `DNSStubListener=no` を書いて systemd-resolved を再起動するか、自分のリゾルバをワイルドカードではなく特定のインターフェイスアドレスにバインドしてください。プロセスを kill して張り合っても、再起動すれば戻ってきます。 |
;; communications error to 192.0.2.1#53: connection refused | ホストは答えました。答えが「いいえ」だっただけです。そのアドレスの 53 番には何もバインドされていません。リゾルバが停止しているか、起動時に落ちたか、ループバックにしかバインドしていないのでサーバー自身以外からは見えないかのどれかです。リゾルバのホストでコマンドを実行し、プロセスの有無だけでなくバインドアドレスを見てください。 |
;; connection timed out; no servers could be reached | 何も返ってきていません。パケットフィルタが問い合わせを捨てているか——セキュリティグループ、ホスト上のファイアウォール、ネットワーク ACL のどれか——単にアドレスが違います。UDP はコネクションレスなのでリセットで教えてくれる相手もおらず、沈黙はタイムアウトいっぱい続きます。`dig +tcp` で TCP も試してください。TCP は通って UDP は通らないなら、遮断はプロトコル単位です。 |
;; Truncated, retrying in TCP mode. — then a timeout | 応答が UDP に収まる大きさを超えたので、サーバーは RFC 1035 の要求どおり TC ビットを立て、クライアントは TCP でやり直そうとして塞がれました。これは「UDP の 53 番だけ開けて TCP の 53 番を忘れた」ファイアウォールの壊れ方です。小さなルックアップは通り、DNSSEC 署名つきやレコード数の多い大きな応答だけ失敗するので、どの名前で壊れるかに気づくまではランダムな障害にしか見えません。 |
REFUSED status in a dig answer, or ;; got answer with no records | ポートもネットワークもデーモンも正常です。サーバーは問い合わせを理解したうえで断りました。たいていは権威専用のサーバーに再帰の質問をしたか、再帰を許可されたアドレス範囲の外から尋ねたかです。直すべきはネットワークではなくアクセスポリシーです。 |
bind: Permission denied binding port 53 as a normal user | 53 番は 1024 未満なので特権ポートで、他に誰が待ち受けていようがいまいが、カーネルは EACCES で bind を断ります。サービスマネージャー経由でリゾルバを起動するか、Linux なら `CAP_NET_BIND_SERVICE` を付与するか、`dig -p 5300 @127.0.0.1` のように高い番号でテストしてください。 |
IANA は 53 番を TCP・UDP 両方で `domain` に割り当てていて、どちらも本当に使われています。通常の問い合わせを運ぶのは UDP です。1 回のルックアップは往復とも小さなパケット 1 つで済み、コネクションを張るほうが答えより高くつくからです。TCP は UDP では足りない場合のためにあります。RFC 1035 は「UDP で運ばれるメッセージは 512 バイトに制限される」と定めていて、収まらない応答は TC ビットを立てた切り詰め状態で返され、クライアントは TCP で同じ問い合わせをやり直します。EDNS(0)（RFC 6891）を使えばクライアントはより大きな UDP バッファを広告できるので、大きな応答の多くは UDP のまま運べますが、RFC 7766 は TCP 対応を任意のフォールバックではなく必須としています。UDP でしか届かないリゾルバは、制限があるのではなく壊れています。ゾーン転送（AXFR）は常に TCP です。暗号化された DNS はここにはいません。DNS over TLS は RFC 7858 が `domain-s` として登録した 853 番、DNS over HTTPS は 443 番に相乗りします。プリンタや AirPlay が使う `.local` の名前解決、つまりマルチキャスト DNS は 5353 番（RFC 6762）なので、出力に出てくる `5353` の行はあなたのリゾルバではありません。ローカルでいちばんよく起きる衝突は systemd-resolved で、マニュアルには stub リスナーが「IPv4 アドレス 127.0.0.53 と 127.0.0.54 のポート 53」を占有すると書かれています。UDP も TCP も含みます。素の Ubuntu で dnsmasq、Pi-hole、CoreDNS、BIND がどれも起動しないのはこれが理由で、`/etc/systemd/resolved.conf` に `DNSStubListener=no` を書くまで解決しません。Docker コンテナの中ではリゾルバのアドレスがまた別で、`127.0.0.11` になります。
権威サーバーは届く必要があり、再帰リゾルバは届いてはいけません。インターネット全体からの再帰問い合わせに答えるリゾルバは、そのまま反射増幅の武器になります。攻撃者は送信元を標的のアドレスに詐称した小さな問い合わせを投げ、あなたのサーバーがずっと大きな応答を標的に送りつけます。RFC 5358（BCP 140）は、再帰ネームサーバーを開放したままにするなと運用者に伝えるためだけに存在しますし、オープンリゾルバは現れてから数時間で全世界スキャンに捕捉されます。再帰は自分のアドレス範囲に限定し、権威と再帰は別のサーバーに分けてください。そうすれば権威側は再帰せずに世界へ答えられます。AXFR も宣言済みのセカンダリに限定してください。制限のないゾーン転送は、内部の命名体系とホスト名、多くの場合ネットワークの構成まで、まとめて 1 回の要求で手渡します。応答にはレート制限をかけ、UDP はコネクションレスなので問い合わせの送信元アドレスは簡単に詐称できる、つまりそれを根拠にしたアクセス制御は見た目より弱いということを覚えておいてください。TCP の 53 番を開け忘れたまま放置するのも危険です。UDP だけ許可して TCP を塞ぐと、応答が UDP バッファに収まらなくなるまでは名前解決が動き、そこから先は「たまに、なぜか失敗する」という形で壊れます。
どれもブラウザ内で完結します。アップロードは発生しません。
53 を調べているとき、ついでに確認することになりがちなポートです。
ほぼ権限の問題です。lsof や ss はソケット自体は出しますが、他ユーザーのプロセスは所有者の列を伏せるので、システムアカウントやコンテナランタイム、launchd が起動したサーバーは sudo を付け直すまで持ち主不明のリスナーに見えます。Windows は逆で、netstat には何も出ないのに bind だけ失敗します。これは Hyper-V や WSL2、Docker Desktop が起動時に予約したポート帯に当たっている状態です。
何なのかを先に見てください。取り残された開発サーバーなら問題ありませんが、書き込み中のデータベースは別ですし、他が依存しているシステムサービスも同様です。持ち主がコンテナならコンテナごと停止してください。ホストから見えるプロセスを kill してもランタイムが再起動するだけです。どうしても止められないものなら、自分のサービスを別のポートへ移すほうが早く片付きます。
0.0.0.0 ではなく 127.0.0.1 にバインドしているからです。各ページのコマンドがプロセス名と並べてバインド先アドレスを出しているのはこのためで、ループバックにバインドしたものはファイアウォールの設定に関係なく自分のマシンからしか届きません。最近は意図的にそれを既定にしているフレームワークも多いので、たいていはバグではなくフラグの問題です。すでに 0.0.0.0 なのに届かないなら、次に疑うのはホストのファイアウォールかクラウドのセキュリティグループです。
ほとんどなりません。インターネット全体を舐めるスキャナーはポート範囲を丸ごと走査し続けているので、稼げるのは数時間であって安全ではなく、代わりに関係者全員がその番号を覚える羽目になります。既定ポートを狙う無差別スキャンのログが減るという効果は確かにありますが、それだけです。結果を変えるのは認証と、送信元アドレスを絞ったファイアウォールと、そもそも外に出さないことです。
ポート 53 でまだ詰まっていますか。ポート一覧をすべて見る。あるいは上に戻って、実際に出たエラー文から追ってください。