TXT record

Last updated

A TXT record (short for text record) is a type of resource record in the Domain Name System (DNS) used to provide the ability to associate arbitrary text with a host or other name, such as human readable information about a server, network, data center, or other accounting information. [1]

Contents

It is also often used in a more structured fashion to record small amounts of machine-readable data into the DNS.

Background

A domain may have multiple TXT records associated with it, provided the DNS server implementation supports this. [1] Each record can in turn have one or more character strings. [2] Traditionally these text fields were used for a variety of non-standardised uses, such as a full company or organisation name, or the address of a host.

Some examples of TXT usage:

Using TXT records to store data for different purposes is not without problems. The DNS protocol specifies that when a client queries for a specific record type (e.g., TXT) for a certain domain name (e.g., example.com), all records of that type must be returned in the same DNS message. That may lead to large transactions with lots of "unnecessary" information being transferred and/or uncertainty about which TXT record to use. There are two ways around this: to specify a domain name prefix to be used when using TXT records for a specific purpose (e.g., _domainkey.example.com – in the DKIM case) or to create a new record type entirely. The former is "easy" because it doesn't require any changes to the DNS. The latter is sometimes considered "cleaner" as it matches the design of the DNS database model better. In the past, creating new record types was often avoided since it was a complicated procedure in the IETF. The reluctance lingers with some people despite the process having been replaced by a much lighter and quicker one.

Format

The structure of the TXT record is specified in RFC 1035 [2] as follows. Note that the specification is silent on the subject of character encoding of the text string. It explicitly states that the interpretation of the string is context dependent, and that the data is treated as binary inside the DNS. Later specifications (e.g., RFC 6763 [8] – DNS used for service discovery) may require the use of specific encodings for specific purposes.

The RDATA section may contain multiple consecutive occurrences of (TXT Length + TXT). Data Length is the length of them all combined.

Record Structure
FieldTypeDescription
NameLabel SequenceThe domain name, encoded as a sequence of labels.
Type2-byte IntegerThe record type. In this case will be 0x0010 as the Type is TXT.
Class2-byte IntegerThe class.
TTL4-byte IntegerTime-To-Live, i.e. how long a record can be cached before it should be requeried.
Data Length2-byte IntegerLength of the record type-specific data.
TXT Length1-byte IntegerLength of TXT string.
TXTStringThe character-string.
TXT response example from example.com
This is the hex returned as part of the DNS response from example.com when queried for TXT records. 
0000344881a000010002000000010765786100106d706c6503636f6d0000100001c00c0000201000010000545f000c0b763d737066310030202d616c6cc00c001000010000545f0000402120386a356e66716c6432307a70637900507238786a7730796463667139726b38680060676d0000290200000000000000


As part of this response, there are two text records, the first of which is shown below (beginning at byte 54).

0000c00c001000010000545f000c0b763d730010706631202d616c6c

This decodes as follows:

Record Structure
FieldHexValue
Name0xc00cexample.com (This is a jump directive to an earlier label)
Type0x0010TXT
Class0x0001IN
TTL0x0000545f21599 (5 hours, 59 minutes, 59 seconds)
Data Length0x000c12
TXT Length0x0b11
TXT0x 76 3d 73 70 66 31 20 2d 61 6c 6cv=spf1 -all

As unstructured text, organisations can use the TXT string in any way they define, for example:

example.com.INTXT"This domain name is reserved for use in documentation"

RFC   1464 defines a structured format that can be used to define attributes and their values in a single record, [1] as in these examples:

host.widgets.com.INTXT"printer=lpr5"sam.widgets.com.INTXT"favorite drink=orange juice"

In practice, services using TXT records often do not follow this RFC, but instead have their own specific format. [9] [10]

Example usage

The character string from a TXT record used for SPF:

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

An example of use for DMARC:

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

Use for site verification:

"google-site-verification=6P08Ow5E-8Q0m6vQ7FMAqAYIDprkVV8fUf_7hZ4Qvc8"

Use for custom email service:

_amazonses.example.com.INTXT"pmBGN/7MjnfhTKUZ06Enqq1PeGUaOkw8lGhcfwefcHU="

Brand Indicators for Message Identification (BIMI):

default._bimi TXT "v=BIMI1; l=https://example.com/image.svg; a=https://example.com/image/certificate.pem"

See also

Related Research Articles

Various anti-spam techniques are used to prevent email spam.

Zero-configuration networking (zeroconf) is a set of technologies that automatically creates a usable computer network based on the Internet Protocol Suite (TCP/IP) when computers or network peripherals are interconnected. It does not require manual operator intervention or special configuration servers. Without zeroconf, a network administrator must set up network services, such as Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS), or configure each computer's network settings manually.

Sender Policy Framework (SPF) is an email authentication method which ensures the sending mail server is authorized to originate mail from the email sender's domain. This authentication only applies to the email sender listed in the "envelope from" field during the initial SMTP connection. If the email is bounced, a message is sent to this address, and for downstream transmission it typically appears in the "Return-Path" header. To authenticate the email address which is actually visible to recipients on the "From:" line, other technologies such as DMARC must be used. Forgery of this address is known as email spoofing, and is often used in phishing and email spam.

