☰

複数の DNS TXT 値を 1 つの TXT エントリとして入力します。各値は " マークで囲み、スペースで区切ります。

tag-icon • tag-icon domain-name-system dns-hosting ptr-record txt-record srv-record
複数の DNS TXT 値を 1 つの TXT エントリとして入力します。各値は " マークで囲み、スペースで区切ります。

他の DNS プロバイダーでもこの操作を実行しましたが、UltraDNS の DNS 管理インターフェイスで行き詰まってしまいます。エントリに複数の値を入力してTXT、各値を " マークで囲み、スペースで区切った単一の文字列として解決する必要があります。

TXT レコードで返される内容の例は次のとおりです (Linux の dig を使用してテストします)。

;; ANSWER SECTION:

name._avaya-ep-config._tcp.example.com. 119 IN  TXT "txtvers=1" "proto=https" "path=/acs/resources/configurations"

しかし、UltraDNS サポートは、これらを別々のレコードとして入力する必要があると言っていますTXT。そうすると、以下の結果が返され、このTXT値を探しているソフトウェアはそれを認識せず、機能しません。

;; ANSWER SECTION:

name._avaya-ep-config._tcp.example.com. 218 IN  TXT "proto=https"

name._avaya-ep-config._tcp.example.com. 218 IN  TXT "txtvers=1"

name._avaya-ep-config._tcp.example.com. 218 IN  TXT "path=/acs/resources/configurations"

\ここでは、RFC に基づいて、二重引用符の使用、RFC ごとの引用符の使用、RFC ごとの の使用を 試しました。https://www.rfc-editor.org/rfc/rfc1464

RFC の例からの提案のいくつかを試したところ、UltraDNS の Web インターフェイスでは、ASCII 文字のみを入力する必要がある (すべて ASCII 文字でしたが、他の ASCII 文字セットのコードでもありました) というメッセージが表示され、入力できませんでした。

無効な入力: コメントには ASCII 文字のみがサポートされています

たとえば次のように入力すると:

\txtvers=1\"<sp>\"proto=https\"<sp>\"path=/acs/resources/configurations\

ソフトウェアも使用して記録しSRV、それらは機能しますが、このフォーマットの問題により、値PTRからパスが適切に取得されません。TXT

答え1

ここで認識しておくべき重要なことは、TXTレコードは複数の値を持つことができ、レコード データにはそれぞれ最大 255 文字の 1 つ以上の文字列が含まれるということです。
つまり、TXT複数の値を持つ 1 つのレコードと、TXTそれぞれ 1 つの値を持つ複数のレコードは同じものではなく、同じように解釈されるとは限りません。

最初にお見せしたものは、実際には記録TXTではありません各値が " マークで囲まれ、スペースで区切られた単一の文字列TXT引用符やスペースを含まない 3 つの個別の文字列値を持つレコードです。この理解は、問題を解決しようとしたことの 1 つに、書式設定の目的で使用されているが実際
には値の一部ではないこれらの文字をエスケープすることが含まれていたため、特に重要です。

DNSを理解し使用するソフトウェアの場合マスターファイル形式(DNS レコードの標準テキスト表現)では、最初に含めたものは、3 つの個別の文字列値 ( 、、)を持つ... TXT "txtvers=1" "proto=https" "path=/acs/resources/configurations"1 つのレコードとして理解され、解釈されます。TXTtxtvers=1proto=httpspath=/acs/resources/configurations

サービス プロバイダーのインターフェイスがこの形式の入力を受け入れず、複数の値を入力する他の手段も提供していない場合 (プロバイダーからの回答から、その可能性が高そうです)、必要なレコードをプロバイダーのシステムに入力する方法がない可能性があります。その場合、このレコードを別の場所でホストすることを検討する必要があります (ゾーン全体を移動するのではなく、別の場所でホストされている別のゾーンに
目的のレコードを配置し、そこにポイントを追加するだけというオプションも含まれます。ただし、問題のソフトウェアが何らかの理由でこれに反対しない限り)。TXTCNAME

とはいえ、TXT他の標準の一部としての の特殊な使用では、レコード内での複数の文字列値の使用を、TXT長い値を許可し、すべての文字列値をそれ以上の解釈の前に単純に連結する必要があることを定義する手段としてのみ定義する方が一般的です (SPF や DKIM などの一般的な例を参照)。代わりに、;単一の長い可能性のある文字列内の複数値コンテンツに何らかの内部区切り文字 (通常は )を使用します。

サービス プロバイダーが、非常に一般的な「長い値」のシナリオを具体的に検討し、何らかの方法でそれをサポートしている可能性が非常に高いです (特に DKIM が原因と考えられます)。いずれに
しても、これらのレコードを使用するソフトウェアの設計があなた次第である場合は、この点に関して標準に準拠し、代わりにこれらの広く普及している専門分野で使用されているのと同じアプローチを使用して、多値コンテンツを保存する方がよいかもしれませんTXT(ただし、このシステムがすでに使用されている場合、このような変更は既存のレコードとの互換性に明らかに影響します)。

答え2

回避策: 以下のTXTレコードを追加します

parmset=txtvers=1,proto=https,path=/acs/resources/configurations

これが役に立つことを願っています

関連情報