ネームサーバーがTCP経由でクエリに応答する必要があるのは本当ですか？

23

私は、いくつかの大きなWebホストのDNSサーバーの監視を設定するプロセスです。私の目標は、pingへの応答を追跡することにより、DNSサーバーの応答時間を比較することです。

その過程で、Bluehostネームサーバーがpingに応答しないことがわかりました。bluehost.comでPingdom DNS Checkを実行して詳細情報を取得しようとすると、次のエラーが生成されました。

ネームサーバーns1.bluehost.com（74.220.195.31）は、TCPを介したクエリに応答しません。

ネームサーバーは、TCP経由で送信されたクエリへの応答に失敗しました。これはおそらく、ネームサーバーが正しくセットアップされていないか、ファイアウォールでフィルタリングが誤って設定されていることが原因です。DNSは、ゾーン転送を提供しない限りTCPを必要としないという一般的な誤解です。おそらく、ネームサーバー管理者は、TCPが通常要件であることを認識していません。

次のことを知りたいです。

上記の声明はどの程度真実ですか？
ネームサーバーがTCP経由のクエリに応答しないことの影響は何ですか？

domain-name-system nameserver

— タラス・マンコフスキー
ソース

47

Pingdomの診断テキストは正確です。TCPは、ゾーン転送専用ではありません。

DNSサーバーの実装は、RFC 5966「TCPを介したDNSトランスポート-実装要件」に従って、TCPをサポートするために（RFCが必要とする限り）「必要」になりました。

これはサーバーソフトウェアの実装の要件であり、サーバーの運用には厳密に適用されないことに注意してください。運用上の慣行は対象外です。

ただし、特定のDNSサーバーがTCPをサポートするように構成されていない場合、またはブロックされている場合、長期的な影響はDNSSECを正しくサポートできなくなることです。同様に、応答が512バイトを超える他のDNSデータがブロックされる場合があります。

ob免責事項：私はそのRFCを書きました。

RFC 5966の編集が RFC 7766に置き換えられました。

— アルニタク
ソース

RE：運用上の慣習として、DNSSECを嫌う人は、TCPを無効にして、適切な手段としてファイアウォールにドロップすることができます。当然、結果があります。2つのエンドポイントでのEDNS0のサポートは、エンドポイント間のデバイスが何らかの方法で干渉しないようにすることはできません。（断片化、古代のファイアウォールによる偽のフラグ付けなど）認証サーバーに大きなDNSレコードがある場合（TXTが肥大化している場合）、対象ユーザーのセグメントを除外したくない場合はTCPが必要になります。同様に、再帰サーバーで無効にすると、メールクラスターがスパムに対処する必要があるDNS応答から隔離されます。

— アンドリューB

3

TCPとUDPをサポートする必要があります-TCPは応答サイズ> 512バイト（ゾーン転送を含む）用です（とにかく読んだものによると。通常、実行するNSでTCPとUDPを有効にします...）

— マーク・リージェンスバーグ
ソース

-2

この件に関してRFCが何を言っているかを知ることは良いことであり、そのことについてはすでに正式な回答がありますが、実際的な目的のために、DJBDNSの著者であるDaniel J.

http://cr.yp.to/djbdns/tcp.html#why（2003-01-16）

TCPクエリはいつ送信されますか？

次のいずれかの状況にある場合は、TCPクエリに応答するようにDNSサーバーを構成する必要があります。

512バイトを超えるレコードセットを公開します。（これはほとんどの場合間違いです。）

たとえば、サードパーティのサーバーへの発信ゾーン転送を許可したい。

TCPサービスをセットアップするまで、親サーバーは名前の委任を拒否します。

これらの状況のいずれにも該当しない場合、TCPサービスを提供する必要はないため、セットアップしないでください。DNS-over-TCPはDNS-over-UDPよりもはるかに遅く、本質的にサービス拒否攻撃に対してはるかに脆弱です。（これはBINDにも適用されます。）

彼はDNSSECの明示的な言及を省略していることに注意してください。その理由は、DJBによると、DNSSECは「常に間違い」のカテゴリに分類されるからです。詳細については、https：//cr.yp.to/djbdns/forgery.htmlを参照してください。DJBには、DNSCurveと呼ばれる代替標準（http://dnscurve.org/）があります。これは、一部のプロバイダー（OpenDNSなど）で既に独立して採用されています。興味深いのは/security/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoptionです。

