Resumo

Neste artigo, discutimos a implementação do DNSSEC (Extensões de Segurança do Sistema de Nomes de Domínio) pelo Serviço Public DNS do Google. DNSSEC é uma tecnologia que adiciona assinaturas criptográficas seguras ao DNS para mitigar vulnerabilidades e garantir a integridade da resolução DNS. Enquanto o DNSSEC existe há muitos anos, sua adoção tem sido relativamente baixa. O DNS público do Google agora executa a validação do DNSSEC para todas as consultas por padrão, aprimorando a segurança de seu serviço de resolução DNS.

Pontos chave:

1. DNSSEC é uma tecnologia crítica que adiciona assinaturas criptográficas ao DNS para proteger contra ataques de DNS.
2. O DNSSEC garante a integridade e a autenticidade da resolução DNS, impedindo que os usuários sejam redirecionados para sites maliciosos.
3. O Public DNS do Google é um resolvedor de DNS amplamente utilizado que agora executa a validação DNSSEC por padrão para todas as consultas.
4. Ao implementar o DNSSEC, o DNS público do Google aprimora a segurança e a confiabilidade de seu serviço de resolução DNS.
5. A adoção do DNSSEC tem sido lenta devido a vários fatores, incluindo a falta de motivação entre administradores de nomes de domínio e autores do navegador.
6. Serviços como o Secspider acompanham o progresso da implantação do DNSSEC contando o número de nomes de domínio com credenciais DNSSEC.
7. Os laboratórios APNIC realizaram medições para quantificar a extensão da validação DNSSEC por aplicativos do usuário final.
8. Em suas medições iniciais, cerca de 9% dos clientes pareciam usar resolvedores de DNS que executaram a validação DNSSEC.
9. Uma medida mais recente mostrou que aproximadamente 1.6% dos clientes usaram exclusivamente resolvedores de DNS que executaram consistentemente a validação DNSSEC.
10. Esses resultados destacam os níveis relativamente baixos de adoção de DNSSEC e a necessidade de maior conscientização e implantação da tecnologia.

Perguntas únicas:

1. Por que o DNSSEC é importante para a segurança da resolução do DNS?
   O DNSSEC adiciona assinaturas criptográficas ao DNS, garantindo a integridade e a autenticidade da resolução do DNS. Sem DNSSEC, os usuários são vulneráveis ​​a ataques de DNS, onde seus aplicativos são direcionados para sites maliciosos, em vez do destino pretendido.
2. Qual é o significado do DNS público do Google, implementando a validação DNSSEC por padrão?
   O DNS público do Google é um resolvedor de DNS amplamente utilizado, e sua implementação da validação DNSSEC por padrão aprimora a segurança e a confiabilidade de seu serviço de resolução DNS. Isso garante que os usuários sejam protegidos contra ataques do DNS e possam ter mais confiança na precisão das resoluções de DNS fornecidas pelo DNS público do Google.
3. Por que a adoção do DNSSEC foi lenta?
   A adoção do DNSSEC tem sido lenta devido a vários fatores. Um fator significativo é a falta de motivação entre os administradores de nomes de domínio e os autores do navegador para assinar nomes de domínio com credenciais DNSSEC. Além disso, os baixos níveis de implantação de DNSSEC tornam menos atraente para as ferramentas do cliente incorporar a validação do DNSSEC na resolução do DNS.
4. Qual é o papel de serviços como o Secspider no rastreamento da implantação do DNSSEC?
   Serviços como o Secspider rastreiam o progresso da implantação do DNSSEC contando o número de nomes de domínio que incluem credenciais DNSSEC. Isso ajuda a medir até que ponto os nomes de domínio são assinados usando assinaturas DNSSEC e fornece informações sobre a adoção geral do DNSSEC.
5. Como os laboratórios Apnic quantificaram a extensão da validação DNSSEC por aplicativos do usuário final?
   Os laboratórios Apnic realizaram medições para determinar até que ponto os clientes usam a validação DNSSEC em conjunto com a resolução de nomes. Essas medidas envolveram observar o registro de consulta DNS em servidores de nomes autoritários e analisar a sequência e os horários das consultas de DNS para inferir os recursos DNSSEC de resolvedores de DNS visíveis.
6. Quais foram os resultados das medições iniciais dos laboratórios Apnic?
   As medições iniciais dos laboratórios Apnic mostraram que cerca de 9% dos clientes pareciam usar resolvedores de DNS que realizaram alguma forma de validação DNSSEC.
7. Que limitações foram observadas na abordagem de medição inicial?
   A abordagem de medição inicial usou geração dinâmica de etiquetas DNS exclusivas e uma cadeia de assinatura DNSSEC compartilhada. Essa abordagem se baseou no cache de resolvedor de DNS, o que afetou a precisão dos resultados. As medições subsequentes foram realizadas para abordar essas limitações.
8. Qual foi o resultado da medição mais recente dos laboratórios apnic?
   A medição mais recente mostrou que aproximadamente 1.6% dos clientes usaram exclusivamente resolvedores de DNS que executaram consistentemente a validação DNSSEC. Isso indica que a adoção da validação DNSSEC por aplicativos de usuário final ainda é relativamente baixa.
9. O que o baixo nível de adoção de DNSSEC implicou?
   O baixo nível de adoção do DNSSEC sugere a necessidade de maior conscientização e implantação do DNSSEC. Sem adoção mais ampla, os benefícios do DNSSEC, como nome de domínio seguro para mapeamento de endereço IP e provisão de chave pública do TLS por meio de tecnologias como Dane, permanecem subutilizadas.
10. Qual é o impacto potencial da adoção mais ampla do DNSSEC?
    A adoção mais ampla do DNSSEC aumentaria a segurança e a confiabilidade da resolução do DNS para todos os usuários. Isso reduziria o risco de ataques baseados em DNS e forneceria um mapeamento mais seguro entre nomes de domínio e endereços IP, fortalecendo a segurança geral da Internet.

Respostas:

1. DNSSEC é importante para a segurança da resolução do DNS porque
   O DNSSEC adiciona assinaturas criptográficas ao DNS, garantindo a integridade e a autenticidade da resolução do DNS. Sem DNSSEC, os usuários são vulneráveis ​​a ataques de DNS, como falsificação de DNS ou envenenamento por cache, onde seus aplicativos são redirecionados para sites maliciosos, em vez do destino pretendido. Ao validar as respostas do DNS usando o DNSSEC, os usuários podem ter mais confiança de que os endereços IP resolvidos estão realmente associados aos nomes de domínio pretendido.
2. O significado do DNS público do Google implementando a validação DNSSEC por padrão é
   O DNS público do Google é um dos resolvedores DNS mais utilizados e sua implementação da validação DNSSEC por padrão aprimora a segurança e a confiabilidade de seu serviço de resolução DNS. Com a validação DNSSEC, o DNS público do Google pode verificar a autenticidade e a integridade das respostas do DNS, protegendo os usuários de ataques baseados em DNS. Essa validação padrão garante que todas as consultas feitas através do DNS público do Google sejam submetidas a cheques de DNSSEC, fornecendo uma camada adicional de segurança para os usuários.
3. A lenta adoção do DNSSEC pode ser atribuída a
   Vários fatores contribuem para a lenta adoção do DNSSEC. Um fator é a falta de motivação entre os administradores de nomes de domínio para assinar seus nomes de domínio com credenciais DNSSEC. O esforço e a complexidade adicional envolvidos no gerenciamento de chaves e assinaturas do DNSSEC podem desencorajar os administradores de domínio de adotar o DNSSEC. Além disso, os autores do navegador podem ter relutado em implementar a validação do DNSSEC devido ao número limitado de nomes de domínio assinados. A baixa demanda por validação DNSSEC dos usuários também pode influenciar a motivação para implantar ferramentas clientes que suportam o DNSSEC. Esses fatores criam um ciclo de baixa adoção e incentivos limitados para implantação adicional.
4. Serviços como o Secspider rastreiam a implantação do DNSSEC por
   Serviços como o Secspider monitoram o progresso da implantação do DNSSEC contando o número de nomes de domínio que incluem credenciais DNSSEC. Ao digitalizar regularmente as zonas DNS e analisar as assinaturas de DNSSEC, o Secspider pode fornecer informações sobre a prevalência de nomes de domínio assinados e a adoção geral do DNSSEC. Esse rastreamento ajuda a aumentar a conscientização sobre as taxas de adoção do DNSSEC e incentiva os administradores de nomes de domínio a considerar a implementação do DNSSEC para seus domínios.
