[caiu] DNS do google
Rubens Kuhl
rubensk em gmail.com
Domingo Maio 12 20:17:15 BRT 2013
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.br 8.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
More information about the caiu
mailing list