[caiu] DNS do google

Francisco Neto fjbvneto em gmail.com
Domingo Maio 12 23:43:57 BRT 2013


Não, não estou buscando redenção para falha, ela passou, eu vi o que se
tratava e foi resolvido. O pior é que, de minha parte, realmente quando
falei nada, foi assim algo absoluto.

É bastante estranho algo que ocorreu, apos uma janela de modificações, que
inclusive foram superiores as 2h.

Cheguei a observar em alguns foruns a questão das falhas entre os clusters
do google DNS ... me parece que foi isto que ocorreu, não tenho como
afirmar e eles não entram em detalhes profundos.

Em relaão ao DS, eu assinei algo, ok, depois simplesmente removi a
assinatura, fiz rollback ! Algo comum. Após o rollback, tem o tempo de
propagação e pronto. O que falo é que, esta janela demorou muito. Foram
muitas horas !!! Muitissimo mais que meu baixo TTL de 300 e muito mais que
as 2h informadas.

A janela de erros foi maior que 2h, muitissimo maior. Ainda tem o fato
(Reportei ao google) que em algumas consultas que fiz em modo debug usando
8.8.8.8, observei valores de TTL que eu não tinha declarado.

Me encomodou pois, durante alguns minutos eu tive problemas com um IDC, que
num primeiro momento um troubleshotting ficou prejudicado pois a falha em
8.8.8.8 era ignorada !!!!! E eles estavam se baseando justamente nisto para
julgar um erro. Que o domínio não existia !!!!

O histórico post-mortem, contem o horário exato penso eu da modificação que
fiz ... o que julguei erro e estranho por parte do 8.8.8.8 e 8.8.4.4 é que,
isto DUROU MUITO !!! Estou falando de quase 20 horas no total geral...

Realmente, não esta correlato o desuso atual de DNSSEC com a política de
recursão, apenas citei, isto sim, por redenção rsrs.

Sim, por favor me envie então para eu ver do outro lado, se possível e
existir, favor enviar também um log de propagação. O máximo de dados que
tiver eu vou agradeçer.


Em 12 de maio de 2013 22:44, Rubens Kuhl <rubensk at gmail.com> escreveu:

> 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
> _______________________________________________
> caiu mailing list
> caiu at eng.registro.br
> https://eng.registro.br/mailman/listinfo/caiu
>
>
> --> PARA SAIR DA LISTA SIGA AS INSTRUÇÕES em:
>
> https://eng.registro.br/mailman/options/caiu
>


More information about the caiu mailing list