タグ付けされた質問 「rfc」

RFCが意見（ServerfaultのQ＆Aを含む）を支持して引用されることは非常に一般的ですが、平均的なIT従業員は、どのRFCが標準を定義し、どのRFCが純粋に情報を提供するかに関して非常によく理解していません。これは驚くべきことではありません。すべての経験レベルのシステム管理者は通常、RFCに目をつぶるのを避けなければなりません。 私たちのようなサイトでは、私たちの投票された答えでよくある誤解を永続させないことが非常に重要です。検索エンジンから巡回するランダムなユーザーは、異論のないコメントのない賛成票が十分な審査の指標であると想定します。最近、私は2011年からの答えに出くわしました。これは、私たちが賛成しており、おそらくコミュニティとインターネット全体に情報を提供するための何らかの努力を必要とするため、これが確実にキャッチされない場合があることを明らかにしました。 では、苦労せずに、インターネット標準として割り当て可能なRFCと純粋に有益なRFCをどのように区別するのでしょうか。

44 rfc 

そして、それは構成可能ですか？たとえば、200Kのクエリパラメータを持つURLが含まれるサーブレットに正常に通過するようにTomcatを設定できますか？ はい、大量のデータがある場合はPOSTを使用する必要があることを知っています。これは、この特定のケースではあまり快適ではないオプションです。含まれているアプリケーション（検索エンジン）は、GET要求が検索を実行することを期待しています。

43 tomcat  http  rfc  uri 

新しい年にサーバーを移動することを計画しているため、ホストしているすべてのWebサイトをCNAMESに移動しようとしています。クライアントに一意のCNAMEを提供することを計画していましたが、このCNAMEは後日変更できます。（今これを行う理由は他にもありますが、それが主な理由です） 私たちはこの理論をいくつかの独自のドメインでテストしてきましたが、問題ないように思えました。ただし、ドメインでMXレコードをチェックすると、MXレコードではなくCNAME値が返されました。 悲しいことに、これらのドメインはすべてコントロールパネルを介して行われますが、それらは私のためにゾーンファイルを作成しているだけだと推測しています。 company.comに2つのCNAMEを作成したい company.com. IN CNAME client.dns.ourserver.com www IN CNAME client.dns.ourserver.com MXレコードは次のようなものです。 company.com IN MX 10 mail.company.com mail.company.comのAレコードがあります やること： host -t mx company.com mxレコードではなく、CNAME値を返します。 これは予想される動作ですか？ 123-reg.co.ukコントロールパネルで上記の構成を動作させることができましたが、それが何よりも幸運かどうかはわかりません。

42 domain-name-system  mx-record  rfc 

誰かが尋ねる前に：DNSクエリがUDPではなくTCPを使用するのはいつですか？それは私の質問に答えません。 私が聞き続けるのは、「答えが長すぎる場合、DNSはTCPを使用します」です。しかし、これはそれがどのように起こるかを説明しません。 状況は次のとおりです。DNSクライアントはUDPを使用してレコードの解決を要求します。レコードはUDPには長すぎます： サーバーが特定のオペコードで応答し、クライアントをTCPに切り替えます サーバーはまったく応答せず、クライアントはTCPで再試行します サーバーはクライアントへのTCP接続を開きます（NATをカウントする場合は愚かですが、誰が知っていますか？） クライアントは何らかの形で（？）与えられたクエリがTCP上で実行されるべきであることを「知っている」ので、そもそもUDPに煩わされません DNS pixiesは必要に応じてUDPをTCPに魔法のように変換します 私は答えをインターネットで探していましたが、多くのノイズがあり（上記を参照）、そのための適切なGoogleクエリを書くことはできません（RFCで情報を見つけることもできません） 。

31 domain-name-system  rfc 

SMTPは、RFCに従って、本文（エンベロープではなく）に複数のFROMアドレスを許可します。 この機能は正当な目的で使用されたことがありますか？ 複数のFROMアドレスを持つメッセージを破棄しても安全ですか？

27 smtp  rfc 

