epp interface manual - etusivu · pdf file1 (50) epp interface version author date comment 1.0...

1 (50)

EPP interface

Version Author Date Comment

1.0 Viestintävirasto 21.9.2015

1.0 Viestintävirasto 21.10.2015 Update to Contact

object; type, role, isfinnish, org, form, name.

Disclose voice

unsupported in Contact.

1.0 Viestintävirasto 29.4.2016 Added example request for company contact.

Removed gender from contact.

1.0 Viestintävirasto 2.5.2016 Updated Check Contact command

1.0 Viestintävirasto 13.6.2016 Removed AuthInfo from Contact object

1.0 Viestintävirasto 24.8.2016 Fixed typo. Old: "For contact role 1,

<contact:legalemail> is mandatory"

New: "For contact role 5,

<contact:legalemail> is mandatory"

1.0 Viestintävirasto 31.8.2016 Correct port is: 700

1.0 Viestintävirasto 15.12.2016 Corrected examples Domain object transfer, Domain

object create, Domain object delete. Auto renew example added

1.0 Viestintävirasto 13.7.2017 Fixed scheduled

delete example on page 21. Fixed delete cancel example on page 21.

1.0 Viestintävirasto 27.10.2017 Update to ContactInfo and

2 (50)

Login examples

1.0 Viestintävirasto 27.10.2017 Added a statement regarding session management.

1.0 Viestintävirasto 27.10.2017 AutorenewDate has been added to the

Domain Info response example.

3 (50)

Content

1 General ..................................................................................................... 5

2 Security and Restrictions .......................................................................... 6

2.1 Traffic Security ................................................................................. 6

2.2 EPP Restrictions ................................................................................ 6

3 Extensions ................................................................................................ 7

3.1 Hello ............................................................................................... 7

3.2 Login ............................................................................................... 8

3.3 Logout ............................................................................................. 9

3.4 Poll ............................................................................................... 10

3.5 Check Balance ................................................................................ 12

3.6 Auto Renew .................................................................................... 13

4 Domain Objects ...................................................................................... 14

4.1 Check ............................................................................................ 14

4.2 Info ............................................................................................... 15

4.3 Transfer ......................................................................................... 17

4.4 Create ........................................................................................... 19

4.5 Delete ........................................................................................... 21

4.6 Update .......................................................................................... 24

4.7 Renew ........................................................................................... 28

5 Contact Objects ...................................................................................... 29

5.1 Check ............................................................................................ 29

5.2 Info ............................................................................................... 30

5.3 Create ........................................................................................... 32

5.4 Delete ........................................................................................... 34

5.5 Update .......................................................................................... 35

6 Host Objects ........................................................................................... 32

6.1 Check ............................................................................................ 38

6.2 Info ............................................................................................... 39

6.3 Create ........................................................................................... 40

6.4 Delete ........................................................................................... 41

6.5 Update .......................................................................................... 42

7 Use cases ................................................................................................ 43

7.1 Register Domain Name .................................................................... 43

7.2 Registrar Change ............................................................................ 46

7.3 Registrant Change .......................................................................... 48

4 (50)

7.4 Registry Lock .................................................................................. 49

5 (50)

1 General

Finnish Communications Regulatory Authority’s EPP-interface is based on RFC documents RFC 5734, RFC 5730, RFC 5731, RFC 5732, RFC 5733 and RFC 4310. The interface includes some restrictions and extensions that will be mentioned in this

document per operation. This document also consists of working examples for each operation. Further information on field specific functionality should be checked from the

RFC documents. Each domain –related query must be performed, where the domain name is in the form

“domain.fi”. Domain names in the form “www.domain.fi”, “www.domain” or “domain” are not allowed. If the domain name consists the letter ä, ö or å, the domain name

must be converted into punycode.

Error messages outside of the RFC documentation are mentioned in the table below:

Error code Message

7010 Maximum session dutation exceeded

7020 Session idle time exceeded

7030 Password already used previously

7040 System maintenance

6 (50)

2 Security and Restrictions

2.1 Traffic Security

EPP interface listens to port 700 and is protected with SSL certificate authentication.

The caller must have a valid certificate that should be saved into the calling system. SSL certificate is attached to the valid EPP user and each request is authorized via an

account / certificate combination. The caller should also add an IP-address from which the requests will be made from.

The specified IP-address will be allowed access through a firewall.

2.2 EPP Restrictions

The restriction values mentioned below are preliminary and FICORA is able to change the values at any time.

EPP interface receives at maximum 30 messages for each user per minute. If the limit

is exceeded, the responses will be returned with delay. Session maximum length is 45 hours and the session is cut if no requests are made within 30 minutes of the previous request. There can be a maximum of 4 open sessions per user.

Sessions are handled per user in the backend systems. Thus, Login and Logout -

commands should be executed with caution. For example, if TCP connection 1 performs Login for user A, TCP connection 2 no longer needs to perform login for user A, as the session is already open. The same applies to the Logout -command. Logging out from

connection 1 will also close the connection for connection 2.