5. Os laboratórios Apnic quantificaram a extensão da validação DNSSEC por
   Os laboratórios APNIC quantificaram a extensão da validação do DNSSEC, realizando medições em aplicativos de usuário final. Essas medidas envolveram observar o registro de consulta DNS em servidores de nome autorizados e analisar a sequência e os horários das consultas DNS. Examinando as respostas e padrões de tempo, os laboratórios Apnic poderiam inferir se os resolvedores de DNS usados ​​pelos usuários finais executaram a validação DNSSEC. Esses dados forneceram informações sobre a proporção de aplicativos de usuário final que empregam ativamente a validação do DNSSEC durante a resolução de nomes.
6. Nas medições iniciais dos laboratórios Apnic, aproximadamente 9% dos clientes pareciam
   Nas medições iniciais da Apnic Labs, aproximadamente 9% dos clientes pareciam usar resolvedores de DNS que executaram alguma forma de validação de DNSSEC. Esta descoberta sugere um nível modesto de adoção de DNSSEC entre uma parte dos aplicativos do usuário final. Embora 9% possam ser considerados um número relativamente baixo, indica que um número significativo de usuários ou organizações optou por permitir a validação do DNSSEC, priorizando a segurança aprimorada que oferece.
7. As limitações observadas na abordagem de medição inicial pelos laboratórios apnic foram
   A abordagem de medição inicial usada pelos laboratórios Apnic teve algumas limitações. Uma limitação foi a dependência do cache de resolver do DNS. O experimento envolveu uma campanha publicitária on -line que inscreveu milhões de clientes finais para executar tarefas de recuperação de objetos DNS. A cadeia de assinatura DNSSEC compartilhada ao longo do experimento significou que, uma vez que um resolvedor de DNS recuperou os registros de recursos DNSSEC (RRS), as consultas subsequentes para o mesmo DNSSEC RRs foram servidas do cache local do resolvedor. Esse comportamento de armazenamento em cache dificultou a avaliação com precisão dos recursos reais do DNSSEC de cada resolvedor e resultou em possíveis superestimações da adoção de DNSSEC.
8. Em uma medida mais recente, aproximadamente 1.6% dos clientes usaram exclusivamente resolvedores de DNS que
   Em uma medida mais recente da Apnic Labs, aproximadamente 1.6% dos clientes usaram exclusivamente resolvedores de DNS que executaram consistentemente a validação DNSSEC. Isso indica que a adoção da validação DNSSEC por aplicativos de usuário final ainda é relativamente baixa. Embora tenha havido um aumento menor em comparação com as medições anteriores, ele destaca a necessidade de adoção mais difundida de DNSSEC entre resolvedores de DNS e aplicativos de usuário final.
9. O baixo nível de adoção de DNSSEC implica que
   O baixo nível de adoção do DNSSEC implica que todo o potencial do DNSSEC ainda está para ser realizado. Com apenas uma pequena porcentagem de clientes e administradores de nomes de domínio usando ativamente o DNSSEC, os benefícios do nome de domínio seguro para o mapeamento de endereços IP e o fornecimento público de chave TLS por meio de tecnologias como Dane permanecem subutilizadas. A adoção mais ampla do DNSSEC contribuiria para uma infraestrutura mais segura da Internet, reduzindo o risco de ataques baseados em DNS e garantindo comunicações seguras entre clientes e servidores.
10. O impacto potencial da adoção mais ampla de DNSSec inclui
    A adoção mais ampla do DNSSEC aumentaria significativamente a segurança e a confiabilidade da resolução do DNS para todos os usuários. Isso reduziria o risco de ataques baseados em DNS, como envenenamento por cache do DNS e seqüestro de DNS, protegendo os usuários de serem redirecionados para sites maliciosos. Além disso, o DNSSEC fornece um mapeamento seguro entre nomes de domínio e endereços IP, garantindo que os usuários estejam se conectando aos servidores pretendidos. Isso fortalece a segurança geral da Internet e promove a confiança nas interações on -line.

Confirmado – Google’S DNS público agora executa a validação DNSSEC para todas as consultas por padrão

O Google investiu pesadamente em segurança de TI e, acho que fez um trabalho decente. Todos os serviços são TLs por padrão, identidade e autorização são bem tratados.

DNSSEC e Google’s Serviço Public DNS

O sistema de nomes de domínio, ou o DNS, é um componente crítico, mas um tanto invisível da Internet. O mundo da internet é um mundo de símbolos e palavras. Invocamos aplicativos para interagir com serviços como Google, Facebook e Twitter, e a interação é formulada em símbolos legíveis humanos. Mas a interação com a rede é inteiramente em um formato binário. Então, nossa visão simbólica de um serviço, como www.Google.com, deve ser traduzido em um endereço de protocolo, como 74.125.237.144. O mapeamento de símbolos para endereços de protocolo é uma das funções críticas do DNS. Nós confiamos não apenas na presença contínua do DNS, mas também sua operação correta. Entrando no mybank.com.Au em um navegador não garante necessariamente que sua interação será com o seu serviço pretendido. Um dos vetores de ataque mais insidiosos da Internet é corromper deliberadamente a operação do DNS e, assim, enganar o aplicativo do usuário para abrir uma sessão com o destino errado. A resposta mais robusta que conseguimos elaborar para mitigar essa vulnerabilidade de longa data no DNS tem sido adicionar assinaturas criptográficas seguras ao DNS, usando uma tecnologia chamada DNSSEC. Mas estamos usando o DNSSEC hoje’s Internet?

A história do DNSSEC tem fortes semelhanças com a de IPv6. Como o IPv6, o DNSSEC existe há muitos anos, mas sua defesa. Como o IPv6, o DNSSEC é mais eficaz quando todos estão usando, e os retornos marginais da adoção fragmentada são extremamente baixos. E, como o IPv6, os níveis relativamente baixos de implantação e uso do DNSSEC não refletem o esforço de longa data para elevar a visibilidade da tecnologia e os esforços concertados para divulgar os benefícios claros a longo prazo no uso dessa tecnologia.

Mesmo quando os perigos insidiosos de um ataque à integridade do DNS e da infraestrutura de certificado de nomes de domínio amplamente utilizados foram claramente demonstrados no incidente do DiginOtar em 2011, os benefícios potenciais do uso do DNSSEC e a adoção de uma estrutura segura de falha no nome do domínio do IP através do Digital. De certa forma, há uma forma de impasse mútuo: enquanto poucos clientes usam DNSSec, parece haver pouca motivação por parte dos administradores de nome de domínio para usar o DNSSEC para assinar nomes de domínio. E embora existam tão poucos nomes de domínio assinados, há pouca motivação para implantar ferramentas de cliente para incorporar a validação do DNSSEC na resolução do DNS. E embora os nomes de domínio sejam amplamente não assinados e tão poucos clientes usam o DNSSEC para validar os resultados da resolução de nomes do DNS, não há motivação para os administradores de nomes de domínio ou os autores do navegador usarem a tecnologia Dane para fornecer uma forma segura de mapeamento de um nome de domínio para o endereço IP e uma chave pública tls.

Podemos quantificar até que ponto o DNSSEC foi implantado e usado hoje’s Internet? Uma maneira é medir até que ponto os nomes de domínio são assinados usando assinaturas de DNSSEC. Serviços como o Secspider rastreiam o progresso da assinatura de domínio nos vários níveis superior e nas zonas DNS de segundo nível, contando o número de nomes de domínio que incluem credenciais DNSSEC. Mas a outra metade da pergunta também é relevante aqui. Até que ponto os aplicativos de usuário final usam resolvedores de DNS que executam a validação do DNSSEC ao resolver um nome? E, mais criticamente, até que ponto os aplicativos do usuário final se absterão de usar um resultado de resolução de nomes do DNS se o nome do domínio for assinado DNSSEC, e a validação de assinatura DNSSEC associada falhar?

Em Apnic Labs nós’Estive olhando para esta segunda pergunta, tentando quantificar até que ponto os clientes usam a validação DNSSEC em conjunto com a resolução de nomes. Nossos esforços iniciais foram realizados em outubro e novembro de 2012. O primeiro exercício de medição em outubro de 2012 apontou para cerca de 9% dos clientes que pareciam usar os resolvedores de DNS que foram vistos para executar alguma forma de validação DNSSEC. Um reencontro do experimento em novembro de 2012 forneceu o resultado de que cerca de 1.6% dos clientes que pareciam usar exclusivamente resolvedores de DNS que executaram consistentemente a validação do DNSSEC.

