Implantações do PDNS
Nesta seção serão apresentadas múltiplas formas de implantação, de acordo com os requisitos do cliente em relação à carga. Deve-se levar em conta que, dado que o produto é Multi-Tenant, também é direcionado a empresas que gerenciam múltiplos domínios sem requisitos em nível de arquitetura
DNS para Clientes Finais na Nuvem da Planisys
Na nuvem da Planisys, é fornecida a aplicação PDNS na nuvem.
Aviso
Nesta seção mostramos o que um usuário cliente pode fazer, sem se importar com a arquitetura de rede da implantação.
Clientes diretos da Planisys acessam uma página web https://pdns-app.planisys.net:8443 com um único nível de papel de usuário, no qual podem criar Zonas (Master, Slave, Reversas IPv4 e IPv6) e criar Registros de Zona ou RRs (Resource Records), e também utilizar a API com própria APIKEY (ver gráficos) para, por exemplo, criar zonas, modificar registros, etc.
Trata-se de um serviço compartilhado, no qual a Planisys fornece os servidores autoritativos credenciados na ICANN que o cliente deverá utilizar para delegar seus domínios.
O cliente pode utilizar os resolvers padrão da Planisys.
O tipo de zonas que um cliente final pode criar é:
Master Direta |
Master Reversa IPv4 |
Master Reversa IPv6 |
Slave de master externo |
A empresa também pode:
Consultar o WHOIS do domínio (data de expiração e mais dados) |
Ver o status de delegação (se está desativado, se está delegado a outros NSs) |
Acessar, através do botão |
Registros de Zona (Resource Records)
Após acessar os registros, pode-se ver que, imediatamente após a criação da Zona, o sistema atribuiu automaticamente dois registros NS correspondentes ao NS-SET e um registro SOA, cujos dados são mostrados na parte superior separadamente.
Qualquer modificação que se faça a nível de registros (excluir/editar/adicionar), implicará em um incremento automático do SOA Serial Number.
Neste gráfico vemos logado o usuário revendedor, mas é a mesma visão para um usuário cliente final.
A seguir, será adicionado um registro MX (clicando no botão verde de adicionar MX) para a zona assetcrypt.com, e veremos como muda apenas o serial number de 2023010500 para 2023012000. Como o tipo de Serial que esta zona possui é no formato YYYYMMDDSS, ele tentará utilizar a data atual e, em seguida, SS de 00 até 99. As zonas podem ser criadas com um serial que não corresponda a datas, mas sim a números de 0 até 2^32 -1 (4294967295).
Aqui é mostrada a lista de registros após adicionar o MX, e vê-se o serial number aumentado. Isto é um gatilho que faz com que o servidor primário regenere a zona e, uma vez carregada, sejam disparadas as transferências de zona para os secundários via protocolo NOTIFY (avisa aos secundários para fazerem um AXFR; em geral, utiliza-se o protocolo IXFR, que é uma transferência de zona incremental para trazer apenas as alterações).
DNS para Revendedores na Nuvem da Planisys
Um revendedor de PDNS é uma entidade que possui seu próprio NS_SET, ou seja, seus próprios servidores autoritativos e, eventualmente, seus próprios resolvers.
É fornecido um login ao Revendedor, cuja tela inicial se vê assim:
O revendedor tem permissões para:
Criar Empresas |
Criar Usuários de Empresas |
Criar Domínios |
Declarar seus Autoritativos |
Declarar seus Blocos CIDR para limitar Resolvers |
Declarar ACLs para transferências de zona externas |
Empresas Clientes
Inicialmente, o revendedor vê suas empresas clientes:
Gerenciamento de Zonas
e pode acessar diretamente as zonas de seus clientes:
Ainda que não se vá delegar a operação das zonas a seus clientes, seja porque eles não têm pessoal com conhecimentos ou preferem serviço gerenciado, é conveniente, a nível da operação CRM, saber quais zonas/domínios estão atribuídos aos seus clientes.
Aviso
No caso de ter domínios sem identificar a que clientes pertencem, deverá igualmente criar uma empresa - mesmo que seja fictícia - para poder acessar as zonas.
Mudar uma Zona de uma Empresa para outra
No caso de termos domínios sem identificar, ou domínios erroneamente atribuídos a uma empresa, podemos muito facilmente, a partir da tela de zonas, clicando no ícone de lápis, acessar a seguinte tela de edição, onde, ao escolher a empresa no dropdown de Empresas e pressionar o botão Salvar, fazemos a mudança de titularidade.
Deve-se notar que o operador deve se auxiliar com o botão WHOIS da lista de domínios para estabelecer a titularidade ou ownership de um domínio.
WHOIS
Com o botão WHOIS, são exibidas as informações do domínio, que são dependentes dos Registrars de domínio, embora devam se ajustar às políticas da ICANN, por exemplo:
É importante notar que, na janela de texto WHOIS, consta a data de expiração do domínio.
Autoritativos
Para dar uma ideia do nível de independência que tem uma Implantação de Revendedor, mostramos aqui seus próprios autoritativos, que podem ser encontrados em qualquer Datacenter, e podem ser Unicast ou Anycast (ver capítulo sobre Alta Disponibilidade):
Nota
O fato de que a aplicação PDNS esteja implantada na nuvem da Planisys não implica que os autoritativos e resolvers também estejam. Na imagem, são vistos dois nameservers registrados na ICANN que estão na nuvem da Planisys, dns1.avascorp.net e dns2.avascorp.net.
Usuários
Neste listado vemos um caso típico de um usuário com direitos para operar as Zonas de uma empresa, e o próprio Revendedor com um cadeado que não pode excluir a si mesmo
Adição de Usuários
Na implantação de Revendedor, poderá criar usuários. Neste gráfico é vista a criação de um usuário operador de Empresa.
Neste gráfico é vista a criação de um Operador DNS a nível Revendedor, que pode criar zonas e empresas. Ao selecionar Operador DNS, vê-se que o dropdown de escolha de Empresa desaparece, já que poderá operar sobre todas as Empresas Cliente deste Revendedor.
É importante notar que o usuário reseller1@planisys.com é um Administrador DNS a nível Revendedor, que tem a possibilidade de criar diferentes clusters de servidores autoritativos e recursivos, ou seja, com mais permissões que um Operador DNS.
Implantação de Recursivos e Autoritativos Externos
O fato de que o PDNS-APP rode dentro da nuvem da Planisys não significa que, para um Revendedor, seus Resolvers e Autoritativos devam fazê-lo na mesma nuvem. O Revendedor pode contratar servidores em diferentes Clouds Públicos ou em seus próprios Datacenters On-Premise, para que a Planisys os administre, instale e monitore seus componentes de software (pipeline CI/CD) que se conectam com a aplicação PDNS-APP.
Aqui pode-se ver um exemplo de um Revendedor que opta por localizar seus Resolvers e Recursivos em diferentes clouds públicos:
Este gráfico é uma variação do anterior, onde o Revendedor também opta por um Datacenter Corporativo de sua empresa ou outro, juntamente com Clouds Públicos:
PDNS-APP implantado On-Premise
Para poder implantar a aplicação PDNS-APP On-Premise, independentemente de onde sejam implantados os Recursivos e Autoritativos, deverá contar minimamente com dois VPSs (Virtual Private Servers) no caso do RedHat9 e um único VPS para o caso do Debian/Ubuntu.
Tomando o caso de um único VPS, as medidas são:
16G - 4VCPU - 1000 a 5000 domínios |
32G - 8VCPU - 5000 a 10000 domínios |
64G - 16VCPU - 10000 a 25000 domínios |
Nota
No caso On-Premise, a Planisys fornecerá chave na mão um superadmin, ou seja, um login com poder capaz de criar Revendedores com toda a capacidade descrita anteriormente. Se não houver Revendedores no funcionamento real, deverá ser criado um Falso Revendedor único de qualquer forma. Se não se quiser delegar a operação para Empresas Cliente, ou não existirem Empresas Cliente, igualmente deverá ser criada uma Empresa Cliente para poder atribuir as zonas, mesmo que seja uma Falsa Empresa única. Um superadmin tem o poder de criar outros superadmins.
A partir dos 20 mil ou 25 mil domínios torna-se necessário clusterizar e ter VPSs independentes para MariaDB, para Bind9 e para o código do PDNS-APP (3 VPSs), e, no caso de haver muita operação, utilizar load-balancing e Galera-Cluster.
No caso do RedHat9, deverá contar com uma assinatura dos repositórios para que a Planisys possa instalar os componentes base como MariaDB, Python3, etc., e manter um kernel atualizado. Em 2023, as alternativas são Debian11 e Ubuntu 22.04 (a alternativa Ubuntu 22.10 não é viável porque seu suporte expira 9 meses após o lançamento).
Instalação mínima para menos de 10 mil domínios
Nota
Aqui se apresenta uma instalação em um único VPS, com o dimensionamento sugerido anteriormente.
Aviso
Nesta instalação, o provedor On-Premise tem a responsabilidade de implementar componentes de Alta Disponibilidade, tais como discos com RAID, circuito elétrico A+B, duplo upstream de Internet, Backups de Snapshot periódicos, utilizar as capacidades de VMWare HA, configurar Proxmox HA Cluster com firmware fencing (IPMI/iDrac/APC), etc.
Instalação para mais de 25 mil domínios
Nesse caso, sugere-se dividir a instalação em mais VPSs, utilizar um load-balancer e um Galera Cluster com Quórum de 3 servidores de banco de dados.
É um exemplo de um dimensionamento maior, onde a Planisys entrega todos os VPSs configurados (incluindo nginx/haproxy e Galera Cluster).
Nota
No gráfico, consta o requisito de Load Balancing segundo sticky sessions. Este requisito de manter a sessão baseada no IP e porta originais do cliente é necessário apenas para a interface Web, já que a interface API é stateless (não possui sessões) pois se baseia na troca de JSONs.
Aviso
No load balancer, não se deve usar round-robin nem distribuição por carga quando o upstream é a interface web. Quando o upstream é a API, o método mais conveniente é leastconn, ou seja, tenta carregar os upstreams por igual baseado em conexões abertas.
Ansible Jumphost (Pivô)
O PDNS utiliza como parte da implantação um jumphost, também às vezes chamado de pivô, onde roda a ferramenta de orquestração Ansible. Por meio desta ferramenta, o PDNS pode suportar uma grande quantidade de servidores recursivos e autoritativos.
A orquestração é realizada para instalar os componentes necessários e os scripts de:
pipeline CI/CD |
monitoramento |
análise de logs |
alertas |
estatísticas |
Isto requer que os servidores a serem orquestrados tenham permissões de root através da chave pública ssh do pivô Ansible. Isto é feito simplesmente adicionando a chave pública fornecida pela Planisys nos servidores a serem orquestrados no arquivo /root/.ssh/authorized_keys.
Isto é, se um cliente/revendedor ou proprietário quiser provisionar servidores autoritativos ou recursivos, poderá fazê-lo em forma de container ou máquina virtual de qualquer nuvem, mas deverá ceder Controle de Orquestração ao pivô Ansible do PDNS.
Dessa forma, podem ser realizadas implantações graduais, ou inclusive provas de conceito ou PoC onde se utilize o PDNS-Cloud (na Nuvem da Planisys).
NS-Set
Um NS-Set ou Nameserver Set é um conjunto de servidores autoritativos, onde um é configurado como Master e o resto como Slave. O servidor master é quem reconstrói as zonas Bind a partir das informações coletadas via Web e via API alojadas no banco de dados. Os servidores slave replicam as zonas pelo mesmo protocolo, utilizando DNS NOTIFY para serem avisados de mudanças nas zonas.
O NS-Set é um círculo de confiança que compartilha uma chave TSIG e evita o spoofing de endereços IP.
Por outro lado, a nível das Empresas, podem ser definidas ACLs ou Access Control Lists com permissões de transferência (por IP ou por TSIG), para poder trocar zonas em ambos sentidos entre o Master e Servidores Bind9 Externos.