上記のDJBDNSセットアップに関するドキュメントがその機能を示すものである場合、AXFR for TCPのみをサポートしているように見えることに注意してください。多くのプロバイダーはまだDJBDNSを使用しているため、追加の努力なしにTCPを介したDNSをサポートする可能性は低いでしょう。

PS DJBは実際、彼が説教することを実践していることに注意してください。彼自身のサーバー（1）はDNSCurveを実行し、（2）TCPに適切に応答しません。のみ+notcp成功します（デフォルト）：

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

、一方、+tcp失敗します（選択されたサーバーに応じて、明らかに異なるエラーメッセージが表示されます）：

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached

— cnst
ソース

2

あなたのDJBファンボアの行為はかなり着ています。DNSコミュニティはDNSSECを選択した、とDNSCurveに関する文献の多くは、完全に融合します直交の要件データの信憑性やデータの暗号化を。IMNSHO、あなたの答えの大部分はこの質問に何も貢献しません。

— アルニタック

@ Alnitak、DNSにTCPが必要であるという主張は、それがDNSの実際の要件にならないことです。明らかに多くの人々がTCPなしで走り、自分のウェブサイトの可用性に関する問題を経験していません。それでも、あなたは誤報とFUDの宣伝を続けています。

— cnst

2

その文書は本当に2003年のものですか？2017年にまだ関連があると真っ向から主張するにはどうすればよいですか？

— マイケルハンプトン

1

@MichaelHampton、はい、心から絶対に。変化しないものもあり、DJBは嫌な奴かもしれませんが、彼はその点でかなり賢い人です。彼が提示するすべての議論は本質的に哲学的であり、技術のように変わらない。一方、（1）なぜ信じるのがそんなに難しいのか、（2）まっすぐな顔で、あなたが偽善者にならずに、さらに古いRFCにリンクしているのはなぜか、（3）あなたが持っている以外の実際の反論は何ですか？デート"？彼のやり方には相互運用性の問題があると人々は言い続けていますが、提案されているまさにその議論（例えば、メールのバウンス）は2003年に反論しました！

— cnst

-5

TCPは必須であり、通常は長い応答が必要な場合にのみ使用されます。マイナスの影響がある可能性があります。ゾーン転送は大きいため、TCPを介して行われ、信頼性が必要です。信頼できないサーバーからのTCPを許可しないことは、小さな回答のみが提供されるようにする1つの方法です。

署名済みDNS回答の導入により、UPD回答の512バイト制限を緩和する必要がありました。EDNS0は、より長いUDP応答のメカニズムを提供します。DNS over TCPを許可しないと、安全なDNSの実装が破壊される可能性が高くなります。

インターネットに対してUDPポート53のみが開いているDNSサーバーを実行することは完全に可能です。DNSピアへのTCPアクセスが必要ですが、これはホストの小さなリストです。

完全なDNS実装のためにTCPを必要とする新しいRFC596があります。これは、実装者を対象としています。このドキュメントは、具体的にはオペレーターを扱っていませんが、TCPを許可しないと多くの障害シナリオが発生する可能性があることを警告しています。DNS over TCPがサポートされていない場合に発生する可能性のあるさまざまな障害について詳しく説明します。

DNS増幅攻撃を防ぐためにTCPを使用することについての議論がありました。TCPには独自のサービス拒否リスクがありますが、配布はより困難です。

— ビルソー
ソース

DNSSECは1999年にEDNS0が緩和した制限を緩和しませんでした（RFC 2671を参照）。

— アルニタック

いいえ、Alnitakが説明したように、ほとんどの場合、TCPが必要です（512バイトを超える応答が絶対にないことを完全に確信できる場合を除き、通常は事前に知らないことです）

— bortzmeyer

UDPのみを許可するファイアウォールを介してDNSを正常に実行しました。病理学的構成がなければ、アドレス検索は512文字未満になります。DNSパスが256文字に制限されているという参照を見てきました。メールサーバーのデータベースの証拠から、サーバーのDNSパスが100文字を超えることはめったになく、PTRレコードによって複数の名前が返されるサイトでは256文字を超えることはめったにありません。これらの応答はすべてUDPで実行されます。DNSSECまたはゾーン転送なしで512文字近くで実行される合理的なケースはありますか。

— BillThor

DNSSECについては、RFCで拡張サイズを確認しませんでしたが、UDPで拡張パケットサイズを使用しているのはDSNSECだけです。

— BillThor

大手コンテンツプロバイダーの1つは、数年前にWebファームの1つに非常に多くのAレコードを追加し、512バイトを超えたため、行き詰まりました。それが本当の相互運用上の問題を引き起こしました。

— アルニタック