Nenhum desses resultados foi tão satisfatório, e a causa desse nível de inquietação com os resultados estava tentando levar em consideração os efeitos do resolvedor de DNS em cache nos resultados do experimento no experimento. Em ambos os experimentos, usamos uma campanha publicitária on -line para matricular milhões de clientes finais para realizar uma coleção de objetos para recuperar e, em ambos os casos, usamos curingas no DNS e a geração dinâmica de etiquetas DNS exclusivas para apresentar a cada cliente um conjunto de nomes de DNS exclusivos para resolver. No entanto, a fraqueza exposta nessa abordagem, na medida em que uma única cadeia de assinatura DNSSEC foi compartilhada em todo o experimento. This meant that once a DNS resolver had retrieved the DNSSEC Resource Records (RRs) for the experiment’s DNS names (the DNSKEY and DS RRs of the signed zone containing the wildcard entry) it served all subsequent DNSSEC RR queries from its local cache, only refreshing the cached data upon expiry of the cache lifetime of the stored records (which was set to one hour). Dado que nosso ponto de observação para o experimento foi o registro de consulta DNS no servidor de nome autoritário, fomos forçados a inferir os recursos do DNSSEC de cada um dos resolvedores DNS visíveis com base na sequência de consultas DNS, como visto no servidor de nome autoritário e nos tempos entre as consultas. Essas experiências encontraram um limite superior aproximado de cerca de 9% dos clientes usando resolvedores de validação de DNSSEC usando um teste bastante liberal para a validação DNSSEC e um limite inferior aproximado de 1.6% dos clientes que usaram os resolvedores de validação do DNSSEC usando um conjunto muito mais rigoroso de restrições de regras de inferência. Obviamente, estamos interessados ​​em reduzir a incerteza nessas medições, se pudermos.

Ao revisar os experimentos anteriores, observamos que uma maneira de remover a necessidade de inferir o comportamento do resolvedor de DNS era usar uma configuração DNS removida, tanto quanto possível, os efeitos do comportamento do cache do resolver DNS. Em vez de usar um curinga simples em um domínio sinalizado com DNSSEC comum, se pudéssemos apresentar a cada cliente um domínio exclusivo de sinalização de DNSSEC, o rótulo exclusivo forçaria qualquer resolução de nome que validava a DNSSEC para recuperar o DNSSEC RRS do servidor de nome autoritário para esta zona de DNS exclusiva. Em outras palavras, se os resolvedores do cliente estivessem executando a validação do DNSSEC, o servidor de nomes autoritário não apenas receberia as consultas A para o endereço do nome do domínio, mas também receberá as consultas DNSKEY e DS como parte da fase de validação do DNSEC. Essa abordagem nos permitiria determinar com um maior nível de precisão quantos clientes estavam usando o DNSSEC para validar nomes de DNS. Esta estrutura de nome do DNS é mostrada na Figura 1.

Figura 1: Estrutura de nomes de domínio usada para medir o comportamento de validação DNSSEC

Executamos esta versão do experimento de medição DNSSEC de 8 a 18 de março de 2013.

Em 19 de março. Em seu anúncio, o Google informou que:

“Atualmente, o Google Public DNS está cumprindo mais de 130 bilhões de consultas DNS em média (atingindo o pico de 150 bilhões) de mais de 70 milhões de endereços IP exclusivos por dia. No entanto, apenas 7% das consultas do lado do cliente são ativadas por DNSSEC (cerca de 3% solicitando validação e 4% solicitando dados DNSSEC, mas sem validação) e cerca de 1% das respostas DNS do lado do servidor de nome são assinadas.”

Este anúncio parecia apresentar uma oportunidade ideal para um “antes e depois” Exercício, ao realizar o exercício de medição DNSSEC no período imediatamente após o Google’S Mudança aparente para seus resolvedores para executar a validação DNSSEC. Qual o impacto que essa mudança teria na imagem geral dos clientes que realizam validação DNSSEC? Reastamos o mesmo experimento de 22 de março a 1º de abril de 2013 para medir até que ponto este anúncio de uma mudança pelo Google’Os servidores públicos DNS mudaram a imagem geral dos clientes que usam a validação DNSSEC.

Neste momento, o Google não ligou para a validação DNSSEC incondicionalmente. Para citar de material adicional publicado pelo Google:

O Google Public DNS suporta o protocolo DNSSEC?
Sim. O Google Public DNS é um resolvedor de validação e com reconhecimento de segurança. Atualmente, este é um recurso de inscrição: para consultas provenientes de clientes que solicitam validação (o anúncio e/ou o sinalizador está definido), o Google Public DNS verifica se os registros de resposta são corretamente autenticados. Validação por padrão (i.e. para todas as consultas) será ativado em breve.

Quais resolvedores de clientes atualmente permitem DNSSEC?
Infelizmente, a maioria dos resolvedores de stub de cliente padrão não permite a verificação completa do DNSSEC e não pode ser facilmente reconfigurado para fazê -lo. Decidimos fazer nosso lançamento inicial apenas os resolvedores de cobertura que solicitam explicitamente a verificação do DNSSEC, para que tomemos conhecimento de qualquer problema antes de expor nossos usuários a possíveis falhas de DNS em larga escala devido a equívocos de DNSSEC ou interrupções. Uma vez felizes por podermos ativar com segurança o DNSSEC para todos os usuários, exceto aqueles que optam explicitamente, faremos isso.

A implicação é que, atualmente, se a consulta DNS do cliente não solicitar a validação do DNSSEC, o Google Public DNS retornará um resultado sem executar nenhuma forma de validação DNSSEC da resposta. O material do Google indica que uma solicitação de validação DNSSEC está marcada por uma consulta DNS com o anúncio ou o conjunto de bandeiras do DO.

O que são essas bandeiras de consulta DNS?

DNSSEC e DNS Consultam sinalizadores

O protocolo DNS, conforme definido na RFC 1034 e RFC 1035, não incluiu nenhuma disposição específica para validação de respostas DNS. O protocolo é um protocolo de consulta/resposta simples. O cliente gera uma consulta DNS composta por um cabeçalho preenchido e uma seção de consulta, e a resposta contém o mesmo cabeçalho e seções de consulta juntamente com resposta, autoridade e seções adicionais.

O DNSSEC é uma extensão compatível com versões anteriores ao protocolo DNS, definido no RFCS RFC 4033, RFC 4034, RFC 4035, RFC 5155 e RFC 6840. Existem três bandeiras em uma consulta DNS que contêm instruções explícitas de DNSSEC para um resolvedor.

A bandeira do DO
O primeiro faz parte dos mecanismos estendidos para o DNS (EDNS0), definido no RFC 2671. Se o dnssec ok (FAZER) Bit está definido em uma consulta, então isso é interpretado como um sinal de que a resposta deve incluir dados DNSSEC em sua resposta. Se a resposta for um registro de recursos de uma zona sinalizada para DNSSEC, a resposta deve incluir a assinatura do registro de recursos (RRSIG RR) em adicional à resposta do registro de recursos. Se não houver esse domínio, a resposta deve incluir NSEC ou NSEC3 RRs em sua resposta.

A bandeira do CD
O segundo é o sinalizador desativado (CD). Se esse sinalizador estiver definido em uma consulta, o resolvedor deverá retornar as informações solicitadas, incluindo os registros do RRSIG, conforme apropriado, se o sinalizador for definido, mas não deve tentar validar as assinaturas incluídas na resposta. Ao definir o bit CD em sua consulta, o resolvedor de origem está indicando que está assumindo a responsabilidade de executar a autenticação da resposta e que o servidor de nome recursivo que está sendo consultado não deve interferir com esta função.

A bandeira do anúncio
A última bandeira é o sinalizador de dados autenticado (AD). Esta bandeira tem um significado um tanto pouco claro. Até o início de 2013, o documento de padrões era RFC4035:

