TXT 레코드

TXT record
인터넷 프로토콜 제품군
응용 계층
전송층
인터넷 계층
링크 레이어

TXT 레코드(텍스트 레코드의 줄임말)는 임의의 텍스트를 호스트나 다른 이름과 연결하는 기능을 제공하는 데 사용되는 DNS(Domain Name System)의 리소스 레코드의 한 유형으로, 서버, 네트워크, 데이터 센터 또는 기타 회계 정보에 대한 사람이 읽을 수 있는 정보와 같다.[1]

그것은 또한 종종 적은 양의 기계 판독 가능 데이터를 DNS에 기록하는 더 구조화된 방식으로 사용된다.

배경

DNS 서버 구현이 이를 지원하는 경우 도메인은 여러 TXT 레코드를 연결할 수 있다.[2]각 레코드는 차례로 하나 이상의 문자열을 가질 수 있다.[3]전통적으로 이러한 텍스트 필드는 전체 회사나 조직 이름 또는 호스트 주소와 같이 표준화되지 않은 다양한 용도로 사용되었다.

1993년 RFC 1464는 이러한 텍스트 필드에 속성과 그 값을 저장하는 단순한 접근방식을 제안했다.이것은 현재 다음에서 광범위하게 사용된다.

TXT 레코드를 사용하여 다른 목적으로 데이터를 저장하는 것은 문제가 없는 것은 아니다.DNS 프로토콜은 클라이언트가 특정 도메인 이름(예: example.com)에 대해 특정 레코드 유형(예: TXT)을 쿼리할 때 해당 유형의 모든 레코드는 동일한 DNS 메시지로 반환되어야 한다고 명시한다.이는 많은 "불필요한" 정보가 전송되는 대규모 거래 및/또는 TXT가 사용할 기록에 대한 불확실성으로 이어질 수 있다.TXT 레코드를 특정 목적으로 사용할 때 사용할 도메인 이름 접두사(예: DKIM의 경우 _domainkey.example.com –)를 지정하거나 완전히 새로운 레코드 유형을 생성하는 두 가지 방법이 있다.전자는 DNS 시스템을 변경할 필요가 없기 때문에 "쉬운" 것이다.후자는 DNS 데이터베이스 모델의 설계와 더 잘 일치하기 때문에 때때로 "깨끗한" 것으로 간주된다.과거에는 IETF에서 복잡한 절차였기 때문에 새로운 기록 유형을 만드는 것을 피하곤 했다.그 과정이 훨씬 더 가볍고 빠른 것으로 대체되었음에도 불구하고, 어떤 사람들은 꺼림칙함을 느낀다.

포맷

TXT 레코드의 구조는 다음과 같다. RFC1035는[10] 다음과 같다.규격은 텍스트 문자열의 문자 인코딩 주제에 대해 정숙하다는 점에 유의하십시오.문자열의 해석은 상황에 따라 다르며, 데이터는 DNS 내부의 이진법으로 취급한다고 명시되어 있다. 이후 규격(예: 서비스 검색에 사용되는 RFC6763[11] – DNS)은 특정 목적을 위해 특정 인코딩을 사용해야 할 수 있다.

RDATA 섹션은 (TXT 길이 + TXT)의 연속적인 발생을 포함할 수 있다.데이터 길이는 모두 결합된 길이입니다.

레코드 구조
밭 유형 설명
이름 레이블 순서 도메인 이름(레이블 시퀀스로 인코딩됨)
유형 2바이트 정수. 레코드 종류.이 경우 유형이 TXT이므로 0x0010이 된다.
클래스 2바이트 정수 학급.
TTL 4바이트 정수 수명(Time-to-Live), 즉 레코드를 요청하기 전에 캐시할 수 있는 시간.
데이터 길이 2바이트 정수 레코드 유형별 데이터의 길이.
TXT 길이 1바이트 정수 TXT 문자열 길이
TXT 끈 문자열이
example.com의 TXT 응답 예제
이는 TXT 레코드에 대해 쿼리했을 때 example.com에서 DNS 응답의 일부로 반환된 16진수다. 
0000   34 48 81 a0 00 01 00 02 00 00 00 01 07 65 78 61 0010   6d 70 6c 65 03 63 6f 6d 00 00 10 00 01 c0 0c 00 0020   10 00 01 00 00 54 5f 00 0c 0b 76 3d 73 70 66 31 0030   20 2d 61 6c 6c c0 0c 00 10 00 01 00 00 54 5f 00 0040   21 20 38 6a 35 6e 66 71 6c 64 32 30 7a 70 63 79 0050   72 38 78 6a 77 30 79 64 63 66 71 39 72 6b 38 68 0060   67 6d 00 00 29 02 00 00 00 00 00 00 00


