主要特點
TXT 記錄如：
admin IN TXT "管理員,電話： xxxxxxxxxxx"
txt記錄Jim IN TXT "郵件主機, 存放在xxx , 管理人：AAA"
mail IN TXT "contact: [email protected]"
也就是您可以設定 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.
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 TXT record format rules for use in DNS-SD (Rendezvous)
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.
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 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.
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!
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.
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 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.
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 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.
Legacy Implementations
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.
OS X APIs
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).
DNS-SD TXT Records for _http._tcp service
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之路，關鍵是下落不明，或本沒有價值或空值，否則無效，那么路徑，假設為" / " 。