4.6. Manuseio do CD e bits
& nbs [;
Um resolvedor de preciosidade de segurança deve limpar o bit de anúncio ao compor mensagens de consulta para proteger contra servidores de nomes de buggy que copiam cegamente os bits do cabeçalho que eles não entendem da mensagem de consulta para a mensagem de resposta.

Em fevereiro de 2013, o RFC6840 foi publicado, com a seguinte definição de RE do bit de anúncio:

5.7. Definindo o bit de anúncio em consultas
A semântica dos dados autênticos (AD) na consulta foram anteriormente indefinidos. Seção 4.6 de [RFC4035] instruíram os resolvedores a sempre limpar o bit de anúncio ao compor consultas.

Este documento define definir o bit de anúncio em uma consulta como um sinal indicando que o solicitante entende e está interessado no valor do bit de anúncio na resposta. Isso permite que um solicitante indique que ele entende o bit de anúncio sem também solicitar dados DNSSEC por meio

5.8. Definindo o bit de anúncio nas respostas
Seção 3.2.3 de [RFC4035] descreve em quais condições um resolvedor de validação deve definir ou limpar o bit de anúncio em uma resposta. Para interoperar com os resolvedores de stub e caixas médias que não entendem nem ignoram o bit de anúncio, validando resolvedores deve definir apenas o bit de anúncio quando uma resposta atende às condições listadas na Seção 3.2.3 de [RFC4035], e a solicitação continha um bit de conjunto ou um bit de anúncio definido.

Configurações combinadas de sinalizador

O efeito de várias configurações de sinalizador de combinações em consultas enviadas para resolvedores é mostrado na tabela a seguir.

 Faça efeito de CD AD 0 0 0 O resolvedor pode ou não executar a validação DNSSEC. Nenhum DNSSEC RRS é transmitido de volta na resposta. 0 0 1 O resolvedor deve executar a validação. Nenhum DNSSEC RRS é transmitido de volta na resposta 0 1 0 O resolvedor não deve executar a validação DNSSEC. Nenhum RRS DNSSEC é transmitido de volta na resposta 0 1 1 Sinais mistos! As ações do resolvedor são indefinidas. 1 0 0 O resolvedor deve executar a validação e retornar o DNSSEC RRS em sua resposta 1 0 1 O resolvedor deve executar a validação e retornar o DNSSEC RRS em sua resposta 1 1 0 O resolvedor não deve executar a validação do DNSSEC, mas deve retornar o DNSSEC RRS em sua resposta 1 1 1 1 sinais misturados! As ações do resolvedor são indefinidas. 

Tabela 1: Configurações de sinalização DNSSEC em consultas DNS

Deve-se notar que, quando o resolvedor é instruído a não executar a validação do DNSSEC, o resolvedor deve responder com os registros de recursos solicitados, mesmo no caso de os registros de recursos serem assinados por DNSEC e a assinatura é inválida.

DNS Resolver comportamento e DNSSEC

O modelo conceitual mais simples da resolução DNS envolvendo um cliente, um resolvedor de DNS e uma coleção de servidores de nome autorizados, como mostra a Figura 2.

Figura 2 – Modelo simples de resolução DNS para o nome de domínio “x.y.z”

Quando o cliente consulta seu resolvedor de DNS para resolução de um nome de domínio, como x.y.Z, então o resolvedor do DNS, assumindo que ele possui um estado de cache limpo, primeiro enviaria esta consulta para um servidor de nomes de raiz. O servidor responderia com o conjunto de servidores de nomes autoritários para o domínio de nível superior z.. O resolvedor do DNS enviaria a mesma consulta para um desses servidores de nomes para z., que responderia com os servidores de nomes para o domínio y.z.. O resolvedor do DNS consultará um desses servidores de nomes para o nome DNS x.y.z., E então passará a resposta que recebe de volta ao cliente. A sequência de consultas DNS enviadas por este resolvedor de DNS depois de receber a consulta inicial do cliente seria a seguinte:

 # Consulta rr nomes servidor Resposta 1. A x.y.z. . Ns para "z."2. A x.y.z. z. Ns para "y.z."3. A x.y.z. y.z. A para "x.y.z." 

Figura 3 – Consultas DNS sem validação DNSSEC

E se este resolvedor de DNS fosse um resolvedor de validação DNSSEC? Isso envolveria consultas DNS adicionais, pois o resolvedor de DNS precisa validar o registro do RRSIG para o registro de recursos recuperado. Esta validação envolve um “traço traseiro” até a hierarquia de delegação do DNS, seguindo a cadeia de Dnskey e DS RRs até atingir um ponto de confiança, que, neste caso, é a chave de assinatura para a zona raiz. O conjunto equivalente de consultas DNS para um resolvedor de validação de DNSSEC, depois de receber a consulta inicial do cliente, seria a seguinte:

 # Consulta rr nomes servidor Resposta 1. A EDC x.y.z. . Ns para "z." + Rrsig 2. A EDC x.y.z. z. Ns para "y.z." + Rrsig 3. A EDC x.y.z. y.z. A para x.y.z. + Rrsig 4. DNSKEY EDC Y.z. y.x dnskey para zona "y.z " + rrsig 5. Ds edc y.z. z. DS para a zona "y.z " + rrsig 6. DNSKEY ECD Z. z. Dnskey para zona "z." + Rrsig 7. Ds edc z. . DS para zona "Z." + Rrsig 8. DNSKEY EDC . . DNSKEY PARA ZONA ".a" 

Figura 4 – Consultas DNS com validação DNSSEC

As três consultas iniciais são semelhantes, mas agora as consultas emitidas por este resolvedor de DNS validador de DNSSEC incluem o EDNS0 (E) extensão e o dnssec ok (D) e a verificação desativada (C) bandeiras. Em cada caso o FAZER O sinalizador sinaliza que as respostas dos servidores autorizados devem incluir o RRSIG RRS, se as zonas forem realmente sinalizadas para DNSSEC.

Se procurássemos as transações no servidor autoritário para a zona y.z. veríamos uma consulta A seguida de uma consulta DNSKEY. Se estivéssemos olhando as transações no servidor autoritário para a zona pai z., Haveria uma consulta A, seguida por uma consulta DS e uma consulta DNSKEY. E se usássemos o mesmo servidor de nome autoritário para ambos Z. e x.z. Então este servidor de nome veria uma consulta para x.y.z., seguido por consultas dnskey e ds para y.z.

A partir deste exemplo, parece viável categorizar os resolvedores de DNS em resolvedores validadores e não validantes de DNSSec com base na observação das consultas DNSKey e DS no servidor de nome autoritário. Se observarmos consultas como na Figura 3, o resolvedor do DNS é um resolvedor não validador e, se forem como na Figura 4, o resolvedor será um resolvedor de valor validado por DNSSEC. Infelizmente, essa forma simples de uma categorização não é possível, pois a imagem da resolução DNS pode ser muito mais complexa do que a imagem simples da Figura 2.

Um resolvedor de DNS pode ser configurado para usar um “encaminhador”. Nesse caso. A vantagem de usar um encaminhador é alavancar a eficiência do cache dos resultados do DNS. As variantes desta configuração do resolvedor permitem que a função de encaminhamento seja limitada à resolução de zonas DNS específicas, em vez de aplicá -la a todas as consultas. Um resolvedor também pode ser configurado para voltar a uma resolução recursiva se os encaminhadores não fornecerem uma resposta. Há também “Resolver Farms” No DNS, onde um único encaminhador lógico pode aceitar consultas DNS, mas depois usar uma coleção de resolvedores de DNS de escravos para realizar as consultas. A imagem idealizada da resolução do DNS na Figura 2 deve ser aumentada um pouco para ilustrar o nível de complexidade potencial envolvido com a resolução do DNS. A Figura 5 mostra algumas das configurações possíveis.

Figura 5 – Algumas estruturas de resolução do DNS com encaminhadores

No contexto do experimento que estamos realizando aqui, instrumentamos apenas o servidor de nome autoritário e só vemos as consultas do DNS enviadas por”visível” Resolventes de DNS para este servidor. Assim, em termos de resolvedores diretamente visíveis, a visão da infraestrutura de resolução do DNS está mais próxima do que mostrou na Figura 6. Aqui, a estrutura interna dos encaminhadores do DNS é efetivamente ocluída do servidor de nome autoritário, e o servidor só pode ver os resolvedores que passam por consultas.

Figura 6 – Estruturas de resolução DNS

A implicação aqui é que, embora essa abordagem experimental possa fornecer uma boa visão dos recursos de validação do DNSSEC dos clientes, requer algum nível de inferência e um nível associado de incerteza das regras de inferência do aplicativo, para inferir o comportamento de validação do DNSSEC dos resolvedores de DNS. Por exemplo, se um resolvedor de validação de DNSEC usar um encaminhador não validador, o servidor de nomes autoritário verá uma sequência de consultas do encaminhador com os sinalizadores DO e CD que são consistentes com a validação DNSSEC. Se um resolvedor não validador de não-DNSSEC usar como encaminhador um resolvedor validador de DNSSEC, o servidor de nomes autoritário poderá ver precisamente a mesma sequência de consultas deste encaminhador.

O experimento de medição DNSSEC

Neste experimento, um objeto Adobe Flash está incorporado em um anúncio online. O código é executado após a apresentação do anúncio e não exige que o usuário clique na impressão do anúncio.

O código faz com que o cliente recupere um objeto de um controlador experimental, que alimenta o cliente com 4 URLs para buscar. Os três primeiros URLs devem ser buscados imediatamente, enquanto o quarto URL deve ser buscado quando os três primeiros objetos forem buscados, ou após o término de um temporizador de 10 segundos, o que ocorrer primeiro. Todos esses URLs incluem um rótulo DNS exclusivo. Um exemplo de conjunto de quatro URLs é mostrado abaixo. O gerador de URL gera um conjunto de valores exclusivos para cada experimento. Esses campos únicos são destacados em cores.

 d http: //.U7280280162.S1364784185.V6022.69DA1.z.dotnxDomain.net/1x1.png?d.U7280280162.S1364784185.V6022.69DA1.z.dotnxDomain.líquido e http: // e.U7280280162.S1364784185V6022.69DA1.z.DashnxDomain.net/1x1.png?e.U7280280162.S1364784185.V6022.69DA1.z.DashnxDomain.líquido f http: // f.U7280280162.S1364784185.V6022.69DA2.z.dotnxDomain.net/1x1.png?f.U7280280162.S1364784185.V6022.69DA2.z.dotnxDomain.líquido resultado http: // resultados.U7280280162.S1364784185.V6022.69DA1.x.rand.apnic.net/1x1.png?resultados.U7280280162.S1364784185.I767.V6022.69DA1& r = 

Como mostrado no exemplo acima, três URLs compartilham um rótulo DNS hexadecimal, “69DA1 ″ neste caso, enquanto o outro URL inclui um rótulo que é maior em valor, “69DA2” Neste caso. O primeiro URL, começando com a etiqueta D, usa uma combinação de um disco curinga e domínio assinado por DNSSEC. Nesse caso. O segundo URL, começando com o rótulo E, usa a mesma combinação, mas neste caso o domínio não é sinalizado DNSSEC assinado. O terceiro URL, começando com a etiqueta F, também usa uma combinação de um domínio curinga e domínio assinado por DNSSEC. No entanto, neste caso, a assinatura DNSSEC é inválida, na medida em que o registro do DS para a zona 69DA2.z.dotnxDomain.A rede não corresponde aos registros DNSKey correspondentes. O URL dos resultados não é assinado DNSSEC. A ordem da apresentação dos URLs no script é fixa como a sequência com o URL final atrasado por 10 segundos, ou a busca bem -sucedida dos três primeiros URLs, o que ocorrer primeiro. O cliente é instruído a iniciar temporizadores para a busca dos urls d, e e f, e relatar os valores do timer nos resultados URL.

Nossa intenção era garantir que cada cliente fosse apresentado com um rótulo DNS assinado exclusivamente, garantindo que não houvesse estado em cache em nenhum resolvedor de DNS ou em qualquer servidor de proxy da Web. O resultado disso é que cada experimento causa um conjunto de transações DNS e HTTP com os servidores DNS autoritários e os servidores da Web para esses nomes de domínio.

O experimento usa um único servidor, que contém um servidor de nome DNS (Executando o Bind 9.9.2-P1) e um servidor da web (executando o Apache V2.2.23). Este servidor é o único servidor de nome autoritário para os domínios usados ​​nesses quatro URLs, e o ponto A RRS apenas para este servidor. Neste experimento, configuramos deliberadamente todo o experimento usando IPv4, deixando a investigação de IPv6 e DNSSEC para outras experiências.

Embora os recursos de validação do DNSSEC de resolvedores individuais de DNS sejam um tanto difíceis de inferir a partir dessa forma de experimento, damos um passo atrás e colocamos a questão de saber se o usuário final usa a validação do DNSSec por meio de seus resolvedores de DNS configurados, então isso é possível deduzir do log de DNS presta e http fethes para o servidor. Um exemplo de extrato dos logs DNS e HTTP do servidor, relacionado a um único experimento (U5158122700.S1364428847 neste caso) é mostrado abaixo.

 Consulta de servidor DNS -Ed em um e.U5158122700.S1364428847.V6022.5e3bf.z.DashnxDomain.DNS líquido -Ed em um f.U5158122700.S1364428847.V6022.5E3C0.z.dotnxDomain.DNS líquido -Ed em um D.U5158122700.S1364428847.V6022.5e3bf.z.dotnxDomain.líquido http get/crossDormain.xml e.U5158122700.S1364428847.V6022.5e3bf.z.DashnxDomain.http net get /1x1.png e.U5158122700.S1364428847.V6022.5e3bf.z.DashnxDomain.líquido http get /crossDormain.xml d.U5158122700.S1364428847.V6022.5e3bf.z.dotnxDomain.http net get /1x1.png d.U5158122700.S1364428847.V6022.5e3bf.z.dotnxDomain.líquido http get /crossDormain.xml f.U5158122700.S1364428847.V6022.5E3C0.z.dotnxDomain.http net get /1x1.png f.U5158122700.S1364428847.V6022.5E3C0.z.dotnxDomain.DNS líquido -ed em um resultado.U5158122700.S1364428847.V6022.5e3bf.x.rand.apnic.líquido http get /crossDormain.Resultados XML.U5158122700.S1364428847.V6022.5e3bf.x.rand.apnic.http net get /1x1.png?resultados.U5158122700.S1364428847.I767.V6022.5e3bf & r = zd-1923.ZE-1578.ZF-1578 

Figura 7 – Logs de servidores de um experimento que não executou a validação DNSSEC

Este experimento gerou 4 consultas DNS e 8 consultas http. Todas as consultas do DNS usaram o sinalizador DNSSEC OK (do)“-Ed” No log indica que a resolução recursiva da consulta foi desativada (-), o EDNS0 estava sendo usado (e) e os registros de recursos de assinatura DNSSEC foram solicitados, se disponível (d)). No entanto, o resolvedor do DNS está pedindo um RRS, mas não pedindo DNSKEY ou DS RRS. Parece que, embora o resolvedor tenha definido a bandeira DNSSEC OK, ele não está executando nenhuma forma de validação DNSSEC no valor retornado no RRSIG RRS.

