目前已废弃。
【介绍】
域名预订业务，可以让预订者在域名过期之后释放到开放市场之后优先获取域名。域名预订业务并不影响当前注册人的权益，也不影响此域名的过期日期，以及此域名返回公开市场的日期。
如果此域名被当前注册人放弃，如果某人下单了域名预订业务，此域名将不会返回公开市场，而是将自动转移给此预订人，域名预订业务随即失效，预订人有30天时间对域名进行续费操作，否则此域名将会返回公开市场。
对于已经过期的域名，从域名过期之日起，注册局将使此域名处于 pendingDelete 状态持续90天，然后将会返回公开市场。
对于新近申请的域名，注册局将使此域名处于 pendingCreate 状态持续7天，然后将会返回公开市场。
对于预订成功的域名，注册局将使此域名处于 pendingCreate 状态持续30天，然后将会返回公开市场，除非预订者及时进行续费操作。
任何时候，一个域名仅允许一个预订业务。
【怎样购买域名预订业务】
可以通过我们的零售商，即注册商的网页界面，或者通过EPP接口实现购买域名预订业务。
域名预订业务必须一次性购买2年，可以续费或者转移，费用和域名续费（2年）相同。
【如果我提供域名抢注业务，有什么好处？】
如果你是一个提供域名抢注业务的注册商，注册局的域名预订业务将可以让你向客户提供比域名抢注业务更高的成功率。
【EPP接口】
预订业务支持所有常用的对象函数。为了更好地与其它注册局保持一致性，我们使用了标签 <future> 。
所有 <future> EPP请求都尽可能地合理地遵循相应的 <domain> EPP请求的语法和要求。
标签：补充EPP：POLL消息
如果预订成功，将执行一次标准域名转移，相应的接收方注册商将收到一个 EPP:POLL 消息“域名已转移到位”；释出方注册商将收到一个 EPP:POLL 消息“域名已转移出去”。
BACKORDER APPROVED 如果一个预订的支付请求被发起，但是在注册商账户中资金不足，这个请求将被挂起，直到账户中存在足够资金，支付请求将被处理。
BACKORDER RENEWED 如果一个预订的支付请求被发起，但是在注册商账户中资金不足，这个请求将被挂起，直到账户中存在足够资金，支付请求将被处理。
BACKORDER TRANSFERRED 如果一个预订的支付请求被发起，但是在注册商账户中资金不足，这个请求将被挂起，直到账户中存在足够资金，支付请求将被处理。
BACKORDER TRANSFERRED AWAY 如果预订成功，将执行一次标准域名转移到接收方注册商，这个消息将被发送给释出方注册商。
BACKORDER DELETED 曾经可用的预订在过期被删除的时候，将收到 epp:poll 消息。不可用的预订请求（比如账户中资金不足）在被删除的时候，将不会收到 epp:poll 消息。
BackOrder Fulfilled 注册商名下的一个预订成功地获得一个本该返回公开市场的域名。
标签：<future:check>
<future:check> 用来检测一组域名中哪些可以被预订。如果某个预订不能被支付，会有消息告知原因。很可能此域名尚未注册，或者已经存在预订业务，或者此域名的状态不允许预定被支付。
对于每个 <domain:check> ，<future:check> 必需字段是 <future:name>，可以存在多个，明确检测是否可以预定被支付。
示例： <future:check> 请求
<epp>
<command />
<check>
<future:check xmlns:future="http://www.dir.org/ xsd/future1.0”>
<future:name>^^.io</future:name>
<future:name>disk.io</future:name>
<future:name> 101.io</future:name>
<future:name>edrftgyhujikol.io</future:name>
<future:name>nic.io</future:name>
<future:name>disk.com</future:name>
</future:check>
</check>
<cltrid>ABC12345</cltrid>
</epp>
示例： <future:check> 响应
<epp>
<response>
<result code="1000">
<msg>命令成功完成</msg>
</result>
<resdata>
<future:chkdata xmlns:future="http://www.dir.org/xsd/future1.0”>
<future:cd>
<future:name avail='0'>^^.io</future:name>
<future:reason>域名验证失败</future:reason>
</future:cd>
<future:cd>
<future:name avail='1'>disk.io</future:name>
</future:cd>
<future:cd>
<future:name avail='0'>101.io</future:name>
<future:reason>域名已被注册</future:reason>
</future:cd>
<future:cd>
<future:name avail='0'>edrftgyhujikol.io</future:name>
<future:reason>域名尚未注册</future:reason>
</future:cd>
<future:cd>
<future:name avail='0'>nic.io</future:name>
<future:reason>域名禁止查询</future:reason>
</future:cd>
<future:cd>
<future:name avail='0'>disk.com</future:name>
<future:reason>域名后缀有误</future:reason>
</future:cd>
</future:chkdata><future:chkdata>
</future:chkdata></resdata>
<trid>
<cltrid>ABC12345</cltrid>
<svtrid>EPP4AA4.543683E4.0</svtrid>
</trid>
</response>
</epp>
标签：<future:create>
The only ?elds required in a <future:create> are <name>, <registrant> and
<period> – they follow the same format as for <domain:create>
<future:name> – required, domain name you wish to buy a back-order on.
<future:period> – required, time period you wish to future to last, currently
only 2 years is supported
<future:registrant> – required, the owner of this back-order, who will
become the owner of the domain name, should the back-order be suc-
cessful. The Admin, Technical and Billing contacts of the domain will
default to the EPP account holder.
<future:authInfo> – optional, set the AuthCode for transferring to another
registrar or directly to the customer’s control. It is recommended that
you do not set an AuthCode on a back order, until the owner speci?cally
requests it. The AuthCode is only used for transfers, so normally does
not need to be set. Use the XML “<future:pw/>” to clear the AuthCode.
A example <future:create> request…
示例： <future:create> 请求
<epp>
<command>
<create>
<future:create xmlns:future="http://www.dir.org/xsd/future1.0”>
<future:name>name.io</future:name>
<future:period unit="y">2</future:period>
<future:registrant>ref12345</future:registrant>
</future:create>
</create>
<clTRID>ABC12345</clTRID>
</command>
</epp>
<future:create> – response will contain …
<future:name> – domain name the back-order applies to
<future:crDate> – date & time the back-order was created
<future:exDate> – date & time the back-order expires
示例： <future:create> 响应
<epp>
<response>
<result code="1000">
<msg lang="en">Command completed successfully</msg>
</result>
<resData>
<future:creData xmlns:future="http://www.dir.org/xsd/future1.0”>
<future:name>name.io</future:name>
<future:crDate>20141009T13:32:45.0Z</future:crDate>
<future:exDate>20161009T13:32:45.0Z</future:exDate>
</future:creData>
</resData>
<trID>
<clTRID>ABC12345</clTRID>
<svTRID>EPP4A74.543680C6.0</svTRID>
</trID>
</response>
</epp>
标签：<future:info>
<future:info> will give the information about a back-order that is owned by
the registrar that issued the query. The only mandatory ?eld is <future:na-
me>, which speci?es the name of the domain which the back-order is held
against.
示例： <future:info> 请求
<epp>
<command>
<info>
<future:info xmlns:future="http://www.dir.org/xsd/future1.0”>
<future:name>name.io</future:name>
</future:info>
</info>
<clTRID>ABC12345</clTRID>
</command>
</epp>
The response will contain ..
– the domain name the back-order applies to
– the ROID of the domain, the back-order itself does not have its own ROID.
– the status of the back-order – this will either be ok – the back-order has been paid for and is active.
pendingCreate – the account has insuf?cient funds to pay for the back-order. It will be held for 7 days before being deleted.
pendingDelete – the Back-Order has expire. Back-Orders are held for 7 days after they have expired before they are deleted.
– the controlling registrar
– the date & time the back-order was created
– the date & time the back order expires – if the back-order has not yet been paid for, the expiry date will not have been incremented by the amount applied for, and so will be the same as the creation date.
– optional, the date & time the back-order was last updated. If it has never been updated, this item is omitted.
示例： <future:info> 响应
<epp>
<response>
<result code="1000">
<msg>Command completed successfully</MSG>
</result>
<resData>
<future:infData xmlns:future="http://www.dir.org/xsd/future1.0”>
<future:name>name.io</future:name>
<future:roid>DOM102210</future:roid>
<future:status s="pendingCreate">
<future:registrant>NIC941001</future:registrant>
<future:clID>NIC1500</future:clid>
<future:crDate>20141007T14:52:29.0Z</future:crdate>
<future:exDate>20141007T14:52:29.0Z</future:exdate>
</future:infData>
<trID>
<clTRID>ABC12345</clTRID>
<svTRID>EPP55EC.5436AF17.0</svTRID>
</trID>
</response>
</epp>
The only ?elds that can be updated in a back-order are the
and the back-order’s AuthCode ( –
which is used for transfers), so these are the only ?eld that can be speci-
?ed, in addition to the domain name the future refers to ().
The registrant can be speci?ed using either the registrar’s own reference
(), or the registries reference (ROID).
– optional, set the AuthCode for transferring to another
registrar or directly to the customer’s control. It is recommended that
you do not set an AuthCode on a back-order, until the owner speci?cally
requests it. The AuthCode is only used for transfers, so normally does
not need to be set. Use the XML “” to clear the AuthCode.
Here is an example request
name.io
NIC231147
ABC12345
Community DNS LLC Proprietary and Con?dential 14
———————– Page 15———————–
EPP
There is no results data for this type of request, so a typical response
would be …
Command completed successfully
ABC12345
EPP4A74.543680C6.0
A future:renew request should be issued to renew the expiry date on a bac-
k-order.
Expiry dates can be renewed up to 11 years in the future. As with domain
renewals, the current expiry date must be quoted so avoiding accidental
multiple renewals.
Community DNS LLC Proprietary and Con?dential 15
———————– Page 16———————–
EPP
You can only renew back-orders for which you are the controlling registrar.
exmaple.io
20150120
2
ABC12345
You can only renew back-orders for which you are the controlling registrar.
Command completed successfully
name.io
20160120T14:52:29.0Z
ABC12345
EPP55EC.5436AF17.0
The only transfer operation that is supported is op=“request”.
Back-orders can be transferred between registrars (or between a registrar
and an end user) by ?rst using the request to set an Auth-
Code on the back-order, then using the AuthCode to issue a transfer reqest.
As with domain names, when a back-order is transferred to a registrar, it
must also be accompanied by a renewal. The period of the renewal must
be speci?ed and currently only two years is supported.
If the AuthCode is correct, and the registrar’s account has suf?cient funds
to pay for the renewal, then the transfer will take place immediately, and the
AuthCode will be reset to unde?ned.
If there are insuf?cient funds, the transfer will be queued. If the AuthCode
is incorrect the request will be rejected immediately.
So a transfer request might look like this …
exmaple.io
2
SomeSecret
ABC12345
and a typical response might look like this …
Command completed successfully
exmaple.io
serverApproved
NIC1500
20141204T16:31:44.0Z
NIC1500
20141204T16:31:44.0Z
20170120T14:52:29.0Z
ABC12345
EPP55EC.5436AF17.0
If you are proposing to transfer control of a back-order from another regi-
strar, by EPP, you are allowed to see the details of the ower associated with
that back-order by using the following standard EPP syntax …
[contact-roid]
[authcode]
ABC-12345
Where [contact-roid] is the ROID of the contact object you wish to know
about, as reported by , [dom-id] is either the FQDN, or the
Domain ROID, of the back-order object to be transferred, and [authcode] is
the AuthCode of the back-order to be transferred. If you ?nd adding
roid=”[dom-id]” tricky, an alternative syntax to provide the domain & Auth-
Code is …
[dom-id]![authcode]
So, for example, if I wanted to know about the contact with the ROID of “NI-
C-334455”, who is the owner of the back-order for the domain “exmaple-na-
me.io”, which has the AuthCode “SomeAuthCode”, the XML might look like
this …
<contact:infoxmlns:contact=”urn:ietf:params:xml:ns:contact-1.0″>
NIC-334455
SomeAuthCode
ABC-12345
Only if the contact is a contact associated with the back-order speci?ed, and the AuthCode you have given is correct, will you be given the details of
a contact object for which you are not the controlling registrar. Using this technique, you can check if a person is the legitimate owner of a back-order
before initiating a transfer request.