여러 DNS TXT 값을 단일 TXT 항목으로 입력합니다. 각 값은 " 표시로 표시되지만 공백으로 구분됩니다.

Question 1

여기서 인식해야 할 중요한 점은 TXT레코드가 하나 이상의 문자열(각각 최대 255자 길이)을 포함하는 레코드 데이터를 사용하여 다중 값을 가질 수 있다는 것입니다.
즉, TXT여러 값이 있는 하나의 레코드와 각각 하나의 값이 있는 여러 TXT레코드는 동일한 것이 아니며 동일하게 해석될 것으로 예상해서는 안 됩니다.

처음에 보여드린 것은 실제로는 TXT가지고 있는 기록 이 아닙니다.각 값이 "로 표시되고 공백으로 구분된 단일 문자열오히려 TXT따옴표나 공백이 포함되지 않은 세 개의 별도 문자열 값을 갖는 레코드입니다.
이러한 이해는 형식화 목적으로 사용되지만 실제로는 값의 일부가 아닌 이러한 문자를 이스케이프하는 것과 관련된 문제를 해결하려는 시도 중 하나이기 때문에 특히 중요합니다.

DNS를 이해하고 사용하는 모든 소프트웨어의 경우마스터 파일 형식(DNS 레코드의 표준 텍스트 표현), 처음에 포함시킨 내용은 세 개의 별도 문자열 값( , , ) 이 있는 ... TXT "txtvers=1" "proto=https" "path=/acs/resources/configurations"하나의 레코드로 이해되고 해석됩니다 .TXTtxtvers=1proto=httpspath=/acs/resources/configurations

서비스 제공업체에 이러한 형식의 입력을 허용하지 않는 인터페이스가 있고 여러 값을 입력하는 다른 방법을 제공하지 않는 경우(서비스 제공업체로부터 받은 답변에 따르면 그럴 가능성이 있음) 원하는 레코드를 입력할 방법이 없을 수 있습니다. 그들의 시스템에.
실제로 그렇다면 이 레코드를 다른 곳에서 호스팅해야 할 수도 있습니다( 해당 소프트웨어가 제공하는 경우 전체 영역을 이동하지 않고 TXT다른 영역에서 원하는 레코드를 다른 곳에서 호스팅하고 거기에 포인팅만 추가하는 등의 옵션 포함). CNAME이것에 동의하지 않습니다).

즉, TXT다른 표준의 일부로 특수하게 사용되는 경우에는 TXT순전히 긴 값을 허용하고 모든 문자열을 정의하는 수단으로 레코드 의 여러 문자열 값 사용을 정의하는 것이 더 일반적입니다(SPF 및 DKIM과 같은 광범위한 예 포함). ;잠재적으로 긴 단일 문자열 내의 다중 값 콘텐츠에 대해 일부 내부 구분 기호(일반적으로 )를 사용하는 대신 문자열 값을 추가 해석 전에 간단히 연결해야 합니다 .

귀하의 서비스 제공업체가 매우 일반적인 "장기 가치" 시나리오를 구체적으로 살펴보고 어떤 방식으로든 이를 지원했을 가능성이 매우 높습니다(특히 DKIM 때문에).
어느 쪽이든, 이러한 기록을 사용하는 소프트웨어의 설계가 전적으로 귀하에게 달려 있는 경우, 이와 관련하여 단순히 표준을 따르고 다중 값 콘텐츠를 저장하는 데 사용되는 것과 동일한 접근 방식을 사용하는 것이 더 나은 아이디어일 수 있습니다. TXT대신 이러한 광범위한 전문화. (그러나 이 시스템이 이미 사용 중인 경우 그러한 변경은 기존 기록과의 호환성에 분명히 영향을 미칠 것입니다).

Answer

여기서 인식해야 할 중요한 점은 TXT레코드가 하나 이상의 문자열(각각 최대 255자 길이)을 포함하는 레코드 데이터를 사용하여 다중 값을 가질 수 있다는 것입니다.
즉, TXT여러 값이 있는 하나의 레코드와 각각 하나의 값이 있는 여러 TXT레코드는 동일한 것이 아니며 동일하게 해석될 것으로 예상해서는 안 됩니다.