O cliente recuperou os três URLs (D, E e F). Considerando que o F URL possui uma assinatura DNSSEC inválida, então isso confirma que o resolvedor de DNS sendo usado por esse cliente não executa nenhuma validação DNSSEC. A linha de resultado também inclui um resultado do timer do lado do cliente, e o cliente está relatando que a Experiência D levou o cliente 1.923ms para carregar, e levou 1.578ms e F levou 1.578ms. O tempo um pouco mais longo para executar a busca de URL em comparação com a busca de URL pode ser devido ao cache do resolvedor da resolução de Z.dotnxDomain.rede durante a resolução do URL D, e usando os valores em cache ao resolver o f url.

Agora, por outro lado, a seguir é um extrato dos mesmos toras que mostram as consultas DNS recebidas pelo servidor de nome autoritário de um resolvedor de DNS que parece estar executando a validação do DNSSEC.

 Consulta de servidor DNS A -EDC em A D.U94278337.S1364428957.V6022.5E4E3.z.dotnxDomain.NET DNS A -EDC em um e.U94278337.S1364428957.V6022.5E4E3.z.DashnxDomain.NET DNS A -EDC em DNSKEY 5E4E3.z.dotnxDomain.NET DNS A -EDC em DS 5E4E3.z.dotnxDomain.NET DNS A -EDC em um F.U94278337.S1364428957.V6022.5E4E4.z.dotnxDomain.NET DNS A -EDC em DNSKEY 5E4E4.z.dotnxDomain.NET DNS A -EDC em DS 5E4E4.z.dotnxDomain.DNS líquido B -EDC em um f.U94278337.S1364428957.V6022.5E4E3.z.dotnxDomain.NET DNS B -EDC no DNSKEY 5E4E4.z.dotnxDomain.DNS NET B -EDC no DS 5E4E4.z.dotnxDomain.líquido http get /crossDormain.xml d.U94278337.S1364428957.V6022.5E4E3.z.dotnxDomain.http net get /1x1.png d.U94278337.S1364428957.V6022.5E4E3.z.dotnxDomain.líquido http get /crossDormain.xml e.U94278337.S1364428957.V6022.5E4E3.z.DashnxDomain.http net get /1x1.png e.U94278337.S1364428957.V6022.5E4E3.z.DashnxDomain.NET DNS A -EDC em um resultado.U94278337.S1364428957.V6022.5E4E3.x.rand.apnic.líquido http get /crossDormain.Resultados XML.U94278337.S1364428957.V6022.5E4E3.x.rand.apnic.http net get /1x1.png?resultados.U94278337.S1364428957.I767.V6022.5E4E3 & R = ZD-1572.ZE-1269.zf-null 

Figura 8 – Logs do servidor de um experimento que executou a validação DNSSEC

Nesse caso, o cliente recuperou dois URLs (D e E) e não recuperou o URL associado ao nome do domínio F que falhou na validação do DNSSEC.

