[GTER] Dúvidas rDNS Bloco /29 VIVO (sem FQDN e com resposta VIVO)

[Douglas Fischer]

Fala Roberto!
A colocação do Fred está perfeita! Escute ele!
Só acho que está um pouco técnica e rebuscada demais, mas está perfeita.
Vou tentar explicar com palavras mais leigas e talvez quase cruzando a
linha entre certo e errado.

Zonas reversas de blocos só são naturalmente quebradas para
sere direcionadas para esse ou aquele NameServer até /24.
Para Máscaras maiores que isso( /25, /29 e etc) não é permitido apontar um
outro DNS autoritativo diretamente na cadeia de roots.

Existem uma quantas técnicas para se fazer com que os reversos de uma
sub-rede menor que /24 seja gerenciada por outro NameServer.
RFC 4183, RFC 2317, e a Gambiarra do "degroot" que é colocar um "subnet" na
frente da entrada PTR para dizer que aquilo é outra subnet(nem sei se isso
virou RFC).

Mas o que funciona MESMO?
Manda a lista de PTRs para o teu fornecedor de link e de bloco IP, e manda
eles colocarem isso no arquivo de zonas de DNS deles.

Se os fornecedores fosse BÃO MESMO, teriam um portalzinho web onde você
mesmo poderia entrar lá e editar as entradas dos objetos assignados a sua
empresa.

P.S.: Quero mandar um abraço ao pessoal da extinta G8, especial menção ao
Rodrigo Borges, que penou muito para fazer essas coisas ficarem tão
bonitinhas por lá, e agora tão destruindo tudo que tava tão redodinho.




Em qui., 29 de ago. de 2024 às 19:43, Frederico A C Neves via gter <
gter at eng.registro.br> escreveu:

> Roberto,
>
> On Thu, Aug 29, 2024 at 07:12:31PM -0300, Roberto Braga via gter wrote:
> > Prezados,
> >
> > Assim como a minha dúvida com rDNS que enviei sobre a Embratel. Com a
> > operadora VIVO estou com a mesma situação.
> >
> > Solicitei a eles que fizessem o rDNS do meu bloco IP 201.63.151.8/29,
> > usando como servidores de DNS:
> > ns1: 201.63.151.11;
> > ns2: 201.63.151.12;
> >
> > E não forneci nome nenhum de domínio...
> >
> > E eles responderam hoje com o seguinte:
> >
> > “Boa tarde,
> >
> >
> >
> > Configuração realizada, favor o cliente configurar a zona dele e
> validar, o
> > NS foi configurado com os IPs enviados, ficando conforme abaixo:
> >
> >
> >
> > *ns1.01.63.151.11.*
> >
> > *ns2.01.63.151.12.*
> >
>
> Como eu te disse isso não vai funcionar assim. Esta configuração está
> errada. Estes nomes nunca vão resolver e a cadeia dos CNAMES nunca vai
> apontar para os PTRs dentro da sub-zona delegada.
>
> Eles poderiam até criar registros A dentro da própria zona com estes
> seus IPs, algo como este exemplo que segue.
>
> ns1.8-15.151.63.201.in-addr.arpa. IN A 201.63.151.11
> 8-15.151.63.201.in-addr.arpa. 86400 IN NS ns1.8-15.151.63.201.in-addr.arpa.
>
> E isso cabe dentro do que eu te disse sobre a convenção de nome
> utilizada pelo operador.
>
> Mas da forma como está não vai funcionar nunca. Pois esta zona 11 não
> existe, e também pq é inválida por definição para um hostname.
>
> ~> drill -DT ns1.201.63.151.11.
> ;; Number of trusted keys: 1
> ;; Domain: .
> [T] . 172800 IN DNSKEY 256 3 8 ;{id = 20038 (zsk), size = 2048b}
> . 172800 IN DNSKEY 257 3 8 ;{id = 20326 (ksk), size = 2048b}
> [T] Existence denied: 11. DS
> ;; No ds record for delegation
> [T] Existence denied: 11. NS
>
> > Grato
> >
> > Roberto Braga
>
> Leia e entenda a BCP-20 ai você terá condições de discutir com os seus
> prestadores de serviço o que deve ser feito para que o seu reverso
> funcione e seja mantido sob o seu controle de maneira adequada.
>
> Fred
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação