TXT 记录如：

admin IN TXT "管理员,电话： xxxxxxxxxxx"

Jim IN TXT "邮件主机, 存放在xxx , 管理人：AAA"

mail IN TXT "contact: xxx@xxx.com"

也就是您可以设定 TXT ，以便使别人联繫到您

然而也会提升域名信箱传送外域邮件的成功率，之所以会提升成功率，是因为企业信箱公司把你的域名加入

白名单，以企业信箱公司的名义传送邮件，企业信箱公司不会互相禁止的。

----------------------------------------------------------

DNS-SD (Rendezvous) TXT record format

A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total length is indicated by the length given in the resource record header in the DNS message. There is no way to tell directly from the data alone how long it is (e.g. there is no length count at the start, or terminating NULL byte at the end).

The format of the data within a DNS TXT record is zero or more strings, packed together in memory without any intervening gaps or padding bytes for word alignment.

The format of each constituent string within the DNS TXT record is a single length byte, followed by 0-255 bytes of text data.

These format rules are defined in Section 3.3.14 of RFC 1035, and are not specific to DNS-SD. DNS-SD simply specifies a usage convention for what data should be stored in those constituent strings.

DNS-SD uses DNS TXT records to store arbitrary name/value pairs conveying additional information about the named service. Each name/value pair is encoded as it's own constituent string within the DNS TXT record, in the form "name=value". Everything up to the first '=' character is the name. Everything after the first '=' character to the end of the string (including subsequent '=' characters, if any) is the value. Specific rules governing names and values are given below. Each author defining a DNS-SD (Rendezvous) profile for discovering instances of a particular type of service should define the base set of name/value attributes that are valid for that type of service. Using this standardized name/value syntax within the TXT record makes it easier for these base definitions to be expanded later by defining additional named attributes. If an implementation sees unknown attribute names in a service TXT record, it SHOULD silently ignore them.

The TCP (or UDP) port number of the service, and target host name, are given in the SRV record. This information — target host name and port number — MUST NOT be duplicated using name/value attributes in the TXT record.

The intention of DNS-SD TXT records is convey a small amout of useful additional information about a service. Ideally it SHOULD NOT be necessary for a client to retrieve this additional information before it an usefully establish a connection to the service. For a well-designed TCP-based application protocol, it should be possible, knowing only the host name and port number, to open a connection to that listening process, and then perform version- or feature-negotiation to determine the capabilities of the service instance. For example, when connecting to an AppleShare server over TCP, the client enters into a protocol exchange with the server to determine which version of the AppleShare protocol the server implements, and which optional features or capabilities (if any) are available. For a well-designed application protocol, clients should be able to connect and use the service even if there is no information at all in the TXT record. In this case, the information in the TXT record should be viewed as a performance optimization — when a client discovers many instances of a service, the TXT record allows the client to know some rudimentary information about each instance without having open a TCP connection to each one and interrogate every service instance separately. Extreme care should be taken when doing this to ensure that the information in the TXT record is in agreement with the information retrieved by a client connecting over TCP.

There are legacy protocols which provide no feature negotiation capability, and in these cases it may be useful to convey necessary information in the TXT record. For example, when printing using the old Unix LPR (port 515) protocol, the LPR service provides no way for the client to determine whether a particular printer accepts PostScript, or what version of PostScript, etc. In this case it is appropriate to embed this information in the TXT record, because the alternative is worse — passing around written instructions to the users, arcane manual configuration of "/etc/printcap" files, etc.

The total size of a typical DNS-SD TXT record is intended to be small — 100 bytes or less.

In cases where more data is justified (e.g. LPR printing), keeping the total size under 400 bytes should allow it to fit in a single standard 512-byte DNS message. (This standard DNS message size is defined in RFC 1035.)

In extreme cases where even this is not enough, keeping size of the TXT record under 1300 bytes should allow it to fit in a single 1500-byte Ethernet packet.

Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this time.

The "Name" MUST be at least one character. Strings beginning with an '=' character (i.e. the name is missing) SHOULD be silently ignored.

The characters of "Name" MUST be printable US-ASCII values (0x20-0x7E), excluding '=' (0x3D).