O resolvedor do DNS está executando a validação DNSSEC, como evidenciado pela recuperação do DNSKEY e DS RRS para as zonas de domínio D e F. A primeira resolução do DNS para o nome do domínio F falhou na validação DNSSEC, e o cliente parece ter recebido uma resposta do servFail. O cliente tentou seu segundo resolvedor configurado, que também executa a validação do DNSSEC. Nesta fase, o cliente desistiu de tentar resolver o nome de domínio F. Após a expiração do temporizador de 10 segundos, o cliente buscou o URL do resultado. A linha de resultado também inclui um resultado do timer do lado do cliente, e o cliente está relatando que o D URL levou o cliente 1.572ms para carregar, e levou 1.269ms e F não foi recuperado. The slightly longer time to perform the d fetch as compared to the e fetch could be due in part to the resolver’s retrieval of the DNSKEY and DS RRs for the d domain, and the associated DNSSEC validation operation that was performed by the validating resolver, as the client would not receive the result of the d DNS query until and the additional queries associated with DNSSEC validation had been completed.

O objetivo deste experimento é provar um grande conjunto aleatório de clientes de toda a Internet e fazer com que seu navegador execute este experimento. Se o conjunto de transações no servidor se assemelha ao primeiro conjunto de transações mostradas acima, podemos concluir e o cliente não estiver usando o DNSSEC, enquanto o conjunto de transações se assemelha ao segundo conjunto mostrado acima, o cliente estiver usando os resolvedores DNS que executam a validação do DNSSEC para proteger sua função de resolução de nome.

Nesta configuração experimental, o único componente acessível que podemos equipar com a instrumentação é o servidor autoritário para o domínio “dotnxDomain.líquido.”. Se o resolvedor do DNS não estivesse executando a validação do DNSSEC, esperaríamos ver uma única consulta para um RR feito no servidor autoritário, enquanto que se o resolvedor de DNS fosse um resolvedor de validação DNSSEC, esperaríamos ver uma consulta A RR, seguida por um DNSKey e uma consulta DS.

E é isso que é visto. As consultas a seguir foram registradas pelo servidor de nome autoritário de um resolvedor de DNS não validante:

 22-mar-2013 01:46:34.209 10.0.0.1#59296: consulta: e.U3435434437.S1363916793.V6022.58CB7.z.DashnxDomain.rede em um -ed 22-mar-2013 01:46:34.311 10.0.0.1#57571: consulta: D.U3435434437.S1363916793.V6022.58CB7.z.dotnxDomain.rede em um -ed 22-mar-2013 01:46:34.245 10.0.0.1#6322E: consulta: f.U3435434437.S1363916793.V6022.58CB8.z.dotnxDomain.rede em um -ed 

As consultas a seguir foram registradas pelo servidor de nome autoritário de um conjunto de resolvedores de DNS que parecem executar a validação DNSSEC:

 22-mar-2013 01:40:48.029 10.0.0.2#17283 Consulta: D.U2867716218.S1363916447.V6022.58721.z.dotnxDomain.rede em um -ed 22-mar-2013 01:40:48.038 10.0.0.2#22572 Consulta: 58721.z.dotnxDomain.rede em ds -ed 22-mar-2013 01:40:48.056 10.0.0.2#54384 Consulta: 58721.z.dotnxDomain.rede em dnskey -ed 22-mar-2013 01:40:48.229 10.0.0.3#18024 Consulta: E.U2867716218.S1363916447.V6022.58721.z.DashnxDomain.rede em um -ed 22-mar-2013 01:40:48.024 10.0.0.4#19869 Consulta: f.U2867716218.S1363916447.V6022.58722.z.dotnxDomain.rede em um -ed 22-mar-2013 01:40:48.032 10.0.0.4#52521 Consulta: 58722.z.dotnxDomain.rede em ds -ed 22-mar-2013 01:40:48.049 10.0.0.4#35302 Consulta: 58722.z.dotnxDomain.rede em dnskey -ed 22-mar-2013 01:40:48.084 10.0.0.5#44543 Consulta: f.U2867716218.S1363916447.V6022.58722.z.dotnxDomain.rede em um -ed 22-mar-2013 01:40:48.092 10.0.0.5#46424 Consulta: 58722.z.dotnxDomain.rede em ds -ed 22-mar-2013 01:40:48.109 10.0.0.5#17802 Consulta: 58722.z.dotnxDomain.rede em dnskey -ed 22-mar-2013 01:40:48.139 10.0.0.6#24334 Consulta: f.U2867716218.S1363916447.V6022.58722.z.dotnxDomain.rede em um -ed 22-mar-2013 01:40:48.147 10.0.0.6#18014 Consulta: 58722.z.dotnxDomain.rede em ds -ed 22-mar-2013 01:40:48.164 10.0.0.6#43916 Consulta: 58722.z.dotnxDomain.rede em dnskey -ed 22-mar-2013 01:40:48.197 10.0.0.6#51221 Consulta: f.U2867716218.S1363916447.V6022.58722.z.dotnxDomain.rede em um -ed 22-mar-2013 01:40:48.230 10.0.0.7#58295 Consulta: f.U2867716218.S1363916447.V6022.58722.z.dotnxDomain.rede em um -ed 22-mar-2013 01:40:48.239 10.0.0.7#34658 Consulta: 58722.z.dotnxDomain.rede em ds -ed 22-mar-2013 01:40:48.255 10.0.0.7#31055 Consulta: 58722.z.dotnxDomain.rede em dnskey -ed 

Nesse caso, o F url, que contém uma assinatura DNSSEC inválida, aparentemente gera uma resposta de erro do servFail da consulta inicial do DNS que, por sua vez, desencadeia o processo de resolução de nome do cliente para tentar novamente a consulta DNS inteira usando um resolvedor diferente. Uma repetição da mesma falha faz com que o cliente realize uma terceira e última tentativa em outro resolvedor configurado.

Resultados da experiência

A primeira execução deste experimento teve os seguintes resultados:

 Experimentos apresentados: 2.802.390 Apresentou experimentos com busca na web: 2.632.322 apresentaram experimentos com a busca da Web de resultados: 2.142.141 

Tabela 2 – Experimente uma contagem

Isso mostra o “deixar” Avaliação no experimento. Quando o anúncio é apresentado ao usuário (um “impressão”) o usuário final’O navegador S passou um objeto flash. A execução do objeto Flash causa o navegador do usuário final para coletar os parâmetros do experimento, que consiste nos três URLs de experimento e no URL do resultado. O navegador começará a buscar os três URLs resolvendo os nomes do DNS para os URLs. A primeira medição de “Experimentos apresentados” No servidor de nome autoritário está a contagem total do número de identificadores exclusivos que geraram consultas DNS. O navegador do usuário final executará as buscas dos URLs. A diferença entre a contagem de consultas do DNS e a contagem de busca da web mostra que cerca de 6% das execuções do experimento são abortadas antes de prosseguir para a busca da web do experimento. Quando todos os três URLs forem buscados, ou 10 segundos tiveram decorrido, o navegador do usuário final executará uma consulta de resolução DNS para o URL do resultado e, em seguida, buscar o URL. Outros 19% das execuções do experimento não chegam a este resultado Fetch Fase. Para garantir que o efeito de abortar a execução do experimento seja minimizado, o resumo a seguir se refere apenas aos 2.142.141 experimentos que concluíram a busca do URL do resultado.

O experimento consiste em buscar os urls D, E e F. A tabela a seguir mostra o número de clientes que buscaram várias combinações desses URLs (e também buscaram o URL do resultado).

 d e f contagem não não não 4.325 0.20% sim não não 1.024 0.05% Não Sim Não 2.627 0.12% sim sim não 60.988 2.85% não não sim 1.045 0.05% sim não sim 6.108 0.29% não sim sim 3.291 0.15% sim sim sim 2.059.990 96.17% 

Tabela 3 – Experimente uma combinações de busca de URL

Houve um total de 60.998 experimentos que buscaram d e e, mas não f. É possível que isso seja devido ao fato de o cliente não conseguir validar as assinaturas de DNSSEC no f nome de domínio, mas também é uma possibilidade de o cliente simplesmente não buscar F devido a alguma forma de final prematuro do experimento’s execução, mesmo que o resultado do resultado tenha sido buscado. É possível usar os logs do DNS para confirmar se o cliente tentou ou não validar o nome de domínio F procurando os clientes que recuperaram o DS e o DNSKEY RRS para ambos d e f, mas apenas buscou d e e. Como mostrado na tabela abaixo, houve 58.303 execuções de experimentos, ou 2.72% do total.

Também estamos interessados ​​no número de clientes que usam vários resolvedores de DNS, onde apenas alguns dos resolvedores executam a validação DNSSEC. No caso de um resolvedor de valor validador de DNSSEC retornar o código de erro do servFail, é provável que um cliente passe a consulta a outros resolvedores. Se esses resolvedores não executarem a validação DNSSEC, o cliente receberá uma resposta para o nome de domínio F. Portanto, a próxima categoria é o número de clientes que buscaram D, E e F, e buscaram o DS e o DNSKEY RRs para D e F. Esses usuários parecem estar usando uma mistura de clientes validadores validadores de DNSSEC e não-DNSSEC. Como mostrado na tabela abaixo, houve 52.713 execuções de experimentos, ou 2.46% do total.