이 응답의 일부로, 두 개의 텍스트 레코드가 있는데, 그 중 첫 번째 레코드는 아래와 같다(54바이트에서 시작). 

0000   c0 0c 00 10 00 01 00 00 54 5f 00 0c 0b 76 3d 73 0010   70 66 31 20 2d 61 6c 6c

이것은 다음과 같이 디코딩된다.

레코드 구조
밭 육각 가치
이름 0xc00c example.com (이전 라벨에 대한 점프 지침임)
유형 0x0010 인
클래스 0x0010 TXT
TTL 0x0000545f 21599(5시간 59분 59초)
데이터 길이 0x000c 12
TXT 길이 0x0b 11
TXT 0x76 3d 73 70 66 31 20 2d 61 6c 6c v=spf1 -all

비정형 텍스트로서 조직은 TXT 문자열을 다음과 같이 정의한 모든 방법으로 사용할 수 있다.

example.com.IN TXT "이 도메인 이름은 설명서에서 사용하기 위해 예약됨"

RFC 1464는 다음과 같은 예에서처럼 단일 기록에서 속성과 그 값을 정의하는 데 사용할 수 있는 구조화된 형식을 정의한다.[2]

host.widgets.com.TXT에서 "printer=lpr5" sam.widgets.com.IN TXT "맛있는 음료=오렌지 주스"

실제로, TXT 레코드를 사용하는 서비스는 종종 이 RFC를 따르지 않고, 대신에 그들만의 특정한 형식을 가지고 있다.[12][13]

사용 예

SPF에 사용되는 TXT 레코드의 문자 문자열:

"v=spf1 ip4:190.0.2.0/24 ip4:190.51.100.123 ip6:2620:0:860:/46 a -all"

DMARC에 대한 사용 예:

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;"

사이트 확인에 사용:

"구글 사이트 검증=6P08Ow5E-8Q0m6vQ7FMAQAYIDPrkVV8fUf_7hZ4Qvc8"

사용자 지정 이메일 서비스에 사용:

_basons.example.com.IN TXT "pmBGN/7MjnfhTKUZ06Enq1PeGUaOkw8lGhcfwefcHU="

참고 항목

참조

  1. ^ Rich Rosenbaum (May 1993). RFC 1464 Using the Domain Name System To Store Arbitrary String Attributes. IETF. doi:10.17487/RFC1464. RFC 1464. Retrieved 2016-02-05.
  2. ^ a b Rosenbaum, R. "Using the Domain Name System To Store Arbitrary String Attributes". Tools.ietf.org. Retrieved 14 October 2018.
  3. ^ P. Mockapetris (November 1987). "TXT RDATA format". Domain names - implementation and specification. IETF. sec. 3.3.14. doi:10.17487/RFC1035. RFC 1035.
  4. ^ "Verify your site ownership". Retrieved 18 December 2018.
  5. ^ "Domain Verification". Facebook. Retrieved 18 December 2018.
  6. ^ Scott Kitterman (April 2014). "DNS Resource Records". Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. IETF. sec. 3.1. doi:10.17487/RFC7208. RFC 7208. Retrieved 2014-04-26.
  7. ^ "About TXT records". Google Apps Administration. Retrieved 2014-08-17.
  8. ^ S. Cheshire and M. Krochmal, Apple Inc. (February 2013). Multicast DNS. IETF. doi:10.17487/RFC6762. RFC 6762.
  9. ^ S. Cheshire and M. Krochmal, Apple Inc. (February 2013). DNS-Based Service Discovery. IETF. doi:10.17487/RFC6763. RFC 6763.
  10. ^ "rfc1035". datatracker.ietf.org. Retrieved 2021-08-15.
  11. ^ "rfc6763". datatracker.ietf.org. Retrieved 2021-08-15.
  12. ^ "DNS Record Verification". WebNots. Retrieved 21 December 2018.
  13. ^ "Amazon SES Domain Verification TXT Records". Amazon. Retrieved 21 December 2018.