FICORA may lock EPP functionality for any user, if any suspicious activity is monitored.

7 (50)

3 Extensions

3.1 Hello

Based on RFC 5730.

Full request:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

</epp>

Example response:

<epp xmlns:obj="urn:ietf:params:xml:ns:obj-1.0"

xmlns="urn:ietf:params:xml:ns:epp-1.0">

<svID>Ficora EPP Server</svID>

<objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>

<objURI>urn:ietf:params:xml:ns:nsset-1.2</objURI>

<objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>

<objURI>urn:ietf:params:xml:ns:keyset-1.3</objURI>

<extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>

<extURI>urn:ietf:params:xml:ns:domain-ext-1.0</extURI>

</svcExtension>

</svcMenu>

</access>

</purpose>

</recipient>

</retention>

</statement>

</dcp>

</greeting>

</epp>

8 (50)

3.2 Login

Based on RFC 5730.

Full request:

<login>

<clID>AsiakasX</clID>

</options>

<svcs>

<objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>

<objURI>urn:ietf:params:xml:ns:host-1.0</objURI>

<objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>

<extURI> urn:ietf:params:xml:ns:secDNS-1.1</extURI>

<extURI> urn:ietf:params:xml:ns:domain-ext-1.0</extURI>

</svcExtension>

</svcs>

</login>

</command>

</epp>

Example response: <?xml version="1.0" encoding="UTF-8" standalone="no"?>

<msg>Command completed successfully</msg>

</result>

<trID>

</trID>

</response>

</epp>

9 (50)

3.3 Logout

Based on RFC 5730.

Full request:

</command>

</epp>

Example response:

<msg>Command completed successfully; ending session</msg>

</result>

<trID>

</trID>

</response>

</epp>

10 (50)

3.4 Poll

Based on RFC 5730.

Example of Poll Req request:

</command>

</epp>

Example of Poll Req response:

<?xml version="1.0" encoding="utf-8"?>

<msg>Command completed succesfully; ack to dequeue</msg>

</result>

<msg>Domain created</msg>

</msgQ>

<obj:trnData>

<obj:name>xioc9</obj:name>

</obj:trnData>

</resData>

<trID>

</trID>

</response>

</epp>

11 (50)

Example of Poll Ack request:

<clTRID>hvidk</clTRID>

</command>

</epp>

Example of Poll Ack response:

<trID>

<clTRID>hvidk</clTRID>

<svTRID>hvidk</svTRID>

</trID>

</response>

</epp>

12 (50)

3.5 Check Balance

Check balance is an extension, where a user can ask for the current account balance. The request contains and empty <balance> element and the response will contain the balance value and the timestamp.

Full request:

<check>

</check>

</command>

</epp>

Example response:

</result>

</resData>

<trID>

</trID>

</response>

</epp>

13 (50)

3.6 Auto Renew

Auto renew is an extension for the <domain:renew> message. In the extension, the request may be given a <domain:autorenew> element with values 0 or 1. Value 1 sets

the auto renewal process on to the specific domain name and removes the auto renewal process. Automatic renewal renews a domain name 30 days before expiration.

Before renewing, the ISP will be messaged a Poll message that the renewing will happen in x days.

Marking a domain for delete will cancel auto renew operations.

Domain info returns will tell if auto renew is set and when the next auto renew

operation will occur.

If a domain name is transferred to another ISP, auto renew will be canceled.

Auto renew example request:

<renew>

<domain:autorenew xmlns:domain="urn:ietf:params:xml:ns:domain-

<domain:name>example.fi</domain:name>

<domain:value>1</domain:value>

</domain:autorenew>

</renew>

</command>

</epp>

14 (50)

4 Domain Objects

4.1 Check

Based on RFC 5731.

Full request:

<check>

<domain:check

xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">

<domain:name>example.net</domain:name>

<domain:name>example.org</domain:name>

</domain:check>

</check>

</command>

</epp>

Example response:

</result>

<domain:chkData

<domain:cd>

<domain:name avail="1">example.fi</domain:name>

</domain:cd>

<domain:cd>

<domain:name avail="0">example.net</domain:name>

<domain:reason>In use</domain:reason>

</domain:cd>

<domain:cd>

<domain:name avail="1">example.org</domain:name>

</domain:cd>

</domain:chkData>

</resData>

<trID>

</trID>

</response>

</epp>

15 (50)

4.2 Info

Based on RFC 5731.

Deviations from RFC:

Authorization is derived from object sponsorship. If the requestor is not the object sponsor, the requestor will receive a stripped

response, where the name identifier and object sponsor identifier are returned.

Full request:

<info>

<domain:info

<domain:name hosts="all">example.com</domain:name>

<domain:authInfo>

<domain:pw>2fooBAR</domain:pw>

</domain:authInfo>

</domain:info>

</info>

</command>

</epp>

Example response:

</result>

<domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">

<domain:registrylock>1</domain:registrylock>

<domain:autorenew>1</domain:autorenew>

<domain:autorenewDate>2018-09-

25T12:11:29.433</domain:autorenewDate>

<domain:status s="Granted"/>

