他の 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 つのレコードとして理解され、解釈されます。TXT
txtvers=1
proto=https
path=/acs/resources/configurations
サービス プロバイダーのインターフェイスがこの形式の入力を受け入れず、複数の値を入力する他の手段も提供していない場合 (プロバイダーからの回答から、その可能性が高そうです)、必要なレコードをプロバイダーのシステムに入力する方法がない可能性があります。その場合、このレコードを別の場所でホストすることを検討する必要があります (ゾーン全体を移動するのではなく、別の場所でホストされている別のゾーンに
目的のレコードを配置し、そこにポイントを追加するだけというオプションも含まれます。ただし、問題のソフトウェアが何らかの理由でこれに反対しない限り)。TXT
CNAME
とはいえ、TXT
他の標準の一部としての の特殊な使用では、レコード内での複数の文字列値の使用を、TXT
長い値を許可し、すべての文字列値をそれ以上の解釈の前に単純に連結する必要があることを定義する手段としてのみ定義する方が一般的です (SPF や DKIM などの一般的な例を参照)。代わりに、;
単一の長い可能性のある文字列内の複数値コンテンツに何らかの内部区切り文字 (通常は )を使用します。
サービス プロバイダーが、非常に一般的な「長い値」のシナリオを具体的に検討し、何らかの方法でそれをサポートしている可能性が非常に高いです (特に DKIM が原因と考えられます)。いずれに
しても、これらのレコードを使用するソフトウェアの設計があなた次第である場合は、この点に関して標準に準拠し、代わりにこれらの広く普及している専門分野で使用されているのと同じアプローチを使用して、多値コンテンツを保存する方がよいかもしれませんTXT
(ただし、このシステムがすでに使用されている場合、このような変更は既存のレコードとの互換性に明らかに影響します)。
答え2
回避策: 以下のTXTレコードを追加します
parmset=txtvers=1,proto=https,path=/acs/resources/configurations
これが役に立つことを願っています