Das experiências restantes, extraímos as execuções de experimentos, onde apenas um RRS foi consultado, o que foi responsável por 2.026.014 execuções de experimento, ou 94,58% do total.

O que resta são cerca de 2.368 execuções de experimentos que parecem buscar alguns RRs DNSSec, mas não puderam ser classificados em nenhuma das duas categorias acima.

 DNSSSEC usado resolvedores de validação: 58.303 2.72% usaram uma mistura de resolvedores validadores e não validadores: 52.713 2.46% buscou o DNSSEC RRS parte do tempo: 2.368 0.11% não buscaram nenhum DNSSEC RRs: 2.026.014 94.58% 

Tabela 4 – Experimente os recursos de um cliente para DNSSEC

O resultado deste experimento mostra que alguns 2.72% de todos os clientes parecem usar exclusivamente os resolvedores de validação de DNSSEC e não poderão resolver um nome de DNS quando a assinatura DNSSEC for inválida. Mais 2.46% dos clientes usam uma mistura de resolvedores de DNSSEC validando e não validantes, para que não derivem nenhum tangível “proteção” A partir desta configuração mista.

O que mudou após o anúncio da validação DNSSEC dos resolvedores públicos de DNS do Google? A seguir, são os mesmos dados do experimento que foi realizado em 22 de março a 1º de abril.

 Experimentos apresentados: 2.590.330 Apresentou experimentos com busca na web: 2.421.138 apresentaram experimentos com a busca na Web: 1.930.180 

Tabela 5 – Contagem do experimento B

 d e f contagem não não não 3.471 0.18% sim não não 797 0.04% Não Sim Não 2.698 0.14% sim sim não 67.487 3.50% não não sim 832 0.04% sim não sim 4.027 0.21% não sim sim 3.352 0.17% sim sim sim 1.844.790 95.58% 

Tabela 6 – Experimente uma combinações de busca de URL

 DNSSSEC usado resolvedores de validação: 64.690 3.35% usaram uma mistura de resolvedores validadores e não validadores: 43.657 2.26% buscou o DNSSEC RRS parte do tempo: 2.652 0.11% não buscaram nenhum DNSSEC RRs: 1.816.968 94.13% 

Tabela 7 – Recursos do cliente Experimento B para DNSSEC

O resultado desta segunda execução do experimento mostra que alguns 3.35% de todos os clientes parecem usar exclusivamente os resolvedores de validação do DNSSEC e, corretamente, não poderão resolver um nome de DNS quando sua assinatura DNSSEC for inválida. Mais 2.26% dos clientes usam uma mistura de resolvedores validadores de DNSSEC e não validantes. O nível de clientes validadores de DNSSEC parece ter aumentado em pouco mais de 0.5%.

Essa mudança positiva dos níveis de clientes que realizam a validação DNSSEC atribuídos a uma mudança no comportamento dos servidores públicos do Google DNS?

Servidores Public DNS do Google

Este aumento de 0.5% no número de clientes que realizam a validação de DNSSEC da Experiência A à Experiência B podem ser atribuídos ao Google ativando a validação do DNSSC em seus servidores públicos DNS no momento do anúncio, ou pode estar dentro dos limites de erro experimental, ou pode ser o resultado de algum outro conjunto de resolvedores que se aproximam da validação. Isto’É uma pergunta razoável para perguntar se os conjuntos de dados de consultas DNS dos servidores de nome DNS do Google antes e depois do anúncio do Google mostram qualquer diferença na extensão em que eles executam a validação do DNSSEC.

O DNS público do Google é um encaminhador de DNS; portanto, ao analisar o perfil das consultas DNS que são geradas pelo Google Resolvers, pode ser útil analisar o conjunto de transformações entre consultas enviadas ao Google e consultas que os resolvedores do Google DNS farão com os servidores autorizados. (assumindo um conjunto de nomes de domínio exclusivos que ainda não estão carregados no cache DNS local do Google).

 Consulta original Consulta correspondente do Google | Validação não validadora | | | A A A A(cd) A A A(do) A(do) A(do), DS(do), DNSKEY(do) A(do, cd) A(do) A(do) DS(cd) DS(do) DS(do) DNSKEY(do, cd) DNSKEY(do) DNSKEY(do) In this table "cd" is the Checking Disabled flag set, and "do" is the EDNS0 option present and the DNSSEC OK flag set 

Tabela 8 – O DNS Query se transforma conforme realizado pelo Public DNS Forwarders do Google

Os resolvedores públicos de DNS do Google não definem o sinalizador do CD em nenhuma das consultas que eles fazem para servidores de nome autorizados (ao contrário dos conselhos explícitos na Seção 5.9 de RFC6840, mas como o servidor é um servidor de nome autoritário, o conselho nesta RFC nesse caso em particular é de valor duvidoso! Os resolvedores DNS do Google não parecem alterar qualquer comportamento de resolução do DNS em não definir o sinalizador do CD ao fazer consultas para servidores de nome autorizados).

Aside from this change to the query profile, the only other change we would expect to see from the perspective of the queries received at an authoritative name server between a Google resolver that did not perform DNSSEC validation and one that did perform validation is that the proportion of queries for an A RR with the DNSSEC OK flag set should be slightly lower, while the proportion of queries for the sequence of A, DS and DNSKEY RRs, all with the DNSSEC Ok flag should rise. O raciocínio é que, se o Google receber uma consulta com o conjunto de bandeiras do DO e o sinalizador de CD limpo, ele próprio executará a validação DNSSEC no resultado, e ao fazê -lo gerará as consultas A, DS e DNSKEY. Se o Google receber uma consulta com o conjunto de sinalizadores DO e CD, ele enviará a consulta ao servidor de nome autoritário com apenas o conjunto de bandeiras, mas não executará nenhuma validação do DNSSEC por si só, pois a bandeira do CD o direcionou para não fazer isso.

Então, aqui estão os resultados das duas execuções deste experimento de medição. Experiência A é o período de 8 a 18 de fevereiro de 2013 e a Experiência B é o período de 22 de março a 1º de abril de 2013.

 Experiência a Experiência B Número total de consultas: 309.043 328.059 . Single a Consulta: 256.708 83.07% 289.428 88.22% Single a Query with Do Set: 23.134 7.48% 20.119 6.13% múltiplo A consultas: 11.700 3.79% 7.916 2.41% múltiplo A consultas, tudo com o conjunto de doenidade: 1.179 0.38% 578 0.18% múltiplas consultas, algumas com o conjunto do DO: 1.194 0.39% 877 0.27% Single DNSSEC-Validate Consulta Sequência: 5.904 1.91% 3.196 0.97% Outras seqüências de consulta: 7.482 2.42% 4.706 1.43% 

Tabela 9 – Google’s Profile de consulta DNS DNS Public DNS: Total

Este resultado não é muito esclarecedor. A proporção de uma única sequência de consulta de validação de DNSSEC (uma consulta A seguida de consultas DS e DNSKEY em qualquer ordem) caiu na Experiência B. Isso leva à conclusão provisória de que, dentro dos limites da variação de dados neste experimento, parece que os servidores públicos DNS do Google estão realizando a validação do DNSSEC há algum tempo, e a validação do DNSSEC não foi simplesmente ligada no momento do anúncio do Google no 19º de março de 2013 de 2013.

Existe outra maneira potencial de detectar o resolvedor de DNS do Google executando a validação DNSSEC. If you query for an A RR from Google’s public DNS servers with the DNSSEC OK bit set, and the domain name is DNSSEC signed, and the DNSSEC signature is valid, then while the first query will cause the DNS resolvers to query the authoritative name servers, subsequent queries for the same name will be answered from the DNS resolvers’ cache, and will not cause any queries to be sent to the authoritative name servers. Por outro lado, se a assinatura do DNSSEC do nome de domínio não for válida, as consultas subsequentes para o mesmo nome de domínio (com o conjunto de bits DNSSEC OK) farão com que os resolvedores do DNS reinicie os servidores de nome autoritários. Este experimento possui assinaturas DNSSEC-Valid e DNSSEC-Intervalid com os nomes de domínio D e F. São as diferenças visíveis nos padrões de consulta dos resolvedores públicos de DNS do Google?

 Experiência da categoria Um experimento B válido (%) inválido (%) válido (%) inválido (%) número total de consultas: 153.540 154.907 164.043 165.623 Single a consulta: 127.366 82.95% 128.134 82.72% 144.561 88.12% 145.725 87.99% Single a Query with DO Set: 5.465 3.56% 5.386 3.48% 6.308 3.85% 6.259 3.78% Múltiplo A Consultas: 5.557 3.62% 5.789 3.74% 3.780 2.30% 4.038 2.44% Múltiplo A consultas, tudo com o conjunto do DO: 245 0.16% 248 0.16% 226 0.14% 236 0.14% múltiplas consultas A, algumas com o conjunto de DO: 202 0.13% 222 0.14% 231 0.14% 224 0.14% Single DNSSEC-Validate Consulta Sequência: 10.818 7.05% 5.904 3.81% 6.434 3.92% 3.196 1.93% DNSSEC Validar mais consultas adicionais: 1.864 1.21% 7.482 4.83% 1.124 0.69% 4.706 2.84% outros 2.023 1.32% 1.742 1.12% 1.379 0.84% 1.239 0.74% 