<domain:registrant>jd1234</domain:registrant>

<domain:contact type="admin">C2000</domain:contact>

<domain:contact type="tech">C4000</domain:contact>

<domain:ns>

<domain:hostObj>ns1.example.com</domain:hostObj>

<domain:hostObj>ns1.example.net</domain:hostObj>

</domain:ns>

<domain:clID>ClientX</domain:clID>

<domain:crID>ClientY</domain:crID>

<domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>

<domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>

<domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>

<domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>

16 (50)

<domain:authInfo>

</domain:authInfo>

<domain:dsData>

<domain:keyTag>12345</domain:keyTag>

<domain:alg>3</domain:alg>

<domain:digestType>1</domain:digestType>

<domain:digest>38EC35D5B3A34B33C99B</domain:digest>

<domain:keyData>

<domain:flags>257</domain:flags>

<domain:protocol>233</domain:protocol>

<domain:pubKey>AQPJ////4Q==</domain:pubKey>

</domain:keyData>

</domain:dsData>

<domain:dsData>

<domain:keyTag>12345</domain:keyTag>

<domain:digestType>1</domain:digestType>

<domain:digest>38EC35D5B3A34B33C99B</domain:digest>

<domain:keyData>

<domain:flags>257</domain:flags>

<domain:protocol>233</domain:protocol>

<domain:pubKey>AQPJ////4Q==</domain:pubKey>

</domain:keyData>

</domain:dsData>

</domain:infData>

</resData>

<trID>

</trID>

</response>

</epp>

17 (50)

4.3 Transfer

Based on RFC 5731.

Only op=”request” is possible. All transfers are accepted or rejected at once. Transfer related ”query”, ”approve” and ”reject” operations are not supported.

<domain:period/> is not supported. Changing the registrar does not renew the

domain name or affect it in any way. When taking new name servers into use, any possible DS-records will be

removed. Transfer key is fixed-period and single use. It will be removed after transfer or

when the expiration time has surpassed.

Changing a domain name registrar is not possible, if the domain name has registry lock set. In such an event, the registrar must first remove the registry

lock from the domain. acDate and exDate fields are not returned.

Full request:

<domain:transfer

<domain:authInfo>

</domain:authInfo>

<domain:ns>

</domain:ns>

<domain:hostAttr>

<domain:hostName>ns1.example.net</domain:hostName>

<domain:hostAddr ip="v4">192.0.2.2</domain:hostAddr>

<domain:hostAddr

ip="v6">1080:0:0:0:8:800:200C:417A</domain:hostAddr>

</domain:hostAttr>

<domain:hostAttr>

</domain:hostAttr>

</domain:transfer>

</transfer>

</command>

</epp>

18 (50)

Example response:

<msg>Command completed successfully </msg>

</result>

<obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj">

<obj:name>example.fi</obj:name>

<obj:trStatus>Transferred</obj:trStatus>

<obj:reID>ClientX</obj:reID>

<obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>

<obj:acID>ClientY</obj:acID>

</obj:trnData>

</resData>

<trID>

</trID>

</response>

</epp>

19 (50)

4.4 Create

Based on RFC 5731 and RFC5910.

<domain:registrant> is mandatory <domain:period> is mandatory maxSigLife –field is not saved

Full request:

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<domain:create

<domain:name>esimerkki.fi</domain:name>

<domain:period unit="y">2</domain:period>

<domain:ns>

<domain:hostObj>ns1.esimerkki.fi</domain:hostObj>

<domain:hostObj>ns2.esimerkki.fi</domain:hostObj>

<domain:hostAttr>

<domain:hostAddr ip="v6">1080:0:0:0:8:800:200C:417A</domain:hostAddr>

</domain:hostAttr>

<domain:hostAttr>

</domain:hostAttr>

</domain:ns>

<domain:registrant>haltijantunnus</domain:registrant>

<domain:contact type="admin">admin</domain:contact>

<domain:contact type="tech">tekninen</domain:contact>

<domain:authInfo>

<domain:pw>salasana</domain:pw>

</domain:authInfo>

</domain:create>

</create>

<secDNS:create

xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">

<secDNS:maxSigLife>604800</secDNS:maxSigLife>

<secDNS:dsData>

<secDNS:keyTag>12345</secDNS:keyTag>

<secDNS:alg>3</secDNS:alg>

<secDNS:digestType>1</secDNS:digestType>

<secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>

</secDNS:dsData>

</secDNS:create>

</extension>

</command>

</epp>

20 (50)

Example response:

</result>

<domain:creData

<domain:crDate>2014-04-03T22:00:00.0Z</domain:crDate>

</domain:creData>

</resData>

<trID>

<clTRID>abcde12345</clTRID>

</trID>

</response>

</epp>

21 (50)

4.5 Delete

Based on RFC 5731.

If the message does not contain an extension, the domain name will be set to patent period.

If an extension and the tags within are set, the date field cannot be empty or in

any other form than mentioned below. Extension namespace domain-ext contains the tags schedule and cancel.