Spaces in the name are significant, whether leading, trailing, or in the middle — so don't include any spaces unless you really indend that!

Case is ignored when interpreting a name, so "papersize=A4", "PAPERSIZE=A4" and "Papersize=A4" are all identical.

If there is no '=', then it is a boolean attribute, and is simply identified as being present, with no value.

When examining a TXT record for a given named attribute, there are therefore four broad categories of result which may be returned:

Attribute not present (Absent)

Attribute present, with no value (e.g. "Anon Allowed" — server allows anonymous connections)

Attribute present, with empty value (e.g. "Installed PlugIns=" — server supports plugins, but none are presently installed)

Attribute present, with non-empty value (e.g. "Installed PlugIns=JPEG,MPEG2,MPEG4")

Unless specified otherwise by a particular DNS-SD (Rendezvous) profile, a given attribute name may appear at most once in a TXT record. If a client receives a TXT record containing the same attribute name more than once, then the client SHOULD silently ignore all but the first occurrence of that attribute. For client implementations that process a DNS-SD TXT record from start to end, placing name/value pairs into a hash table, using the name as the hash table key, this means that if the implementation attempts to add a new name/value pair into the table and finds an entry with the same name already present, then the new entry being added should be silently discarded instead. For client implementations that retrieve name/value pairs by searching the TXT record for the requested name, they should search the TXT record from the start, and simply return the first matching name they find.

Each author defining a DNS-SD (Rendezvous) profile for discovering instances of a particular type of service should define the interpretation of these different kinds of result. For example, for some keys, there may be a natural boolean interpretation:

Absent implies 'false'

Present with no value implies 'true'

For other keys it may be sensible to define other semantics, such as:

Present with value implies that value. E.g. "Color=4" for a four-color ink-jet printer, or "Color=6" for a six-color ink-jet printer.

Present with emply value implies 'false'. E.g. Not a color printer.

Absent implies 'Unknown'. E.g. A print server connected to some unknown printer where the print server doesn't actually know if the printer does color or not — which gives a very bad user experience and should be avoided wherever possible.

(Note that this is a hypothetical example, not an example of real name/value keys for printing.)

As a general rule, names that contain no dots are defined as part of the open-standard definition written by the person or group defining the DNS-SD (Rendezvous) profile for discovering that particular service type. Vendor-specific extensions should be given names of the form "keyname.company.com=value", using a domain name legitimately registered to the person or organization creating the vendor-specific key. This reduces the risk of accidental conflict if different organizations each define their own vendor-specific keys.

If there is an '=', then everything after the first '=' to the end of the string is the value. The value can contain any eight-bit values including '='. Leading or trailing spaces are part of the value, so don't put them there unless you intend them to be there. Any quotation marks around the value are part of the value, so don't put them there unless you intend them to be part of the value.

The value is opaque binary data. Often the value for a particular attribute will be US-ASCII (or UTF-8) text, but it is legal for a value to be any binary data. For example, if the value of a key is an IPv4 address, that address should simply be stored as four bytes of binary data, not as a variable-length 7-15 byte ASCII string giving the address represented in textual dotted decimal notation.

Generic debugging tools should generally display all attribute values as if they were UTF-8 text, except for attributes where the debugging tool has embedded knowledge that the value is some other kind of data.

Authors defining DNS-SD (Rendezvous) profiles SHOULD NOT convert binary attribute data types into printable text (e.g. using hexadecimal, Base64 or UU encoding) merely for the sake of making the data be printable text when seen in a generic debugging tool. Doing this simply bloats the size of the TXT record, without truly making the data any more understandable to someone looking at it in a generic debugging tool.

-------------------------------------------------------------------

| 0x0A | name=value | 0x08 | paper=A4 | 0x12 | Rendezvous Is Cool |

-------------------------------------------------------------------

It is recommended that authors defining DNS-SD (Rendezvous) profiles include an attribute of the form "version=xxx" in their definition, and require it to be the first name/value pair in the TXT record. This information in the TXT record can be useful help clients maintain backwards compatibility with older implementations if becomes necessary to change or update the specification over time. Even if the profile author doesn't anticipate the need for any future incompatible changes, having a version number in the specification provides useful insurance should incompatible changes become unavoidable. Clients should ignore TXT records with a version number higher (or lower) than the version(s) they know how to interpret.