Tabela 10 – Google’S Profile de consulta DNS DNS Public DNS: Totais válidos e inválidos

Esta tabela não mostra nenhuma mudança apreciável no volume de consulta entre os nomes de DNS válidos e inválidos. Ele provavelmente se deve à natureza deste experimento, onde o uso de rótulos exclusivos de DNS em cada experimento foi deliberadamente projetado para contornar o cache.

Há, no entanto, um caso em que há alguma evidência de perguntas de DNS repetidas. A queda na proporção relativa de seqüências de consulta de validação de DNSSEC único entre os nomes de domínio válidos e inválidos é ilustrativo de uma forma de comportamento do cliente em que uma resposta de erro do servFail da consulta DNS inicial faz com que o cliente tente novamente a mesma consulta no próximo resolvedor em sua lista local de nome do DNS Resolvers. A parte talvez irônica desse comportamento em particular é que o que estamos vendo aqui nesta tabela é o resultado daqueles casos em que vários resolvedores de DNS na lista de resolvedores disponíveis acabam encaminhando essas consultas supostamente distintas para o ponto comum dos servidores públicos do Google.

Portanto, podemos dizer com alguma certeza que o Google não ligou a validação do DNSSEC no momento de seu anúncio público em 19 de março de 2013, e o Google estava realizando a validação do DNSSEC há algum tempo antes do anúncio. Parece que o 0.A alteração de 5% no nível de uso final do cliente da validação DNSSEC é mais provável que o resultado da variabilidade no experimento.

Os resultados – uso do DNSSEC pelos usuários finais

Este experimento mostra que no início de 2013 alguns 3% de todos os clientes parecem usar exclusivamente os resolvedores validadores de DNSSEC e, apropriadamente, não poderão resolver um nome de DNS quando sua assinatura DNSSEC for inválida. Um mais 2% de clientes usam uma mistura de resolvedores de valor validante e não validante de DNSSEC.

Confirmado – Google’S DNS público agora executa a validação DNSSEC para todas as consultas por padrão

Isto’S OFICIAL… Google’S O Serviço Público DNS agora está executando a validação DNSSEC para todos Consultas DNS por padrão!

Quando as notícias voltaram em 19 de março de que o Google havia permitido a validação do DNSSEC em seu serviço público DNS, houve alguma preocupação inicial depois que as pessoas perceberam que o Google estava apenas realizando a validação do DNSSEC quando solicitado. Isso levou a um esclarecimento alguns dias depois do Google de que o lançamento inicial exigia que um cliente solicitasse a validação do DNSSEC para que eles pudessem testar o serviço – e que a validação completa estava chegando em breve.

A palavra oficial

Ontem, Google’S Warren Kumari postou na lista de discussão DNSSEC-Deployment que a validação completa está acontecendo agora:

Recentemente, ativamos a validação por padrão globalmente, e agora você deve obter o ServFail para falhas de validação. Desculpas novamente pelo anúncio original e pouco claro.

O blog / documentação ainda não foi atualizado (isso provavelmente acontecerá nos próximos dias), mas queríamos lhe dar boas notícias o mais rápido possível.

E, de fato, um teste rápido para ver se eu poderia obter os registros DNS para um domínio de teste conhecido por ter uma assinatura DNSSEC ruim produziu o esperado “ServFail” mensagem e corretamente fez não Retorne todos os registros do DNS:

$ dig @8.8.8.8 www.DNSSEC falhou.org; > Dig 9.8.3-p1> @8.8.8.8 www.DNSSEC falhou.org; (1 servidor encontrado) ;; Opções globais: +CMD ;; Recebi resposta: ;; ->> headerservfail, ID: 60286 ;; Bandeiras: Qr Rd Ra; Consulta: 1, Resposta: 0, Autoridade: 0, Adicional: 0 ;; Seção de perguntas :; www.DNSSEC falhou.org. EM UM

Esta é uma ótima notícia para aqueles de nós que são defensores do DNSSEC e significa que qualquer pessoa que use o Google’Os servidores públicos DNS para resolução de nomes DNS agora estão recebendo automaticamente a maior segurança do DNSSEC. Qualquer pessoa que use esses servidores saberá que (para domínios assinados) as informações que estão saindo do DNS são a mesma informação que o operador de domínio colocou em DNS – e não o de um invasor que procura que você vá para outro site.

Se você também deseja obter acesso ao aumento da segurança do DNSSEC, tudo o que você precisa fazer é configurar seu computador ou roteador doméstico como servidores DNS os servidores DNS do Google Public:

Movendo a validação DNSSEC ainda mais perto

Tão impressionante quanto esse movimento do Google é (e é é incrível), você ainda pode aumentar a segurança fornecida pelo DNSSEC um pouco mais. Porque o Google’Os servidores públicos DNS não estão na sua rede local e estão em algum lugar na Internet, existe ainda uma chance de um atacante se inserir entre você e o google’S servidores DNS. O atacante poderia então fingir estar enviando de volta as informações corretas e disfarçando como Google’s Servidores Public DNS.

Para obter o nível mais alto de segurança DNSSEC, você idealmente deseja executar a validação DNSSEC em pelo menos sua rede local e potencialmente até o computador local. Lá’é um grande whitepaper do pessoal da Surfnet chamado “Implantando DNSSEC: Validação em servidores de nomes de cache recursivo” Isso explica como você pode simplesmente ativar a validação DNSSEC para três dos servidores DNS comuns usados ​​por empresas e redes hoje.

Ei, se o Google pode ativar a validação do DNSSEC, por que pode’Tu?

Se você puder’T DO DNSSEC Validação localmente (por exemplo, se você tiver apenas um roteador de wifi em casa que não’t executar validação), então, com a realização da validação no seu ISP, pode ser o próximo passo … e se o seu ISP vencer’T OM’s Serviços Públicos DNS. Sua validação DNSSEC é definitivamente uma proteção muito melhor do que nenhum!

Novamente, parabéns ao google’A equipe pública de DNS por dar esta etapa e estamos ansiosos pelo dia em que todos Os resolvedores do DNS apenas executam a validação DNSSEC automaticamente.

Isenção de responsabilidade: os pontos de vista expressos neste post são os do autor e podem ou não refletir posições oficiais da sociedade da Internet.

Google usa DNSSEC

O Google publica qualquer estatística ao vivo sobre o estado de sua rede DNS?

Estou muito feliz por você estar a todo vapor no DNSSEC e em outras práticas recomendadas de segurança de segurança do DNS e deseja defender o Google DNS para outras pessoas, mas, infelizmente, você não está realmente compatível com as especificações do DNSEC no momento pela simples razão. Isso está simplesmente errado; Você deve devolver o ServFail para qualquer falha de validação, a qualquer cliente.

É realmente uma informação ótima e útil.
Estou satisfeito por você simplesmente compartilhar esta informação útil conosco.
Por favor mantenha-nos informados sobre isso. Obrigado por compartilhar informações.

Existe alguém no Google designado para fazer o trabalho para obter o Google.com domínio com assinado DSNSEC? Temos um problema de frango e ovo, onde os usuários finais não terão tempo para se envolver com o DNSSEC se os sites que eles acessarem frequentemente não forem assinados. Se alguém estiver trabalhando nisso, qual é a data/trimestre de implantação alvo?

Google: onde’é o seu dnssec?

O Google investiu pesadamente em segurança de TI e, acho que fez um trabalho decente. Todos os serviços são TLs por padrão, identidade e autorização são bem tratados.

Então, fiquei um pouco surpreso com isso para ver que o Google’s .com (e .CA) não são uma configuração DNSSEC. Eu me pergunto por que, deve haver uma razão.

O DNSSEC ajuda a evitar a falsificação de domínio, que por sua vez pode ser usada para trapacear e obter certificações TLS. EU’tenho certeza que essa foi uma decisão consciente. Seus 8.8.8.8 servidor faz validação DNSSEC. É uma opção em seus domínios gerenciados do Google. O DNS em nuvem suporta. Só não a entrada de seu domínio corporativo.