| TOC |
|
Este documento descreve o Procedimento Técnico de Homologação de Provedores de Serviços de Provisionamento de Nomes de Domínios .br via protocolo EPP pelo Registro.br.
1.
Introdução
2.
Sequência de Comandos
2.1.
Comandos Básicos
2.1.1.
Connect
2.1.2.
Login com mudança de senha.
2.1.3.
Hello
2.1.4.
Logout
2.1.5.
Connect
2.1.6.
Login com a nova senha
2.2.
Comandos de Contato
2.2.1.
Create
2.2.2.
Info
2.2.3.
Update
2.3.
Comandos de Organização
2.3.1.
Check
2.3.2.
Create
2.3.3.
Info
2.4.
Comandos de Domínio
2.4.1.
Domain Check
2.4.2.
Domain Create
2.4.3.
Ticket Info
2.4.4.
Ticket Update
2.5.
Domain Create (domínio 2)
2.6.
Serviço de Mensageria (Poll)
2.6.1.
Poll Request
2.6.2.
Poll Acknowledge
2.7.
Comandos após a criação do domínio
2.7.1.
Organization Update
2.7.2.
Organization Info
2.7.3.
Domain Info
2.7.4.
Domain Renew
2.7.5.
Domain Update - Contatos
2.7.6.
Domain Update - Habilitar Renovação Automática
2.7.7.
Domain Update - Desabilitar Renovação Automática
2.7.8.
Domain Delete
3.
Aprovação
4.
Normative References
§
Author's Address
| TOC |
O Procedimento de Homologação é o mecanismo através do qual o Registro.br pode confirmar que o provedor candidato possui uma total compreensão do protocolo EPP e do sistema de registro de domínios brasileiro. Sua sequência de comandos abrange um universo que julgamos minimamente suficiente para cobrir todas as operações mais importantes que o provedor pode realizar junto ao Registro.br.
Antes de iniciar o Procedimento de Homologação o provedor deve estar devidamente cadastrado para acessar o servidor beta.registro.br. Os comandos devem ser executados na ordem apresentada e todos devem ser completados com sucesso.
Os exemplos exibidos utilizam o cliente 'shepp', disbonibilizado livremente pelo Registro.br junto com a [libepp‑nicbr] (, “libepp-nicbr: Biblioteca para cliente EPP do NIC.br,” August 2010.). O seu uso não é obrigatório, basta que os comandos em XML sejam enviados para o nosso servidor beta.registro.br:700 seguindo as definições especificadas nos drafts e RFCs que definem o protocolo EPP e suas extensões para o modelo BR.
| TOC |
| TOC |
| TOC |
Conectar-se ao servidor de testes usando o protocolo de transporte TCP sobre TLS como especificado em [RFC4934] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Transport Over TCP,” May 2007.).
Exemplo:
shepp> server beta.registro.br:700 shepp> connect
| TOC |
Executar o comando EPP Login mudando a senha.
Exemplo:
shepp> user 001 shepp> pw abcdef shepp> newpw 123456 shepp> login
| TOC |
Executar o comando EPP Hello.
Exemplo:
shepp> hello
| TOC |
Executar o comando EPP Logout.
Exemplo:
shepp> logout
| TOC |
Conectar-se ao servidor de testes novamente.
Exemplo:
shepp> connect
| TOC |
Executar o comando EPP Login com a nova senha.
Exemplo:
shepp> user 001 shepp> pw 123456 shepp> login
| TOC |
Os comandos desta seção estão especificados no Mapping de Contato EPP em [RFC4933] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Contact Mapping,” May 2007.).
| TOC |
Executar o comando EPP Contact Create para criar um novo contato.
Exemplo:
shepp> contact create dummy -postalInfo loc -name "John Foo"
-street1 "Rua Foo" -street2 "555" -street3 "AP11"
-city "São Paulo" -state "SP" -pc "00000-000" -cc "BR"
-voice 55.1155555555 -email usuario@provedor
| TOC |
Executar o comando EPP Contact Info para buscar informações do contato criado informando o ID retornado pelo servidor. Verificar o campo "contact:id" na resposta do comando anterior.
Exemplo:
shepp> contact info <ID>
| TOC |
Executar o comando EPP Contact Update para atualizar os dados do contato recém-criado. A atualização deve alterar os seguintes atributos:
- - Endereço
- - Telefone
Exemplo:
shepp> contact update <ID>
-postalInfo loc -street1 "Rua Bar" -street2 "666" -street3 "CJ00"
-voice 55.1198765432 -email other@provedor
| TOC |
Os comandos desta seção estão especificados em parte no Mapping de Contato em [RFC4933] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Contact Mapping,” May 2007.). A outra parte faz parte da extensão do Mapping de Contato para Organização feita pelo Registro.br especificada em [I‑D.neves‑epp‑brorg] (Neves, F. and H. Kobayashi, “BR Organization Mapping for the Extensible Provisioning Protocol (EPP),” August 2010.).
| TOC |
Executar o comando EPP Contact Check extendido para Organização para checar a disponibilidade de provisionamento de uma determinada organização. Um documento deve ser especificado (CPF ou CNPJ).
Exemplo:
shepp> brorg check <documento>
| TOC |
Executar o comando EPP Contact Create extendido para Organização para criar a nova organização ou entidade como é chamada no sistema do Registro.br. Detalhe: o contato da entidade deve ser o usuário cadastrado na seção 2.2.1.
Exemplo:
shepp> brorg create <documento> -postalInfo loc
-name "Minha Empresa"
-street1 "Rua Foobar" -street2 "123" -street3 "CJ11"
-city "São Paulo" -state "SP" -pc "00000-000" -cc BR
-voice 55.55554321:2222 -email usuario@organizacao -contact admin=<ID>
| TOC |
Executar o comando EPP Contact Info extendido para Organização para buscar informações da organização criada no passo anterior.
Exemplo:
shepp> brorg info <documento>
| TOC |
Os comandos desta seção estão especificados em parte no Mapping de Domínios [RFC4931] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” May 2007.). A outra parte faz parte da extensão do Mapping de Nomes de Domínios feita pelo Registro.br especificada em [I‑D.neves‑epp‑brdomain] (Neves, F. and H. Kobayashi, “BR Domain Mapping for the Extensible Provisioning Protocol (EPP),” August 2010.).
| TOC |
Executar o comando EPP Domain Check como especificado no Mapping de Domínio para checar a disponibilidade de provisionamento de um determinado nome de domínio.
Exemplo:
shepp> domain check <dominio>
| TOC |
Executar o comando EPP Domain Create extendido para domínios .BR. O domínio deve ser criado sem contatos e com 3 servidores DNS da seguinte forma:
- - Primeiro servidor sem glue record
- - Segundo servidor com glue record IPv4
- - Terceiro servidor com glue record IPv4 e IPv6
Os campos de endereço IPv4 e IPv6 sempre devem ser preenchidos nos casos em que o domínio do servidor DNS seja igual ou esteja contido no que está sendo delegado. Nestes casos, o endereço IPv4 é obrigatório e o IPv6 opcional. O campo endereço IPv6 deve ser preenchido caso o servidor possua conectividade neste protocolo.
Exemplo: No caso do domínio XYZ.COM.BR delegado para os servidores FOO.XYZ.COM.BR, NS1.BAR.XYZ.COM.BR e NS1.KZX.COM.BR, para os dois primeiros servidores, o preenchimento do campo endereço IPv4 é obrigatório e o campo endereço IPv6 opcional. Já para o terceiro servidor, não é necessário preencher os campos IPv4 e IPv6 e caso sejam informados, os mesmos serão descartados.
Nesse passo não é importante que os servidores DNS tenham autoridade sobre o domínio.
Exemplo:
shepp> domain create <dominio>
-ns <host>
-ns <host2>.<dominio>,v4:<ipv4-1>
-ns <host3>.<dominio>,v4:<ipv4-2>,v6:<ipv6>
-o <documento>
| TOC |
O comando anterior, se executado com sucesso, retornará um número de ticket no campo 'brdomain:ticketNumber'. Executar o comando EPP Domain Info extendido para Ticket para buscar informações sobre este ticket.
Exemplo:
shepp> domain info <dominio> -t <ticket>
| TOC |
Executar o comando EPP Domain Update extendido para Ticket para fazer as alterações necessárias para resolver todas as pendências DNS. Ao menos dois servidores de nomes devem ser fornecidos e TODOS os servidores fornecidos devem responder com autoridade sobre o domínio caso contrário o ticket será cancelado assim que o prazo para resolver as pendências expirar.
Exemplo:
shepp> domain update <dominio> -t <ticket>
-rem-ns <host2>.<dominio>
-rem-ns <host3>.<dominio>
-add-ns <host4>
Neste momento, uma vez resolvidas todas as pendências do ticket criado, é necessário aguardar para que o mesmo seja processado (até 15 minutos).
| TOC |
Execute mais um comando Domain Create para um segundo domínio. Certifique-se via o comando Domain Check de que este nome de domínio esteja disponível e informe já neste momento servidores DNS que estejam respondendo com autoridade para o domínio em questão.
Exemplo:
shepp> domain create <dominio-2>
-ns <host1>
-ns <host2>
-o <documento>
Neste momento, uma vez criado o ticket sem pendências, é necessário aguardar para que o mesmo seja processado e convertido em domínio (até 15 minutos).
| TOC |
O sistema mensageria EPP é utilizado pelo Registro.br para enviar mensagens referentes ao serviço EPP ao provedor. Avisos sobre o crédito do provedor ou sobre o cadastro e inativação de tickets, por exemplo, são exemplos de mensagens enviadas via Poll.
Este sistema funciona como uma lista FIFO (first-in-first-out). Quando é executado um comando 'req' a primeira mensagem da fila (a mais antiga) é exibida. Para que a próxima mensagem da fila seja exibida, é necessário confirmar a leitura da mensagem atual enviando um comando 'ack' especificando o id da mensagem lida. A partir daí, uma nova chamada do comando 'req' mostrará a mensagem seguinte.
Os comandos 'poll op="ack"' e 'poll op="req"' devem ser executados tantas vezes quanto for necessário até zerar a fila de mensagens.
Informações completas sobre todas as respostas do poll podem ser encontradas no documento [BR‑policy‑restrictions‑espec] (, “Política e restrições do serviço EPP no Registro.BR - especificações técnicas,” .).
| TOC |
Executar o comando EPP Poll Request para requisitar a primeira mensagem EPP da fila. Deverá receber como resposta a notificação de criação da organização. Esse comando não foi extendido e deve ser usado como especificado em [RFC4930] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP),” May 2007.).
Exemplo:
shepp> poll req
| TOC |
Executar o comando EPP Poll Acknowledge para confirmar a remoção da última mensagem EPP lida. Para tal é necessário informar o atributo 'id' dentro de 'msgQ' da mensagem recebida na resposta ao comando anterior.
Exemplo:
shepp> poll ack <id>
| TOC |
| TOC |
Uma vez cadastrado o primeiro domínio para uma determinada entidade, já será possível alterar os dados da mesma.
Executar o comando EPP Contact Update extendido para Organização para atualizar os seguintes atributos:
- - Endereço
- - Telefone
Exemplo:
shepp> brorg update <documento> -postalInfo loc
-street1 "Rua Barfoo" -street2 "321" -street3 "7-AND"
-voice 55.1198761234
| TOC |
Executar o comando EPP Contact Info para buscar as informações atualizadas da organização.
Exemplo:
shepp> brorg info <documento>
| TOC |
Executar o comando EPP Domain Info para checar os dados do domínio recém-criado.
Exemplo:
shepp> domain info <dominio>
| TOC |
Executar o comando EPP Domain Renew para renovar o domínio por um ano a partir da data de expiração 'domain:exDate' obtida na resposta do comando anterior.
Exemplo:
shepp> domain renew <dominio> -expdate <expdate>
| TOC |
Criar um novo contato e executar o comando EPP Domain Update para atualizar o contato de cobrança do domínio recém-criado.
Exemplo:
shepp> contact create dummy -postalInfo loc -name "Foo John"
-street1 "Rua Bar" -street2 "123" -street3 "AP44"
-city "São Paulo" -state "SP" -pc "00000-000" -cc "BR"
-voice 55.1155555555 -email usuario@provedor
shepp> domain update <dominio>
-rem-contact billing=<ID>
-add-contact billing=<ID-2>
| TOC |
Executar o comando EPP Domain Update para habilitar a renovação automática do domínio. Com esta opção habilitada o domínio será renovado quando chegar o prazo de expiração e o valor da manutenção será debitado automaticamente.
Exemplo:
shepp> domain update <dominio> -auto-renew on
| TOC |
Executar o comando EPP Domain Update para desabilitar a renovação automática do domínio. Com esta opção desabilitada, caso o provedor não envie um comando EPP Domain Renew até a data de expiração do domínio, o mesmo será congelado e em seguida removido.
Exemplo:
shepp> domain update <dominio> -auto-renew off
| TOC |
Executar o comando EPP Domain Delete para excluir o segundo domínio criado anteriormente.
Exemplo:
shepp> domain delete <dominio-2>
No servidor em produção, é permitido o envio do comando domain:delete para uma porcentagem dos domínios registrados pelo provedor via EPP sem ônus (até 3% dos domínios registrados nos últimos 5 dias).
| TOC |
O servidor EPP de testes irá logar TODOS os comandos executados pelo cliente para certificar que o teste foi completo.
Para comprovar que efetuou a sequência de comandos com sucesso o provedor de serviços deverá avisar por e-mail data e hora de início e término do teste, bem como o endereço IP utilizado na conexão.
A análise será feita offline e o Provedor de Serviços será informado sobre o resultado pelo email de contato cadastrado junto ao Registro.br.
| TOC |
| [RFC4930] | Hollenbeck, S., “Extensible Provisioning Protocol (EPP),” RFC 4930, May 2007 (TXT). |
| [RFC4931] | Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Domain Name Mapping,” RFC 4931, May 2007 (TXT). |
| [RFC4933] | Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Contact Mapping,” RFC 4933, May 2007 (TXT). |
| [RFC4934] | Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Transport Over TCP,” RFC 4934, May 2007 (TXT). |
| [I-D.neves-epp-brdomain] | Neves, F. and H. Kobayashi, “BR Domain Mapping for the Extensible Provisioning Protocol (EPP),” draft-neves-epp-brdomain-04 (work in progress), August 2010. |
| [I-D.neves-epp-brorg] | Neves, F. and H. Kobayashi, “BR Organization Mapping for the Extensible Provisioning Protocol (EPP),” draft-neves-epp-brorg-05 (work in progress), August 2010. |
| [BR-policy-restrictions-espec] | “Política e restrições do serviço EPP no Registro.BR - especificações técnicas.” |
| [libepp-nicbr] | “libepp-nicbr: Biblioteca para cliente EPP do NIC.br,” August 2010. |
| TOC |
| NIC.br / Registro.br | |
| Av. das Nações Unidas, 11541, 7 | |
| São Paulo, SP 04578-000 | |
| BR | |
| Phone: | +55 11 5509 3511 |
| Email: | epp-suporte@registro.br |
| URI: | http://registro.br/ |