Do not assume that all current Apple products using Rendezvous present a model example of how to structure Rendezvous TXT records. Like all companies, Apple sometimes works under severe time pressure, and some of the current Apple Rendezvous products were written in a great hurry. Consequently you should not assume that any particular behaviour of a current Apple Rendezvous product necessarily constitutes an endorsement that that behaviour is correct, or an acceptable model to emulate.

Jaguar's DNSServiceDiscovery.h APIs are, like most Unix APIs, based on C strings. How then does a client encode multiple pascal strings containing name/value pairs using a single C string? The answer is that Jaguar's DNSServiceDiscovery.h APIs use ASCII 1 as the boundary marker between constituent strings within the DNS TXT record. This value can be inserted into a C string using '\001', as shown below:

DNSServiceRegistrationCreate(..., "a=1\001b=2\001c=3", ...);The results returned from DNSServiceResolverResolve() return the TXT data similarly encoded, so that each name/value pair except the last is followed by ASCII 1, and the last is followed (as usual for a C string) by ASCII 0.

See SamplemDNSClient.c in the Darwin Open Source Code for simple sample code showing how to do this.

This encoding as C strings means that binary values containing the value 0 or 1 cannot be used with this API. For clients wishing to create binary values in TXT records, the registration can be created with an empty TXT record, and then the DNSServiceRegistrationUpdateRecord() call can be used to update the TXT record, as shown below.

DNSServiceRegistrationUpdateRecord(ref, 0, len, buffer, ttl);The buffer passed to this call is used as-is without interpretation or modification, so it is the client's responsibility to ensure that it is a properly formatted DNS TXT record.

To obtain the raw binary-format TXT record associated with a service, without interpretation or modification, the client should use the standard Unix res_query() call. Unfortunately, in OS X 10.2 and 10.2.1, the res_query() call does not work with local multicast Rendezvous names (names ending in ".local."). This bug has been fixed, and is planned for an upcoming OS X update.

Client applications that really really need to obtain raw binary-format TXT records for local multicast Rendezvous names right right now, and can't wait for the OS X update, can embed the Darwin mDNSResponder source code directly in their application, and use that API do do the record lookup. This course of action is recommended only for the very bold (and impatient).

Currently only one key is defined for _http._tcp service; the "path" key. The value of the path key is everything that comes after the optional port number in an HTTP URL, as defined in section 3.2.2 of RFC 2616 ("HTTP/1.1"):

http URL

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]If you are writing a web browser, then the path key gives you the text that should appear directly after "GET " in an HTTP "GET" request.

If you are writing a tool to generate a URL to send to a web browser for display, then you should generate a URL of the form shown below, where {host} and {port} are obtained from the information in the service's SRV record, and {path} is obtained from the "path" key in the TXT record.

http://{host}:{port}{path}The path key in the TXT record MUST include the leading slash of the abs_path, e.g. the following is a legal DNS-SD TXT record for an _http._tcp service:

path=/thepage.htmlIf the path key is missing, or present with no value or empty value, or otherwise invalid, then the path is assumed to be "/".

-----------------------------google机器翻译-----------------

DNS的的SD （会合） TXT等记录格式

一般格式规则的DNS TXT等记录

1 DNS的TXT等纪录，可达到65535 （ 0xffff ）位元组长。总长度的长度在DNS信息中给定的头记录资源里。没有办法直接从数据本身判断它有多长（在开始没有记录字元长度或者最后的终止字元是空字元时） 。

该格式的数据在一个DNS的TXT等记录是零或以上的字元串，包装在一起，在记忆，没有任何干预的差距或填充位元组为词对齐。

该格式的每个组成字元串内部的DNS TXT等记录，是一个单一的长度位元组，然后0-255位元组的文本数据。

这些格式规则，是指在第3.3.14的了RFC 1035 ，而并没有特定的DNS -政府统计处。 DNS的可持续发展，根本还明确规定了使用公约哪些数据应存放在这些组成串。

