(...)

 

E se a registro.br oferece os seus próprios servidores de DNS, que permite que muitos tenham VPS/revenda com 1 IP só e tudo roda normalmente (apesar da maior mão de obra para manter os registros de subdomínios, por exemplo, que temos que ir adicionar sempre manualmente, além de ter algumas limitações - eu tentei criar um SRV outro dia e não consegui, e também já tive problema com alguns TXT para Domain Keys que não entravam por não aceitarem alguns caracteres, como "_", se me recordo bem) o que, ao meu ver, gera mais custo de operação/manutenção para a registro.br do que se não oferece esse serviço (e realmente obrigasse as pessoas a terem nameservers externos), a registro.br poderia então oferecer o que a OVH oferece:

 

 

Lá, podemos configurar os 2 nameservers dos nossos domínios como sendo ns1.ovh.com / ns2.ovh.com, e no painel deles, você aponta o IP do servidor de onde eles devem clonar a zona quando consultados. E esse resultado é cacheado pelo tempo determinado como expire da zona (ou de cada registro individual, não me recordo ao certo).

 

Assim poderíamos deixar o registro.br como nameservers e continuar aproveitando toda a facilidade que os painéis de hospedagem nos oferecem, criando/retirando/editando entradas conforme criamos/deletamos/modificamos as contas dos clientes!

Ou, melhor ainda, poderíamos definir o nosso próprio servidor como master, e os servidores da registro.br atuariam só no caso de falha destes (seriam slaves). Não sobrecarregaria os servidores da registro.br com consultas desnecessárias.

 