schedule contains delDate tag, which should contain the scheduled time for domain delete. delDate cannot be set to more than one year from now or beyond the current expiration time.

When the Cancel tag is given, the message will be handled as domain name delete removal, where the delDate is not considered. In this case, the domain

name should still be in patent period and in state removed or awaiting removal. In the end, the domain name will return to granted state, but the expiration time will not be affected.

Example request with only delete command:

<domain:delete xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">

</domain:delete>

</delete>

</command>

</epp>

22 (50)

Example request with scheduled delete time:

</domain:delete>

</delete>

<domain-ext:delete xmlns:domain-

ext="urn:ietf:params:xml:ns:domain-ext-1.0">

<domain-ext:schedule>

<domain-ext:delDate>2015-01-01T00:00:00.0Z</domain-

ext:delDate>

</domain-ext:schedule>

</domain-ext:delete>

</extension>

</command>

</epp>

Example request, where domain delete is being cancelled:

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <epp

</domain:delete>

</delete>

<domain-ext:delete xmlns:domain-ext="urn:ietf:params:xml:ns:domain-

ext-1.0">

<domain-ext:cancel/>

</domain-ext:delete>

</extension>

</command>

</epp>

23 (50)

Example response, where domain is deleted or delete is canceled:

<?xml version="1.0" encoding="UTF-8"?>

</result>

<trID>

</trID>

</response>

</epp>

Example response, when domain delete is scheduled:

<?xml version="1.0" encoding="UTF-8"?>

<msg>Command completed successfully; action pending</msg>

</result>

<trID>

</trID>

</response>

</epp>

24 (50)

4.6 Update

Based on RFC 5731 and RFC 5910.

DS-record is given with the <secDNS:update> extension.

DS-record maxSignLife is not supported. DS-records urgent is not in use.

A contact can have a single role only, and the role must adhere to the value saved in the system.

During registrant contact transfer, the register number cannot change.

If all of the name servers are being removed from a domain name, the DS-records will also be removed.

Domain registry lock can be update via the <registrylock> element. Registrylock command allows the following operation types: activate, deactivate,

requestkey

o Activate sets the domain name registry lock attribute, so that the domain name cannot be updated until the lock is removed. Activation requires 2-3

phone numbers in the request. o Deactivate removes the domain name registry lock attribute, so that the

domain name can be updated again. Removal requires a valid authorization key. The key is requested with requestkey request.

o Requestkey generates and sends an authorization key to predetermined

phone numbers as SMS messages. The request should have the wanted sequence number(s). The key is valid for one day.

Update domain –command allows a single operation per request. The possible operations and priorities are mentioned below.

Operations is priority order: Registrylock –operations

Transfer key update Authorization key request to user Contact updates

Name server updates DS-record updates

25 (50)

Full request:

<domain:update

<domain:add>

<domain:ns>

<domain:hostAttr>

<domain:hostAddr

</domain:hostAttr>

<domain:hostAttr>

</domain:hostAttr>

</domain:ns>

<domain:contact type="tech">mak21</domain:contact>

<domain:contact type="admin">mak21</domain:contact>

<domain:status s="clientHold" lang="en">Payment

overdue.</domain:status>

</domain:add>

<domain:rem>

<domain:ns>

<domain:hostAttr>

<domain:hostAddr

</domain:hostAttr>

<domain:hostAttr>

</domain:hostAttr>

</domain:ns>

<domain:contact type="tech">C4000</domain:contact>

<domain:contact type="admin">C2000</domain:contact>

<domain:status s="clientUpdateProhibited"/>

<domain:authInfo>

<domain:pw>2BARfoo</domain:pw>

<domain:pwregistranttransfer>2BARfoo</domain:pwregistranttransfer>

</domain:authInfo>

</domain:rem>

<domain:chg>

<domain:registrant>C5000</domain:registrant>

<domain:authInfo>

<domain:pw>2BARfoo</domain:pw>

<domain:pwregistranttransfer>2BARfoo</domain:pwregistranttransfer>

26 (50)

</domain:authInfo>

<domain:registrylock type="activate">

<domain:smsnumber>+2314s12312</domain:smsnumber>

<domain:numbertosend>1423</domain:numbertosend>

<domain:authkey>7867896f896sadf9786</domain:authkey>

</domain:registrylock>

</domain:chg>

</domain:update>

</update>

<secDNS:update xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">

<secDNS:rem>

<secDNS:dsData>

<secDNS:digest>38EC35D5B3A34B33C99B</secDNS:digest>

<secDNS:keyData>

<secDNS:flags>257</secDNS:flags>

<secDNS:protocol>233</secDNS:protocol>

<secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>

</secDNS:keyData>

</secDNS:dsData>

<secDNS:dsData>

<secDNS:keyData>

</secDNS:keyData>

</secDNS:dsData>

<secDNS:all>true</secDNS:all>

</secDNS:rem>

<secDNS:add>

<secDNS:dsData>

<secDNS:keyData>

</secDNS:keyData>

</secDNS:dsData>

<secDNS:dsData>

27 (50)

<secDNS:keyData>

