txt记录

主要特点

TXT 记录如：

admin IN TXT 管理员，电话： xxxxxxxxxxx

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

mail IN TXT contact: xxx@xxx.com

也就是您可以设置 TXT ，以便使别人联系到您

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

白名单，以企业邮箱公司的名义发送邮件，企业邮箱公司不会互相屏蔽的。

DNS-SD (Rendezvous) TXT record format

General format rules for DNS TXT records

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).

txt记录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.

The 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 tho constituent strings.

DNS TXT record format rules for u in DNS-SD (Rendezvous)

DNS-SD us DNS TXT records to store arbitrary name/value pairs conveying additional information about the named rvice. 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 subquent '=' 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 rvice should define the ba t of name/value attributes that are valid for that type of rvice. Using this standardized name/value syntax within the TXT record makes it easier for the ba definitions to be expanded later by defining additional named attributes. If an implementation es unknown attribute names in a rvice TXT record, it SHOULD silently ignore them.

The TCP (or UDP) port number of the rvice, 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 uful additional information about a rvice. Ideally it SHOULD NOT be necessary for a client to retrieve this additional information before it an ufully establish a connection to the rvice. For a well-designed TCP-bad 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 rvice instance. For example, when connecting to an AppleShare rver over TCP, the client enters into a protocol exchange with the rver to determine which version of the AppleShare protocol the rver implements, and which optional features or capabilities (if any) are available. For a well-designed application protocol, clients should be able to connect and u the rvice even if there is no information at all in the TXT record. In this ca, the information in the TXT record should be viewed as a performance optimization — when a client discovers many instances of a rvice, 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 rvice instance parately. 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 the cas it may be uful to convey necessary information in the TXT record. For example, when printing using the old Unix LPR (port 515) protocol, the LPR rvice provides no way for the client to determine whether a particular printer accepts PostScript, or what version of PostScript, etc. In this ca it is appropriate to embed this information in the TXT record, becau the alternative is wor — passing around written instructions to the urs, arcane manual configuration of /etc/printcap files, etc.

DNS-SD TXT record size

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

In cas 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 cas 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.

Rules for Names in DNS-SD Name/Value pairs

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!

Ca 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 prent, 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 prent (Abnt)

Attribute prent, with no value (e.g. Anon Allowed — rver allows anonymous connections)

Attribute prent, with empty value (e.g. Installed PlugIns= — rver supports plugins, but none are prently installed)

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

Unless specified otherwi 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 prent, then the new entry being added should be silently discarded instead. For client implementations that retrieve name/value pairs by arching the TXT record for the requested name, they should arch 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 rvice should define the interpretation of the different kinds of result. For example, for some keys, there may be a natural boolean interpretation:

Abnt implies 'fal'

Prent with no value implies 'true'

For other keys it may be nsible to define other mantics, such as:

Prent 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.

Prent with emply value implies 'fal'. E.g. Not a color printer.

Abnt implies 'Unknown'. E.g. A print rver connected to some unknown printer where the print rver doesn't actually know if the printer does color or not — which gives a very bad ur 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 rvice 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.

Rules for values in DNS-SD Name/Value pairs

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 reprented 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, Ba64 or UU encoding) merely for the sake of making the data be printable text when en 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.

Example TXT record containing three name/value pairs

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

Version tag

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 uful 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 uful 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.

Legacy Implementations

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

OS X APIs

Jaguar's DNSServiceDiscovery.h APIs are, like most Unix APIs, bad 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 u ASCII 1 as the boundary marker between constituent strings within the DNS TXT record. This value can be inrted into a C string using '001', as shown below:

DNSServiceRegistrationCreate(..., a=1001b=2001c=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 ud 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 ud to update the TXT record, as shown below.

DNSServiceRegistrationUpdateRecord(ref, 0, len, buffer, ttl);The buffer pasd to this call is ud 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 rvice, without interpretation or modification, the client should u 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 u that API do do the record lookup. This cour of action is recommended only for the very bold (and impatient).

DNS-SD TXT Records for _http._tcp rvice

Currently only one key is defined for _http._tcp rvice; 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 ction 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 browr, 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 nd to a web browr for display, then you should generate a URL of the form shown below, where {host} and {port} are obtained from the information in the rvice's SRV record, and {path} is obtained from the path key in the TXT record.

{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 rvice:

path=/thepage.htmlIf the path key is missing, or prent with no value or empty value, or otherwi 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 -统计处（会合）概况不应转换成二进制属性的数据类型到打印文本（例如，使用十六进制， ba64或UU的编码）仅仅是为了使数据得到打印文本的时候，看到在一个通用的调试工具。这样做，根本bloats大小的TXT等记录，没有真正让数据更可以理解为有人看，它在一个通用的调试工具。

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

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

版本标签

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

传统的实现

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

OS X的宣传短片

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

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

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

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

dns rvice 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纪录。

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

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