[caiu] DNS do google

[Rubens Kuhl]

2013/5/12 Francisco Neto <fjbvneto at gmail.com>:
> Rubens, você reparou no timestamp dos fatos ??
>
> Nas datas ??? Existe uma janela ai entre a alteração que fiz no registro
> (Exclusão da minha entrada DS) a janela de erros...

E existem também movimentos do próprio Google acontecendo em conjunto:
o atendimento pode ter variado e ido para um cluster que estava com
DNSSEC habilitado e já tinha uma resposta de antes que ainda estava
com DS.

> No momento em que o erro é acusado, EU NÃO TINHA MAIS DS ! Logo a consulta
> não tinha (não no registro.br) onde buscar.

Num mundo distribuído como DNS, você está aplicando raciocínios
instantâneos a sistemas que tem propagação.

> Pena que eu não guardei uma saida nslookup -debug teletalk.com.br que
> fiz,... tinha uma informação errada de TTL, todos os meus TTLS são 300...
> tinha uma de 6h
>
> A não ser questão de cache de resposta anterior...TTL inválido.. ou então,
> alguma resposta com TTL maior que eu configurei, como estes que aparece
> neste fluxograma ai do DNSVIZ... como os informados por .com.br.

Se tem DS no parent, e o domínio está com falha de assinatura, seu TTL
nunca é levado em conta, porque a recursão para.

> Eu removi minhas entradas de DS em um momento... e depois, o erro era
> observado... isto ainda não tinha sido refletido (pelo menos para 8.8.8.8),
> logo , a consulta estava errada SIM.
>
> O TTL de 1h informado também esta errado (Sob minha zona), o que eu não
> saberia precisar, é se o TTL informado 6h e 1d teria influencia, porem meu
> TTL (todos) estão setados para 300s

O TTL é baseado em quando a primeira resposta foi obtida, não do TTL
original daquele RRset.
Qualquer TTL entre 0 e o TTL original é um TTL possível para resposta
de um recursivo.


> O engraçado, é que, quando eu consegui contato, após algumas horas, na
> madrugada... voltou !
>
> E sabe o que eu fiz ??? NADA !
>
> A alteração no registro para remoção do DS (Desativar DNSSEC) que
> justamente fiz, após manter alguns dias ativos, e justamente pensando em
> automatizar de alguma forma o processo de atualização das chaves, pensei em
> remover/desconfigurar (fiz removendo DS no painel do registro.br) atualizei
> no registro, observei a remoção, estava OK, depois nos meus servidores,
> atualizei a configuração, relodei as zonas e até dei um restart no daemon
> do bind só para garantir..

Sua descrição de ações para mim são bem diferente de nada... além
disso, outras alterações no Google DNS podem ter acontecido que não
estão relacionadas ao teletalk.com.br e que teriam como efeito refazer
recursão.

> Existe uma janela de tempo ai, e a consulta não pode estar certa justamente
> pelo tempo...a alteração que fiz no registro.br foi anterior a janela de
> erros... logo, como ele poderia consultar ? Se no registro.br já não tinha
> mais DS, no final do dia 10 por exemplo ??? Outro detalhe, esta atualização
> não ocorre em 30m ?

O cache de DS dura mais que 30 minutos. De acordo com a DPS do .br, é
atualmente de 1 hora, e os experimentos de migração de zonas com
DNSSEC para sem DNSSEC feitos para o lançamento do recurso de DNS
autoritativo gratuito indicaram 2 horas como prazo total de "sumiço"
de uma delegação DS.

http://registro.br/suporte/servico-dns.html
"A publicação dos novos servidores DNS levará ao menos 2 horas, tempo
necessário para a remoção completa da chave DNSSEC utilizada no
domínio do sistema DNS."


> Ainda mantenho a opinião e acho que é lógica, pois algo assim, com carater
> de unificação (esta 'consulta unificada') só deveria ser padrão (ainda não
> é, veja que, até onde eu sei, apenas o google usa como padrão, nesta nova
> abordagem deles), não estou dizendo que é errado, mas para o atual momento
> (E só observar quantos domínios são assinados, aqui mesmo na lista, quantos
> sisadm´s aqui que administram domínios/zonas de DNS, as tem assinadas ????
> se pegar 'algumas grandes' ainda não são... logo, amarrar uma resposta
> erronea de inexistencia de domínio, atrelada a um tipo de consulta que
> ainda não é padrão, é uma desformidade.

O protocolo DNSSEC é um padrão definido em RFCs e cujo comportamento
esperado não é o que você gostaria.
Ele não ser tão usado como você alega não muda as políticas que
recursivos que sigam as RFCs devem aplicar.

> Seria como, atrelar o funcionamento do SMTP, ao uso do SPF por exemplo (Que
> também pode ser feito, algums MTA´s implementam inclusive, mas, não é
> padrão...)

Ao publicar um DS você declarou à comunidade que se não fosse assinado
daquela forma, deveria ser desconsiderado. Algo como você publicar num
jornal de grande circulação que só se deve aceitar e-mails do seu
domínio com SPF (isso inclusive tem nome no caso de e-mail: DMARC
http://www.dmarc.org).

Me parece que você está buscando redenção de uma falha de gestão desse
domínio ao culpar o serviço recursivo do Google na questão. Nem você
nem o Google são perfeitos e ambos podem errar, mas todo o histórico
do DNSviz indica que o Google apenas seguiu o protocolo DNSSEC
corretamente. Se você quiser podemos te mandar (só para você que é
contato técnico deste domínio, não para a lista) o histórico das
alterações no domínio para que você possa fazer um post-mortem do
ocorrido.


Rubens