</secDNS:keyData>

</secDNS:dsData>

</secDNS:add>

<secDNS:chg>

</secDNS:chg>

</secDNS:update>

</extension>

</command>

</epp>

Example response:

<msg>Command completed succesfully</msg>

</result>

<trID>

</trID>

</response>

</epp>

28 (50)

4.7 Renew

Based on RFC 5731.

Full request:

<renew>

<domain:renew

<domain:curExpDate>2014-04-03</domain:curExpDate>

</domain:renew>

</renew>

</command>

</epp>

Example response:

</result>

<domain:renData

</domain:renData>

</resData>

<trID>

</trID>

</response>

</epp>

29 (50)

5 Contact Objects

5.1 Check

Based on RFC 5733.

Full request:

<check>

<contact:check

xmlns: contact ="urn:ietf:params:xml:ns: contact -1.0">

<contact:id>username1</contact:id>

</contact:check>

</check>

</command>

</epp>

Example response:

</result>

<contact:chkData

xmlns: contact ="urn:ietf:params:xml:ns: contact -1.0">

<contact:cd>

<contact:name avail="1">example.fi</contact:name>

</contact:cd>

<contact:cd>

<contact:reason>In use</ contact:reason>

</contact:cd>

<contact:cd>

</contact:cd>

</contact:chkData>

</resData>

<trID>

</trID>

</response>

</epp>

30 (50)

5.2 Info

Based on RFC 5733.

Authorization is derived from object sponsorship. If the requestor is not the object sponsor, the requestor will receive a stripped

response, where the name identifier and object sponsor identifier are returned.

Full request: <?xml version="1.0" encoding="UTF-8" standalone="no"?>

<info>

<contact:info xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">

<contact:id>sh8013</contact:id>

</contact:info>

</info>

</command>

</epp>

Example response:

</result>

<contact:infData xmlns:contact="urn:ietf:params:xml:ns:contact-

<contact:id>sh8013</contact:id>

<contact:role>5</contact:role>

<contact:type>1</contact:type>

<contact:postalInfo type="loc">

<contact:isfinnish>1</contact:isfinnish>

<contact:firstname></contact:firstname>

<contact:lastname></contact:lastname>

<contact:name>HR</contact:name>

<contact:org>Example Inc</contact:org>

<contact:birthDate>2005-04-03</contact:birthDate>

<contact:identity>123423A123F</contact:identity>

<contact:registernumber>1234312SFAD-5</contact:registernumber>

<contact:addr>

<contact:street>123 Example Dr.</contact:street>

<contact:street>Suite 100</contact:street>

<contact:city>Dulles</contact:city>

<contact:sp>VA</contact:sp>

<contact:pc>20166-6503</contact:pc>

<contact:cc>US</contact:cc>

</contact:addr>

</contact:postalInfo>

31 (50)

<contact:voice x="1234">+358401231234</contact:voice>

<contact:email>jdoe@example.com</contact:email>

<contact:legalemail>jdoe@example.com</contact:legalemail>

<contact:clID>ClientY</contact:clID>

<contact:crID>ClientX</contact:crID>

<contact:crDate>1999-04-03T22:00:00.0Z</contact:crDate>

<contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>

<contact:disclose flag="0">

<contact:voice/>

<contact:email/>

<contact:address/>

</contact:disclose>

</contact:infData>

</resData>

<trID>

</trID>

</response>

</epp>

32 (50)

5.3 Create

Based on RFC 5733.

<contact:authInfo> is not supported <fax> is not saved Only address type ”loc” is supported

A person’s name is written to the fields <contact:firstname> and <contact:lastname>

Company name is written to field <contact:org> and department or contact person is written to <contact:name>. contact:org is mandatory for a company.

There must be at least one <contact:street> element and a maximum of three

<contact:sp> is not mandatory, other address fields are mandatory Contact role is mandatory with value between 2-5. Descriptions below.

Contact type is mandatory with value between 0-7. Descriptions below. For contact role 5, <contact:legalemail> is mandatory, for others

<contact:email> is mandatory

For a Finnish person, (role=5, type=0, isfinnish=1) <contact:identity> is mandatory and is validated as a Finnish identity

For a Finnish company, (role =5, type =1-7, isfinnish=1) <contact:registernumber> is mandatory and is validated

For a foreign person, (role =5, type =0, isfinnish=0) <contact:birthDate> is mandatory and is validated

For a foreign company, (role =5, type =1-7, isfinnish=0)

<contact:registernumber> is mandatory <contact:disclose> flag can be set to email. Address disclosure can be set only if

the contact is a person. Disclose voice is not supported. Disclose = 1 = public data.

Validation rules: <contact:street> : 2-255 characters

<contact:city> : 2-128 characters <contact:org> : 2-255 characters <contact:sp> : 2-128 characters (not mandatory)

<contact:pc> : o Allowed characters for Finnish contact: 0-9, length 5 characters

o Allowed characters for a foreign contact: 0-9,A-Z, space, length 2-16 characters

<contact:voice> : Allowed characters are +, 0-9, first sign must be '+', country