The Extensible Provisioning Protocol (EPP) is a flexible protocol designed for allocating objects within registries over the Internet. The motivation for the creation of EPP was to create a robust and flexible protocol that could provide communication between domain name registries and domain name registrars. These transactions are required whenever a domain name is registered or renewed, thereby also preventing domain hijacking. Prior to its introduction, registries had no uniform approach, and many different proprietary interfaces existed. While its use for domain names was the initial driver, the protocol is designed to be usable for any kind of ordering and fulfilment system.

Sender ID is an historic anti-spoofing proposal from the former MARID IETF working group that tried to join Sender Policy Framework (SPF) and Caller ID. Sender ID is defined primarily in Experimental RFC 4406, but there are additional parts in RFC 4405, RFC 4407 and RFC 4408.

example.com Domain name reserved for documentation purposes and as an example of the use of domain names

The domain names example.com, example.net, example.org, and example.edu are second-level domain names in the Domain Name System of the Internet. They are reserved by the Internet Assigned Numbers Authority (IANA) at the direction of the Internet Engineering Task Force (IETF) as special-use domain names for documentation purposes. The domain names are used widely in books, tutorials, sample network configurations, and generally as examples for the use of domain names. The Internet Corporation for Assigned Names and Numbers (ICANN) operates websites for these domains with content that reflects their purpose.

In computer networks, a reverse DNS lookup or reverse DNS resolution (rDNS) is the querying technique of the Domain Name System (DNS) to determine the domain name associated with an IP address – the reverse of the usual "forward" DNS lookup of an IP address from a domain name. The process of reverse resolving of an IP address uses PTR records. rDNS involves searching domain name registry and registrar tables. The reverse DNS database of the Internet is rooted in the .arpa top-level domain.

Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.

Forward-confirmed reverse DNS (FCrDNS), also known as full-circle reverse DNS, double-reverse DNS, or iprev, is a networking parameter configuration in which a given IP address has both forward (name-to-address) and reverse (address-to-name) Domain Name System (DNS) entries that match each other. This is the standard configuration expected by the Internet standards supporting many DNS-reliant protocols. David Barr published an opinion in RFC 1912 (Informational) recommending it as best practice for DNS administrators, but there are no formal requirements for it codified within the DNS standard itself.

The name localhost is reserved by the Internet Engineering Task Force (IETF) as a domain name label that may not be installed as a top-level domain in the Domain Name System (DNS) of the Internet.

MARID was an IETF working group in the applications area tasked to propose standards for email authentication in 2004. The name is an acronym of MTA Authorization Records In DNS.

The Sender Rewriting Scheme (SRS) is a scheme for bypassing the Sender Policy Framework's (SPF) methods of preventing forged sender addresses. Forging a sender address is also known as email spoofing.

In computing, Author Domain Signing Practices (ADSP) is an optional extension to the DKIM E-mail authentication scheme, whereby a domain can publish the signing practices it adopts when relaying mail on behalf of associated authors.

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in email, a technique often used in phishing and email spam.

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, phishing email, email scams and other cyber threat activities.

Vouch by Reference (VBR) is a protocol used in Internet mail systems for implementing sender certification by third-party entities. Independent certification providers vouch for the reputation of senders by verifying the domain name that is associated with transmitted electronic mail. VBR information can be used by a message transfer agent, a mail delivery agent or by an email client.

Spam reporting, more properly called abuse reporting, is the action of designating electronic messages as abusive for reporting to an authority so that they can be dealt with. Reported messages can be email messages, blog comments, or any kind of spam.

DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.

Murray S. Kucherawy is a computer scientist, mostly known for his work on email standardization and open source software.

References

  1. 1 2 3 R. Rosenbaum (May 1993). Using the Domain Name System To Store Arbitrary String Attributes. Network Working Group. doi: 10.17487/RFC1464 . RFC 1464.Experimental.
  2. 1 2 P. Mockapetris (November 1987). DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. Network Working Group. doi: 10.17487/RFC1035 . STD 13. RFC 1035.Internet Standard 13. Obsoletes RFC  882, 883 and 973. Updated by RFC  1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2137, 2181, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 5936, 5966, 6604, 7766, 8482, 8490 and 8767.
  3. ↑ "Verify your site ownership" . Retrieved 18 December 2018.
  4. ↑ "Domain Verification". Facebook. Retrieved 18 December 2018.
  5. ↑ S. Kitterman (April 2014). Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. Internet Engineering Task Force. doi: 10.17487/RFC7208 . ISSN   2070-1721. RFC 7208.Proposed Standard. Obsoletes RFC   4408. Updated by RFC   7372, RFC   8553, and RFC   8616.
  6. ↑ "About TXT records". Google Apps Administration. Retrieved 2014-08-17.
  7. ↑ S. Cheshire; M. Krochmal (February 2013). Multicast DNS. Internet Engineering Task Force. doi: 10.17487/RFC6762 . ISSN   2070-1721. RFC 6762.Proposed Standard.
  8. 1 2 S. Cheshire; M. Krochmal (February 2013). DNS-Based Service Discovery. Internet Engineering Task Force. doi: 10.17487/RFC6763 . ISSN   2070-1721. RFC 6763.Proposed Standard. Updated by RFC  8553.
  9. ↑ "DNS Record Verification". WebNots. 2 July 2013. Retrieved 21 December 2018.
  10. ↑ "Amazon SES Domain Verification TXT Records". Amazon. Retrieved 21 December 2018.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.