[caiu] DNS do google

Domingo Maio 12 21:50:51 BRT 2013

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...

O parent (srv do registro) não estava informando nada, pois eu tinha
removido a DS ...

Inclusive antes do fato (tudo foi observado no dia 10 e ontem pela
madrugada...inicio da manhã quando, sem eu fazer nada (a não ser a
alteração refletida no dia 10 da remoção das minhas entradas DS no registro
DS, logo 'desconfigurando' DNSSEC para minha zona).

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.

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.

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 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..

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 ?

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.

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...)

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

> 2013/5/12 Francisco Neto <fjbvneto at gmail.com>:
> > Cesar. Negativo. Como voce pode afirmar isto ?
>
> Ele pode sim afirmar que daquela vez que o DNSviz fez uma análise
> havia uma quebra de DNSSEC.
>
> O próprio DNSviz em análises posteriores notou que houve remoção do
> DS, é só seguir os links na página daquele teste específico.
>
> > A validação de DNS do google, é inclusive nova. E inclusive não sei se
> > (particularmente acho errado), que ele retorne um not found por uma falha
> > de um recurso de segurança (importante, claro que voltarei a ativar mas
> não
> > por hora), a afirmação de inexistencia de um dominio por uma falha na
> > observação de um recurso (Que não esta nem relacionado com uma consulta,
> > por exemplo, a consulta para o RR A não deveria retornar not found por
> > falta ou falha em DS... ou do SOA...)...
>
> Mas é assim que funciona DNSSEC. Um recursivo que valida descarta
> totalmente uma resposta não assinada se no parent está dito que é para
> esperar um resposta assinada. Não dá para diferenciar uma resposta sem
> assinatura por falta de gestão apropriada de uma resposta sem
> assinatura maliciosa vinda de alguém tentando interceptar o tráfego.
>
>
> > De fato, eu tinha ativado dnssec, mas desativei para realizar alguns
> testes
> > e analises. Mantenho meu TTL em 300 buscando rapida atualização
> justamente
> > para evitar atrasos, meu servidor fica estável e por isto 'não corro
> risco
> > de apagar'. ...
> >
> > Entre uma consulta e outra, via nslookup -debug teletalk.com.br8.8.8.8, EU
> > OBSERVEI E RELATEI A EQUIPE DO GOOGLE UM TTL (DEFAULT TTL) QUE EU NÃO
> > ESTAVA PUBLICADO NA MINHA ZONA, E ESTAVA SAINDO, SOMENTE PELA CONSULTA
> > USANDO 8.8.8.8 ... USANDO OUTROS (COMO O OPENDNS OU LEVEL 3...).. todas
> as
> > consultas saiam como eu configurei (os ttl´s 300 por exemplo)...
>  consegui
> > no site que informei, alguns emails e falei com eles interagimos na
> > madrugada... e eles efetuaram alguma ação, não sei qual, ONTEM, DIA 11
> ...
> > e ficou OK...
> >
> > Tome cuidado antes de afirmar onde estava um problema... seu eu
> considerei
> > que era no google, mandei os testes, fundamentei, era por que era. E
> mesmo
> > que a falha de DS existisse, e ainda tivesse com o DS errado (Ate hoje se
> > fosse o caso), mesmo assim, não justificaria uma consulta recursiva para
> um
> > RR (q=soa) retornar domain not found ... mesmo uma abordagem de combate a
> > phising, reforço de segurança.. não justifica isto.
>
>
> > Esta claro que a abordagem é errada.
>
> Você pode levar seu ponto de vista na IETF e ver se convence o pessoal
> a mudar as RFCs de DNSSEC... mas enquanto isso, também pode usar um
> hidden-master que mantém as assinaturas sempre atualizadas e evita
> perda de validação:
> http://registro.br/dnsshim
>
>
>
> 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
>