code must be provided with actual existing code and local part must match the country specific rules.

<contact:email> : Email format validaiton <contact:legalemail> : Email format validaiton <contact:cc> : Allowed characters A-Z, length 2 merkkiä, must comply to an

existing country code <contact:isfinnish> : 0 or 1

<contact:firstname> : 1-255 characters <contact:lastname> <contact:org> : 2-255 characters

33 (50)

Type values:

<contact:role> : o 2 = Admin

o 3 = Reseller o 4 = TechnicalContact o 5 = Registrant/Holder

<contact:type> :

o 0 = Private person o 1 = Company o 2 = Association

o 3 = Institution o 4 = Political party

o 5 = Municipality o 6 = Government o 7 = Public community

Full request:

<contact:create

xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">

<contact:id>1</contact:id>

<contact:firstname>Essi</contact:firstname>

<contact:lastname>Esimerkki Oy</contact:lastname>

<contact:org>Esimerkki Oy</contact:org>

<contact:birthDate>2005-04-03T22:00:00.0Z</contact:birthDate>

<contact:registernumber>1234312SFAD-5</contact:registernumber>

<contact:addr>

<contact:street></contact:street>

</contact:addr>

<contact:fax>+04040as</contact:fax>

<contact:addr/>

<contact:email/>

</contact:disclose>

</contact:create>

34 (50)

</create>

</command>

</epp>

5.4 Delete

Based on RFC 5733.

Contact cannot be removed if it is related to any domain.

Contact cannot be removed if you have not created it.

Example request: <?xml version="1.0" encoding="UTF-8" standalone="no"?>

<contact:delete xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">

<contact:id>C5000</contact:id>

</contact:delete>

</delete>

</command>

</epp>

35 (50)

5.5 Update

Based on RFC 5733.

Deviations from RFC: <contact:authInfo> is not supported

<fax> is not saved Only address type ”loc” is supported A person’s name is written to the fields <contact:firstname> and

<contact:lastname> Company name is written to field <contact:org> and department or contact

person is written to <contact:name>. contact:org is mandatory for a company. There must be at least one <contact:street> element and a maximum of three <contact:sp> is not mandatory, other address fields are mandatory

Contact type is mandatory with value between 0-7. Descriptions below. For contact role 5, <contact:legalemail> is mandatory, for others

<contact:email> is mandatory For a Finnish person, (role=5, type=0, isfinnish=1) <contact:identity> is

mandatory and is validated as a Finnish identity

For a Finnish company, (role =5, type =1-7, isfinnish=1) <contact:registernumber> is mandatory and is validated

For a foreign person, (role =5, type =0, isfinnish=0) <contact:birthDate> is mandatory and is validated (Gender: 1=male, 2=female)

For a foreign company, (role =5, type =1-7, isfinnish=0) <contact:registernumber> is mandatory

<contact:disclose> flag can be set to email. Address disclosure can be set only if

the contact is a person. Disclose voice is not supported. Disclose = 1 = public data.

Update may be targeted to only one field While updating your address, you should provide all address information To remove a non-mandatory field, provide an empty field. For eg <contact:sp />

Validation rules:

<contact:street> : 2-255 characters <contact:city> : 2-128 characters <contact:org> : 2-255 characters

<contact:sp> : 2-128 characters (not mandatory) <contact:pc> :

o Allowed characters for Finnish contact: 0-9, length 5 characters o Allowed characters for a foreign contact: 0-9,A-Z, space, length 2-16

characters

<contact:voice> : Allowed characters are +, 0-9, first sign must be '+', country code must be provided with actual existing code and local part must match the

country specific rules. <contact:email> : Email format validaiton <contact:legalemail> : Email format validaiton

<contact:cc> : Allowed characters A-Z, length 2 merkkiä, must comply to an existing country code

<contact:isfinnish> : 0 or 1 <contact:firstname> : 1-255 characters <contact:lastname>

<contact:org> : 2-255 characters

36 (50)

Type values:

<contact:role> : o 2 = Admin

o 3 = Reseller o 4 = TechnicalContact o 5 = Registrant/Holder

<contact:type> :

o 0 = Private person o 1 = Company o 2 = Association

o 3 = Institution o 4 = Political party

o 5 = Municipality o 6 = Government o 7 = Public community

Full request:

<contact:update

<contact:id>C5000</contact:id>

<contact:add>

</contact:add>

<contact:rem>

</contact:rem>

<contact:chg>

<contact:firstname>John</contact:firstname>

<contact:lastname>Doe</contact:lastname>

<contact:org>Example Inc.</contact:org>

<contact:birthDate>2005-04-03T22:00:00.0Z</contact:birthDate>

<contact:registernumber>1234312-5</contact:registernumber>

<contact:addr>

<contact:street>Suite 100</contact:street>

</contact:addr>

<contact:fax>+04040as</contact:fax>

37 (50)

<contact:voice/>

<contact:email/>

<contact:addr/>

</contact:disclose>

</contact:chg>

</contact:update>

</update>

</command>

</epp>

38 (50)