DNS的TXT等记录格式规则的使用在DNS -统计处（会合）

DNS的可持续使用DNS TXT等记录存储任意名称/值对的输送更多地了解命名服务。每个名称/值对编码后，因为它本身的制宪字元串内部的DNS TXT等纪录，在该表"的名称=值" 。一切行动第一' = '字是名字。一切后，第一个' = '字，以字元串的结尾（包括后来的' = '字，如果有的话） ，是价值。具体规则的名称和价值是47482 。每个作者确定的DNS -统计处（会合）剖面发现的事例某一特定类型的服务应界定基础集的名称/值属性的有效期为这种类型的服务。使用本规範的名称/值的语法与TXT等记录，使得它更容易为这些基地的定义，将予以扩大，后来通过定义额外的命名属性。如果一个执行看见未知属性名称，在一个服务TXT等记录，它应该悄悄地忽略它们。

TCP （或UDP ）连线埠号码的服务，并且目标主机名称，是考虑到在srv记录。这一信息-目标主机名称和连线埠号-绝不能重複使用在文本记录中的名称/值属性。

意图的DNS -统计处TXT等记录，是传达一个小量的有益补充资料服务。最理想的，不应该有必要为客户取回这笔额外资料，然后它是一个有益的建立连线，以提供服务。一个设计良好的TCP基于套用协定的，它应该有可能，只知道主机名称和连线埠号，打开一个连线，收听过程中，然后再演出版本或功能谈判，以确定能力服务例如。举例来说，当连线到appleshare伺服器TCP时，客户签订了协定交换与伺服器，以确定哪个版本的appleshare议定书伺服器执行的，并且可选的特性或功能（如果有的话）可供选择。一个设计良好的套用协定，客户应能连线上，并使用该服务，因此，即使没有这方面的资料都在上班时间记录。在这种情况下，信息在TXT的记录应被看作是一个性能最佳化-当客户发现许多一项服务， T XT等记录在案，使客户了解一些最起码的信息，比如每不必打开一个T CP连线，以每一个和审问每个服务实例都分开。极端应注意的时候，这样做是为了确保资料在上班时间纪录，是在协定与信息检索客户端连线在TCP 。

有遗留议定书，其中规定，没有特色的谈判能力，并且在这些情况下，它可能是有用的，以传达必要的信息，在TXT的记录。举例来说，当印刷使用旧的Unix车牌识别（连线埠515 ）议定书中，车牌识别服务，不提供任何方式为客户确定某一特定印表机接受后记中，或有什幺版本的后记中，等等，在这种情况下，是适当的嵌入这一信息在上班时间记录的，因为另一种方法是坏-通过围绕在批示中向用户，难懂的手工配置的" /等/ p rintcap"档案等。

DNS的职务TXT等记录尺寸

警察总人数的一个典型的DNS -统计处TXT等纪录，是打算以小-1 00位元组或更少。

的情况下，更多的数据是合理的（如车牌识别列印） ，使总人数为400位元组，应该允许它适合在一个单一的标準为512位元组的DNS信息。 （此标準的DNS信息，其大小界定了RFC 1035 ） 。

在极端情况下，甚至这样是不够的，保持规模的TXT等记录下1300个位元组应该允许它适合在一个单一的1500个位元组的乙太网包。

利用上班时间记录大于1300个位元组，不建议在这个时候。

规则名称在DNS -统计处名称/值对的

"姓名"必须至少有一个字元。字元串以一个' = '开始的（即名字就是失蹤） ，应静静地忽视了。

人物的"姓名" ，都必须列印，美的ASCII值（ 0x20 - 0x7e ） ，但不包括' = ' （ 0x3d ） 。

位中的名称是显着的，无论是领导，拖尾，或在中间-所以不包括任何空间，除非你真的i ndend！

案件时，忽视了诠释一个名字，所以"纸张大小为A4规定" ， "纸张大小为A4规定" ， "纸张大小为A4规定" ，都是一致的。

如果没有' = ' ，那实在是一个布尔属性，并简单地被确定为当前，没有任何价值。

当研究TXT等记录某一特定的命名属性，因此，当局目前4大类的结果，可能会返回：