A questão de _ e ; é um pouco mais complexa do que parece pois vem do cerne do software DNS que é usado para prover esse serviço, o DNSSHIM (http://registro.br/tecnologia/provedor-hospedagem.html?secao=dnsshim). Esses caracteres por muito tempo foram considerados inválidos para nomes DNS, e por isso o DNSSHIM foi escrito assim. O problema é que por serem inválidos, eles tem sido aproveitados em definições que usam caracteres inválidos como separadores... assim, é preciso discriminar contextos como tipo de resource-record e posição no conteúdo para entender como válido ou inválido. E em se decidindo colocar, dá um trabalho ingrato de encoding garantir que qualquer browser envie corretamente isso e que isso não possa ser usado como SQL Injection. Não é uma limitação propositada de produto, mas um change-request que não tem tanta prioridade para ser implementado. 

 

Usar DNS por cópia da zona, usando ou não zone-transfer DNS, não é algo que um usuário comum irá precisar... aqui precisa ficar claro a questão de posicionamento do Registro.br:

- Temos uma interface registry, usando protocolo EPP, voltada a quem tem nível técnico de registrador de domínios. É uma organização que tem capacidade de ter um DNS próprio e sistemas de provisionamento, automático ou manual, sob seu controle. Ela inclusive não permite registros por outra interface que não EPP, e tem o maior nível de segurança que podemos oferecer, com 3 fatores de autenticação. 

- Temos uma interface web, voltada ao usuário final. Os casos de uso dela são escolhidos conforme essas necessidades. 

- Não temos uma interface reseller, voltada ao revendedor. Uma interface reseller normalmente tem uma API simplificada que não é EPP, um sistema de extrato e gestão de conta, e que pode ter a interface web como back-up da API para registro de novos domínios. 

 

Normalmente quem oferece interface reseller são registradores maiores, não o registry... OVH, OpenSRS, Resell.biz, ResellClub são exemplos disso. Esse papel porém ainda precisa ser preenchido no caso de domínios .br ... há empresas cogitando isso e com serviço em caráter de teste, mas se alguém souber de alguma que já esteja em operação comercial, seria uma ótima adição ao tópico. 

A questão de _ e ; é um pouco mais complexa do que parece pois vem do cerne do software DNS que é usado para prover esse serviço, o DNSSHIM (http://registro.br/tecnologia/provedor-hospedagem.html?secao=dnsshim). Esses caracteres por muito tempo foram considerados inválidos para nomes DNS, e por isso o DNSSHIM foi escrito assim. O problema é que por serem inválidos, eles tem sido aproveitados em definições que usam caracteres inválidos como separadores... assim, é preciso discriminar contextos como tipo de resource-record e posição no conteúdo para entender como válido ou inválido. E em se decidindo colocar, dá um trabalho ingrato de encoding garantir que qualquer browser envie corretamente isso e que isso não possa ser usado como SQL Injection. Não é uma limitação propositada de produto, mas um change-request que não tem tanta prioridade para ser implementado. 

 

Usar DNS por cópia da zona, usando ou não zone-transfer DNS, não é algo que um usuário comum irá precisar... aqui precisa ficar claro a questão de posicionamento do Registro.br:

- Temos uma interface registry, usando protocolo EPP, voltada a quem tem nível técnico de registrador de domínios. É uma organização que tem capacidade de ter um DNS próprio e sistemas de provisionamento, automático ou manual, sob seu controle. Ela inclusive não permite registros por outra interface que não EPP, e tem o maior nível de segurança que podemos oferecer, com 3 fatores de autenticação. 

- Temos uma interface web, voltada ao usuário final. Os casos de uso dela são escolhidos conforme essas necessidades. 

- Não temos uma interface reseller, voltada ao revendedor. Uma interface reseller normalmente tem uma API simplificada que não é EPP, um sistema de extrato e gestão de conta, e que pode ter a interface web como back-up da API para registro de novos domínios. 

 

Normalmente quem oferece interface reseller são registradores maiores, não o registry... OVH, OpenSRS, Resell.biz, ResellClub são exemplos disso. Esse papel porém ainda precisa ser preenchido no caso de domínios .br ... há empresas cogitando isso e com serviço em caráter de teste, mas se alguém souber de alguma que já esteja em operação comercial, seria uma ótima adição ao tópico. 

 

Mas qual seria a dificuldade de implementar a cópia de zona, e o uso dos DNS do registro.br como slaves (uma opção dada diretamente no painel), se hoje já operam como master para uma infinidade de domínios? Acho que não seria muito difícil implementar isto. É uma sugestão bem séria que estou dando aqui, gostaria muito de ver isso funcionar. Pouparia um número muito grande de IPs que estão sendo utilizados só para funcionar como slave.

 

Pelo que eu entendi (não somente pelas suas afirmações de agora), há total abertura para que uma interface de registros como a LogicBoxes (utilizada pela ResellerClub e outras) inclua suporte ao registro de domínios .br, usando a documentação de integração que a registro.br oferece, estou certo (tanto eles se tornando um provedor habilitado, quanto eles abrindo uma possibilidade de associarmos nossos certificados ao painel deles)? E, se eu estou certo, alguma vez vocês entraram em contato com eles (ou eles com vocês)?

Mas qual seria a dificuldade de implementar a cópia de zona, e o uso dos DNS do registro.br como slaves (uma opção dada diretamente no painel), se hoje já operam como master para uma infinidade de domínios? Acho que não seria muito difícil implementar isto. É uma sugestão bem séria que estou dando aqui, gostaria muito de ver isso funcionar. Pouparia um número muito grande de IPs que estão sendo utilizados só para funcionar como slave.

 

Pelo que eu entendi (não somente pelas suas afirmações de agora), há total abertura para que uma interface de registros como a LogicBoxes (utilizada pela ResellerClub e outras) inclua suporte ao registro de domínios .br, usando a documentação de integração que a registro.br oferece, estou certo (tanto eles se tornando um provedor habilitado, quanto eles abrindo uma possibilidade de associarmos nossos certificados ao painel deles)? E, se eu estou certo, alguma vez vocês entraram em contato com eles (ou eles com vocês)?

 

A dificuldade não é para quem sabe o que são DNS master e slave, e sim para um usuário leigo. Como já disse, isso é típico de interface reseller, o que o Registro.br não tem. E para ter, não vai precisar ter apenas isso, vai precisar de uma série de outros recursos para ter um bom serviço de revenda. 

 

Eu não posso comentar sobre a LogicBoxes especificamente e nem negar ou confirmar qualquer contato.. mas questões como a necessidade do registrador constituir empresa no Brasil,  de transferir dinheiro a partir do sistema financeiro brasileiro e pela pequena diferença entre o preço de atacado e o de varejo costumam ser apontadas por empresas desse tipo como dificuldades. 

Apesar disso, ao menos uma delas disse que entrará se conseguir achar alguém confiável para cuidar da parte jurídica e contábil no país. 

A dificuldade não é para quem sabe o que são DNS master e slave, e sim para um usuário leigo. Como já disse, isso é típico de interface reseller, o que o Registro.br não tem. E para ter, não vai precisar ter apenas isso, vai precisar de uma série de outros recursos para ter um bom serviço de revenda. 

 

Eu não posso comentar sobre a LogicBoxes especificamente e nem negar ou confirmar qualquer contato.. mas questões como a necessidade do registrador constituir empresa no Brasil,  de transferir dinheiro a partir do sistema financeiro brasileiro e pela pequena diferença entre o preço de atacado e o de varejo costumam ser apontadas por empresas desse tipo como dificuldades. 

Apesar disso, ao menos uma delas disse que entrará se conseguir achar alguém confiável para cuidar da parte jurídica e contábil no país. 

 

Entendi. Começa a cair para o lado de revenda via interface web, como você falou, mesmo não sendo o meu propósito. Quanto a atrapalhar o usuário leigo... oras, eu pensei em colocar essa opção num box oculto, igual tá o de DNS atualmente, um checkbox "copiar zona master para os servidores da registro.br". Meu propósito era só para permitir que pudessem ter zonas master em VPS de 1 IP e a registro.br cobrir o slave, facilitando o processo e evitando compra de VPS só para servidor de slave (desperdício de recursos e de IP). Inclusive, para a revenda, só seria 100% útil se os domínios fossem registrados pela API e também fosse definido isso (usar os servidores da registro.br como slaves), ou os registros nem seriam aceitos pela registro.br, devido ao revendedor só ter 1 IP para responder (ele teria que se limitar a vender hospedagem para domínios internacionais, ou a ter todos os domínios .com.br com DNS da registro.br - como master mesmo, e os registros geridos no painel dela (tem gestão dos DNS pela API?)).

 

Quanto à plataforma que demonstrou interesse, ficaria feliz se pudesse me passar o contato ou, ao menos, me informar por MP qual foi.

 

Obrigado pelos rápidos retornos até aqui. Você se mostra muito esclarecido e prestativo :)

Certamente vou tentar contribuir com o módulo para WHMCS assim que tiver um tempo. No momento (como quase sempre), estou na correria... rsrs.

 

Abraços

Entendi. Começa a cair para o lado de revenda via interface web, como você falou, mesmo não sendo o meu propósito. Quanto a atrapalhar o usuário leigo... oras, eu pensei em colocar essa opção num box oculto, igual tá o de DNS atualmente, um checkbox "copiar zona master para os servidores da registro.br". Meu propósito era só para permitir que pudessem ter zonas master em VPS de 1 IP e a registro.br cobrir o slave, facilitando o processo e evitando compra de VPS só para servidor de slave (desperdício de recursos e de IP). Inclusive, para a revenda, só seria 100% útil se os domínios fossem registrados pela API e também fosse definido isso (usar os servidores da registro.br como slaves), ou os registros nem seriam aceitos pela registro.br, devido ao revendedor só ter 1 IP para responder (ele teria que se limitar a vender hospedagem para domínios internacionais, ou a ter todos os domínios .com.br com DNS da registro.br - como master mesmo, e os registros geridos no painel dela (tem gestão dos DNS pela API?)).

 

 

Domínios internacionais também requerem dois servidores DNS... é que eles são menos atentos em não checar se na verdade não aponta para o mesmo, o que recai na auto-ilusão que é operar com apenas um. 

 

Coisas como slave e gestão de DNS via API fazem sentido se/quando tivermos um serviço para revendas. Mas a tecnologia para isso não é a única questão... encaixar um modelo comercial e jurídico que agradem revendas, não irritem demais os registrars EPP, não gerem passivo jurídico alto, tenha bom número de revendas e domínios registrados por elas, e consiga aprovação no CGI.br (nós não fazemos as regras do .br), não é algo que eu veja uma maneira de acontecer nem em curto nem em médio prazo. 

 

Agora, existem idéias de como algumas dessas coisas podem ser feitas de maneira mais simples... em algo que lembra mais um programa de afiliados do que de revendas. Mas isso ainda está no papel.