6 Host Objects

6.1 Check

Based on RFC 5732.

Full request:

<check>

<host:check

xmlns: host ="urn:ietf:params:xml:ns: host -1.0">

<host:name>ns1.example.fi</host:name>

</host:check>

</check>

</command>

</epp>

Example response:

</result>

<host:chkData

xmlns: host ="urn:ietf:params:xml:ns: host -1.0">

<host:cd>

<host:name avail="1">ns1.example.fi</host:name>

</host:cd>

<host:cd>

<host:reason>In use</host:reason>

</host:cd>

<host:cd>

</host:cd>

</host:chkData>

</resData>

<trID>

</trID>

</response>

</epp>

39 (50)

6.2 Info

Based on RFC 5732.

trDate is not returned Full request:

<info>

<host:info xmlns:host="urn:ietf:params:xml:ns:host-1.0">

</host:info>

</info>

</command>

</epp>

Example response:

</result>

<host:infData xmlns:host="urn:ietf:params:xml:ns:host-1.0">

<host:addr ip="v4">192.0.2.2</host:addr>

<host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>

<host:clID>ClientY</host:clID>

<host:crID>ClientX</host:crID>

<host:crDate>1999-04-03T22:00:00.0Z</host:crDate>

<host:upDate>1999-12-03T09:00:00.0Z</host:upDate>

</host:infData>

</resData>

<trID>

</trID>

</response>

</epp>

40 (50)

6.3 Create

Based on RFC 5732.

- If you create a .fi name server, you should be the domains managing registrar. - If the domain does not have a managing registrar, IP addresses will not be

saved.

- Name servers can have a maximum of ten IP addresses. - IP address is mandatory, if the name server is the zone of a domain name.

Full request:

<host:create

xmlns:host="urn:ietf:params:xml:ns:host-1.0">

<host:name>ns1.esimerkki.fi</host:name>

<host:addr ip="v6">::1</host:addr>

</host:create>

</create>

</command>

</epp>

Example response:

</result>

<host:creData

<host:name>ns1.esimerkki.com</host:name>

<host:crDate>2014-06-26T22:00:00.0Z</host:crDate>

</host:creData>

</resData>

<trID>

</trID>

</response>

</epp>

41 (50)

6.4 Delete

Based on RFC 5732.

- If you are removing a .fi name server, you will have to be the managing

registrar of that domain name and the name server cannot be related to other

domain names. For example, if you are the managing registrar to domain name foobar.fi, you may remove the name server ns1.foobar.fi if it is not related to

any other domain name.

Full request:

<host:delete xmlns:host="urn:ietf:params:xml:ns:host-1.0">

<host:name>ns1.example.com</host:name>

</host:delete>

</delete>

</command>

</epp>

Example response:

</result>

<trID>

</trID>

</response>

</epp>

42 (50)

6.5 Update

Based on RFC 5732.

Name server change (host:chg) is not supported.

Name server status change (host:status) is not supported. Only the managing registrar of the parent zone domain can change the IP

address. A name server can have a maximum of ten IP addresses.

Full request:

<host:update

<host:name>ns1.esimerkki.fi</host:name>

<host:add>

<host:status s="clientUpdateProhibited"/>

</host:add>

<host:rem>

</host:rem>

</host:update>

</update>

</command>

</epp>

Example response:

</result>

<trID>

</trID>

</response>

</epp>

43 (50)

7 Use cases

7.1 Register Domain Name

In this case, we are creating a new domain name without name servers and the

registrant user is a new person contact. Here the following actions are required:

Login Contact create Domain create

Login:

<login>

<clID>AsiakasX</clID>

</options>

<svcs>

<objURI>urn:ietf:params:xml:ns:obj1</objURI>

<extURI>http://custom/obj1ext-1.0</extURI>

</svcExtension>

</svcs>

</login>

</command>

</epp>

44 (50)

Contact create (Finnish Person):

<contact:create

<contact:firstname>Etunimi</contact:firstname>

<contact:lastname>Sukunimi</contact:lastname>

<contact:identity>031294-311W</contact:identity>

<contact:addr>

<contact:street>stree1</contact:street>

<contact:city>city</contact:city>

<contact:pc>00100</contact:pc>

<contact:cc>FI</contact:cc>

</contact:addr>

<contact:voice>+35844400044</contact:voice>

<contact:legalemail>contact@asd.awd</contact:legalemail>

</contact:create>

</create>

</command>

</epp>

Contact create (Finnish company): <?xml version="1.0" encoding="UTF-8" standalone="no"?>

<contact:create

<contact:org>Testi Oy</contact:org>

<contact:registernumber>2834721-7</contact:registernumber>

<contact:addr>

<contact:street>street 1</contact:street>

<contact:city>city</contact:city>

<contact:pc>00001</contact:pc>

<contact:cc>FI</contact:cc>

</contact:addr>

<contact:voice>+46844400044</contact:voice>

<contact:email>contact@sadf.com</contact:email>

<contact:legalemail>contact@sadf.com</contact:legalemail>

</contact:create>

</create>

</command>