属性没有出席（缺席）

属性目前，没有任何价值（如"别名允许" -伺服器允许匿名连线）

属性当前，随着空值（例如， "安装外挂程式= " -伺服器支持外挂程式，但都不是，目前已安装）

属性当前，随着非空值（例如， "安装外挂程式= JPEG格式，兼容MPEG2 ， MPEG4影片" ）

除另有规定外，由某一特定的DNS -统计处（会合）简介，给定属性名称可能出现在最一次在TXT记录。如果客户收到TXT等记录含有相同的属性名称，多于一次，那幺客户应该默默全部忽略，但第一次发生这种属性。为客户实现这一进程的DNS -统计处TXT等记录从开始到结束，配售名称/值对的一个哈希表，使用化名，因为哈希表的关键，这意味着，如果执行试图加入一个新的名称/值对到表，并认为一个条目具有相同的名字已经存在，那幺新入职正补充说：应该悄悄地被丢弃。为客户建置取出名称/值对通过检索TXT等记录被请求的名字，他们应该查找TXT等记录，从一开始，并简单地返回第一个匹配的名字，他们找到。

每个作者确定的DNS -统计处（会合）剖面发现的事例某一特定类型的服务，一定要解释这些不同种的结果。例如，对于某些按键，有可能是一个自然的布尔解释：

缺席意味着'假'

目前没有任何价值，就意味着'真'

对于其他按键，它可以合理界定其他语义，例如：

目前与价值意味的价值。例如： "颜色= 4 " ，一台四色喷墨印表机，或"颜色= 6 " ，接受为期六个月的彩色喷墨印表机。

目前与emply价值，就意味着'假' 。例如：不是彩色印表机。

缺席意味着'不明' 。例如：列印伺服器连线到一些未知的印表机那里列印伺服器实际上并不知道如果印表机没有颜色或不-这给人一个极坏的用户体验，并应儘可能避免。

（注：这是一个假设的例子，而不是一个例子，真实姓名/价值按键，可列印） 。

作为一般规则，名字包含任何圆点，是指部分的开放式标準的定义写，由一个人或一组确定的DNS -统计处（会合）剖面发现，特别是服务型。供应商的具体扩展应给予名字的形式" keyname.company.com =价值" ，用一个域名合法注册到个人或组织创造卖方特定关键。这就降低了风险，意外冲突，如果有不同的组织，每一个确定自己的供应商指定的键。

规则的价值观，在DNS的职务名称/值对的

如果存在一个' = ' ，则一切后，第一个' = ' ，以字元串的结尾是价值。该值可以包含任何8位值包括' = ' 。领导或拖尾位部分的价值，所以不要把它们存在，除非你打算在他们那里。任何引号围绕价值的部分的价值，所以不要把它们存在，除非你打算在他们获得部分的价值。

该值是不透明的二进制数据。常值为某一特定属性，将美的ASCII （或对UTF - 8 ）文本，但它是合法的一个值为任何的二进制数据。例如，如果值的一个关键，是一个IPv4地址，地址应该简单地被储存了4个位元组的二进制数据，而不是作为一个可变长度7-15位元组ASCII字元串赋予地址所代表的词句虚线小数点乐谱。

通用调试工具一般应显示出所有属性值，因为如果他们的UTF - 8文本中，除属性那里调试工具嵌入式知识的价值，是一些其他类型的数据。

作者界定的DNS -统计处（会合）概况不应转换成二进制属性的数据类型到列印文本（例如，使用十六进制， base64或UU的编码）仅仅是为了使数据得到列印文本的时候，看到在一个通用的调试工具。这样做，根本bloats大小的TXT等记录，没有真正让数据更可以理解为有人看，它在一个通用的调试工具。

例如TXT等记录包含三个名称/值对的

-------------------------------------------------- --------

| 0x0a |姓名=价值| 0x08 |档案=的A4 | 0x12 | Rendezvous技术是酷|

-------------------------------------------------- --------

版本标籤