IETF RFC 7505には、明示的に電子メールを受信しないドメイン/ホストのMXレコードが記載されています。これは、ドメインネームシステムのルートでMXを指すことによって実現されます。例えば、 nomail.example.com. 86400 IN MX 0 "." なぜこれが必要ですか？私の理解では、TLDの下でドメインを使用することにより、明示的な反論を利用できますinvalid。例えば、 nomail.example.com. 86400 IN MX 0 "spam.invalid." nomail.example.com. 86400 IN MX 10 "null.invalid." RFC 2782、DNS SRVも同様に、「 'のターゲット」を指定しているようです。サービスがこのドメインで明らかに利用できないことを意味します。」だから、私の質問は次のように思う： invalidこの機能をすでに提供しているのに、DNSルートを使用して「使用不可」を意味するのはなぜですか？

18 domain-name-system  rfc 

Cisco ASA 5520ファイアウォールでフェールオーバーの問題を診断しようとして、www.btfl.comへのtracerouteを実行しましたが、驚いたことに、ホップの一部がRFC 1918アドレスとして戻ってきました。 明確にするために、このホストはファイアウォールの背後になく、VPNが関与していません。そこに着くには、オープンなインターネットに接続する必要があります。 どのように/なぜこれが可能ですか？ asa# traceroute www.btfl.com Tracing the route to 157.56.176.94 1 <redacted> 2 <redacted> 3 <redacted> 4 <redacted> 5 nap-edge-04.inet.qwest.net (67.14.29.170) 0 msec 10 msec 10 msec 6 65.122.166.30 0 msec 0 msec 10 msec 7 207.46.34.23 10 msec 0 msec 10 msec 8 * * …

18 routing  rfc 

SMTPの「MAIL FROM：」フィールドが、メーリングリスト以外に、メッセージのDATAセクションの「From：」フィールドと一致しない正当な理由はありますか？ /programming/1750194/smtp-why-does-email-needs-envelope-and-what-does-the-envelope-meanから： 「しかし、カタツムリメールのメタファーを続けるために、ほとんどのプロの手紙には、手紙自体に印刷された送信者と受信者のアドレスが含まれます。これらの住所は郵便配達員には必要ではありませんが、代わりに受取人への礼儀です。ですから、電子メールが同じように機能するのは賢明です。」 このロジックの行の問題は、「受信者への礼儀」にあります。SMTP経由の電子メールに「差出人」アドレスを含めることは礼儀ではありません。受信者が返信を送信できるようにする場合は必須です。 From：PostfixのMAIL FROMに一致するようにFromヘッダーを制限する方法は？： 「しかし、本当にFrom：とMAIL FROMを確認したい場合は、Return-Path：がFrom：と一致するようにheader_checksを適用する必要があります。」 これを行うことの意味は何ですか？メーリングリストは明らかに問題になるでしょう。「MAIL FROM：」および「From：」ヘッダー情報が異なる他の正当な用途はありますか？

18 email  smtp  rfc 

FROMアドレスとTOアドレスの両方が「エンベロープ」と呼ばれる隠し要素で繰り返され、その後「ボディ」で再び繰り返されることを学びました。 質問 エンベロープデータが「ヘッダー」にコピーされないのはなぜですか？ なぜこの重複が存在し、必要な機能をメッセージ自体に埋め込むことができなかったのですか？ すべての（非SMTP）メッセージトランスポートはこれを行いますか？ SMTPにはどのような代替手段がありますか？（だから私は推論をよりよく理解できる）

15 email  smtp  rfc  legacy  protocol 

RFC-952（仮定の下のポイント1の最後の文）は単一文字のホスト名を禁止しており、いくつかのサービスが単一文字のホスト名で動作することを拒否する経験がありました（7年以上前の2002年）標準に準拠していません）が、過去数年間で多くの単一文字のホスト名が使用されているのを見てきました。現在、単一文字のホスト名は有効ですか？（もしそうなら、適切な検証リファレンスは何ですか？） 編集（答えからいくつかの情報を統合する）：DNSのさまざまな側面を含むいくつかのRFCで定義されているように見える1035年、1123年、そして2181年。RFC-2181セクション11： Note however, that the various applications that make use of DNS data can have restrictions imposed on what particular values are acceptable in their environment. For example, that any binary label can have an MX record does not imply that any binary name can be used as the …

14 domain-name-system  hostname  rfc 