</epp>

45 (50)

Domain create:

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<domain:create

<domain:registrant>usernamefromcontactcreateresponse</domain:registrant>

<domain:authInfo>

<domain:pw>salasana</domain:pw>

</domain:authInfo>

</domain:create>

</create>

</command>

</epp>

46 (50)

7.2 Registrar Change

Domain name registrar (ISP) change happens by creating a transfer key, providing it to the new registrar and ultimately the new registrar should transfer the domain to itself.

Registrar transfer key expires in one month after creating the key. In this example, the new registrar adds new name servers to the domain that is transferred. If the domain

had DNSSec in use prior to transfer, they will be removed. Removal of registrar transfer key is also depicted below.

Password requirements: 8-64 characters.

At least one small letter. At least one capital letter. At least one number.

At least one special character: "!\"#$%'()*+,-./:;=@[\\]^_'{|}~"

Creating registrar transfer key: (domain:chg): <?xml version="1.0" encoding="UTF-8" standalone="no"?>

<domain:update

<domain:chg>

<domain:authInfo>

<domain:pw>newPassword1!</domain:pw>

</domain:authInfo>

</domain:chg>

</domain:update>

</update>

</command>

</epp>

New registrar sends transfer request (domain:transfer): <?xml version="1.0" encoding="UTF-8" standalone="no"?>

<domain:transfer

<domain:authInfo>

</domain:authInfo>

<domain:ns>

<domain:hostObj>ns1.newns.net</domain:hostObj>

<domain:hostObj>ns2.newns.net</domain:hostObj>

</domain:ns>

</domain:transfer>

</transfer>

</command>

</epp>

47 (50)

Registrar removes transfer key (domain:rem): <?xml version="1.0" encoding="UTF-8" standalone="no"?>

<domain:update

<domain:rem>

<domain:authInfo>

</domain:authInfo>

</domain:rem>

</domain:update>

</update>

</command>

</epp>

48 (50)

7.3 Registrant Change

Domain registrar may start registrant (previously holder) change process. The process requires a transfer key if the register number or holder type of the registrant will

change. Starting the change process will send an email to the registrant that contains the transfer key. The key is generated by the system and is valid for one month.

Requesting registrant change key: <?xml version="1.0" encoding="UTF-8" standalone="no"?>

<domain:update

<domain:chg>

<domain:authInfo>

<domain:pwregistranttransfer>new</domain:pwregistranttransfer>

</domain:authInfo>

</domain:chg>

</domain:update>

</update>

<clTRID>ynair</clTRID>

</command>

</epp>

Registrant change:

<domain:update

<domain:chg>

<domain:registrant>newRegistrantUsername</domain:registrant>

<domain:authInfo>

<domain:pwregistranttransfer>HuY%9Ipgo&i0</domain:pwregistranttransfer>

</domain:authInfo>

</domain:chg>

</domain:update>

</update>

</command>

</epp>

49 (50)

7.4 Registry Lock

Registrant (ISP) may lock a domain so that it cannot be updated in any other way than by renewing it. The registry lock may also be removed. Registrylock command allows

the following operation types: activate, deactivate, requestkey.

Activate sets the domain registry lock attribute. Activation requires 2-3 phone numbers in the request.

Deactivate removes the registry lock attribute from the domain. After successful

removal, the domain may be updated again. Removal request requires a valid authorization key. The key is requested by requestkey command.

Requestkey generates and sends the authorization key to predetermined phone numbers as SMS messages. The request must have the wanted phone numbers order number. The key is valid for one day.

Activate:

<domain:update

<domain:chg>

<domain:registrylock type="activate">

<domain:smsnumber>+3584441111444</domain:smsnumber>

<domain:authkey>domainauthkey</domain:authkey>

</domain:chg>

</domain:update>

</update>

</command>

</epp>

50 (50)

Deactivate: <?xml version="1.0" encoding="UTF-8" standalone="no"?>

<domain:update

<domain:chg>

<domain:registrylock type="deactivate">

<domain:authkey>1234567890</domain:authkey>

</domain:chg>

</domain:update>

</update>

</command>

</epp>

Requestkey:

<domain:update

<domain:chg>

<domain:registrylock type="requestkey">

<domain:authkey>domainauthkey</domain:authkey>

</domain:chg>

</domain:update>

</update>

</command>

</epp>

epp interface manual - etusivu · pdf file1 (50) epp interface version author date comment 1.0...

Documents

video batteries - markertekav800 epp-100c / epp-100 av850...

vnnic epp gateway specifications · 2017. 1. 5. · vnnic...

capacitacion epp ok

filipino epp

new developments of epileptic syndromes in very young...

epp example

current topic – epp -

epp tank installation & service manual - super hot...

epp interface - finlex · epp interface version author date...

draupne epp interface description · the epp interface is...

epp capacitación - copia.pptx

can - mywp.org.my · introduction epp 1 – mnc attraction...

epp slidedeck

epp guidelines 13d

epp january 2014

clarification epp 310309

proyecto de epp

epp platform

epp catalog

prensentation epp (nantucket)