因此建议作者界定的DNS -统计处（会合）概况，包括一个属性的形式"版本= xxx "时，在其定义，并要求其作出相应的第一名称/值对在上班时间纪录。这一信息在TXT记录，可有效协助客户保持向后兼容旧的实现，如果必要变更或更新规格随着时间的推移。即使简介作者并没有预料到有必要为今后的任何不相容的变化，有一个版本号码，在规範中提供了有用的保险应不相容的变化成为不可避免的。客户应该忽视TXT等记录一个版本号码更高（或更低） ，比本（ ） ，他们知道如何解释。

传统的实现

不要想当然地认为，目前所有的苹果电脑产品採用交会，目前的典範如何构建交会TXT等记录。象所有的公司，苹果电脑，有时作品受到严厉的时间压力，以及目前的一些苹果交会产品写在忙。因此，你不应该假设任何特定行为的，目前苹果交会产品不一定构成背书表示，这种行为是正确的话，还是可以接受的模式来学习的好榜样。

OS X的宣传短片

捷豹的dnsservicediscovery.h API的是，最喜欢的Unix宣传声带，基于C字元串。怎幺那幺客户编码多Pascal字元串包含名称/值对使用一个单一的c字元串？答案是捷豹的dnsservicediscovery.h API的使用ASCII的1作为界桩之间组成的字元串内部的DNS TXT等记录在案。此值可被插入一个C字元串使用' \ 001 ' ，如下所示：

dnsserviceregistrationcreate (..., " = 1 \ 001b = 2 \ 001c = 3 " ， … … ） ，结果回来dnsserviceresolverresolve （ ）返回该TXT等数据同样编码，使每一个名称/值对除最后一个是其次是ASCII码1 ，而最后一个是遵循（正常的C字元）的ASCII 0 。

见samplemdnsclient.c在达尔文开原始码，发现一些简单的样例代码，显示如何做到这一点。

这种编码为C字元串意味着二进制值含有值为0或1 ，不能用这个API 。为客户欲创造二元价值观，在上班时间的记录，登记，可以创造一个空洞TXT等记录在案，然后dnsserviceregistrationupdaterecord （ ）的调用，可以用来更新TXT等记录，如下图所示。

dns service registration update record （档号， 0 ，时限，缓冲区，对焦TTL ） ;缓冲区通过了这一号召，是用来作为-是未经解释或修改，所以这是客户端的责任，以确保它是一个正确格式化的DNS TXT等记录在案。

获得原始二进制格式的TXT等记录与服务，不设口译或修改，客户应使用标準的Unix res_query （ ）的调用。不幸的是，在OS X的10.2和10.2.1 ， res_query （ ）的调用不工作，与当地组播交会的姓名（名称结束的"本地" ） 。这个bug已定，并计画在即将推出的OS X的最新情况。

用户端套用程式真的真的需要取得原始二进制格式的TXT等档案，为当地组播交会的姓名权，目前并不能等待，为OS X的更新，可以嵌入达尔文mdnsresponder原始码直接在套用中，并用它的API这样做的记录查找。这一行动是建议只适用于非常大胆（不耐烦） 。

DNS的职务TXT等记录_http._tcp服务

目前只有一个，关键是界定为_http._tcp服务的"路"的关键。价值之路，关键在于这一切之后可选的连线埠号，在一个HTTP网址，界定在第3.2.2了RFC 2616 （ " http/1.1 " ） ：

http_URL = "http:" "//" 主机 [ ":" 连线埠 ] [ abs_path [ "?" 质疑 ] 如果你是写一个网路浏览器，那幺路径关键给你的案文应直接出现后， "过关" ，在一个HTTP "GET"的要求。

如果你是写作的一个工具，以生成一个网址传送给Web浏览器为显示器，那幺你应该生成一个网址的形式如下图所示，其中{主机}和{连线埠}，得到了从信息服务的srv记录（ ）是从"路" ，关键在TXT纪录。

http:// {主机} ： （港口） {路径}之路关键在上班时间记录必须包括大中华地区领先斜线的abs_path ，例如：以下是一个合法的DNS -统计处上班时间记录为_http._tcp服务：

路径= / thepage.htmlif之路，关键是下落不明，或本没有价值或空值，否则无效，那幺路径，假设为" / " 。