サードパーティのメールゲートウェイリレーが、送信先のメールアドレス宛のメッセージの処理を拒否しています。アドレスは、firstname..lastname @ recipientdomain.comの形式です（2つのピリオドに注意してください）。これはRFCガイドラインで許可されていますか？ RFC 2822は、セクション3.4.1でこれに反対しているようです。 ローカルで解釈される文字列は、引用符付き文字列またはドットアトムです。文字列がドットアトムとして表現できる場合（つまり、テキスト文字または「。」以外の文字が含まれていない場合）、ドットアトム形式を使用する必要があり（SHOULD NOT）、引用符付き文字列形式はSHOULD NOT利用される。コメントと折りたたみ空白は、addr-specの「@」の前後に使用しないでください。 さらに、同じセクションで、これを参照します。 addr-spec =ローカル部分「@」ドメイン ローカル部分=ドットアトム/引用符付き文字列/ obs-local-part これは、ローカル部分のコンテンツをドットで区切ることができますが、2つの連続したドットは存在できず、ドットで開始または終了することはできないことを意味すると解釈します。そうは言っても、私はドットアトム構文に精通していないので、ここで間違えているかもしれません。 誰か確認して説明してもらえますか？

13 email  smtp  rfc 

スタンドアロン環境でUbuntu 10.04 LTSサーバーを使用し、ビューを使用してクライアントの2つの異なるサブネットを提供しようとしています。zone.rfc1918ファイルに関するエラーを取得しているため、そのファイルの用途を知りたいと思います。rfc1918アドレスをホストする意味は何ですか？ 私が使用しているサブネットはrfc 1918アドレスです。デフォルトのzones.rfc1918ファイルを含めると、（さらに）頭痛がしますか？

12 bind  internal-dns  rfc 

現在、ドメインレジストラーとDNSは、不明なドメインへのDNS要求を無視します。無視するということは、ブラックホールを意味し、応答しないことを意味します。これにより、DNSクライアントとリゾルバライブラリは再試行、バックオフ、最後にタイムアウトします。 dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org ... ;; connection timed out; no servers could be reached 他の一般的なドメインネームサービスを調査すると、他のプロバイダーは5（拒否）のRCODEを返すため、この動作は非常にユニークです。 dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org すべて次のようなものを返します。 ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732 または ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219 サーバールームのフロアにリクエストを単にドロップするのではなく、返すREFUSEDかNXDOMAINすぐに返すことが適切です。 サーバーが応答しないことについてプロバイダーに不平を言うと、サーバーが違反しているというRFCを引用するように頼まれます。サーバーがすべての要求に応答する必要があることを証明するように彼らが私に求めているのは奇妙ですが、それはそうです。 質問： 私の規定では、リクエストIDが重複していないか、何らかのDOS応答がない限り、サーバーは常にリクエストに応答する必要があります。これは正しいです？ 規定をサポートするには、どのRFCと特定のセクションを引用すればよいですか？ 私にとって、DNSクエリに応答しないのは悪いことです。ほとんどのクライアントはバックオフし、同じクエリを同じDNSサーバーまたは別のサーバーに再送信します。クライアントの速度が低下するだけでなく、権限のあるネームサーバーとNSエントリに応じて、独自のサーバーまたは他のサーバーによって同じクエリが再度実行されます。 ではRFC 1536および2308 …

11 domain-name-system  rfc  protocol 

ソースポートがランダムで、1024〜65535の範囲にあることが文書化されている場所を見つけるのに苦労しています。 これはどのRFCで文書化されていますか？ 編集： 特権ポートの最初のリファレンスはRFC2623 にあります。これはTCP / IPの実装により依存しており、事実上の標準であるようです。 IANAはポート番号を割り当てています（RFC1700）

11 tcpip  udp  rfc 

DNSサーバーでチェックを実行して、サーバーが正常に動作し、RFC仕様に準拠していることを確認することが何度もあります。DNSTools Webサイトを使用してこれを実行していました。何が起こっているのかがよくわかりました。すべてのサーバーが外の世界に応答しており、重要な（特にNS、MX）レコードがまだ正常に複製されています。また、MXレコードがブラックリストに登録されているかどうかを確認します。 信頼できる「ワンストップショップ」を見つけることができなかったので、ブラックリストは常に苦痛の種でした。 私はしばらくの間DNSツールを使用していませんでしたが、今では支払いが必要になっています（大規模な内部監視ソリューションに投資しているときに上司に正当化するのは困難ですが、確認してください」） 私の仲間のシステム管理者は、DNSレコードを確認するために何を使用しますか？

11 domain-name-system  blacklist  rfc