i18n/dns-overview.md at 1ae35f41e64cc1fa43cb76b01db7bf0a342d5345

privacyguides/i18n

Fork 0

mirror of https://github.com/privacyguides/i18n.git synced 2025-08-23 15:09:14 +00:00

Files

Crowdin Bot 1ae35f41e6 New Crowdin translations by GitHub Action

2024-04-02 11:33:03 +00:00

25 KiB

Raw Blame History

title, icon, description

title	icon	description
Visão geral do DNS	material/dns	O sistema de nomes de domínio, DNS, é a "lista telefónica da Internet", e ajuda o seu browser a encontrar o site que procura.

O sistema de nomes de domínio é a "lista telefónica da Internet". O DNS traduz os nomes de domínio em endereços IP, para que os navegadores e outros serviços possam carregar os recursos da Internet, através de uma rede descentralizada de servidores.

O que é o DNS?

Quando se visita um site, é devolvido um endereço numérico. Por exemplo, quando se visita o privacyguides.org, é devolvido o endereço 192.98.54.105.

O DNS existe desde os primeiros dias da Internet. Os pedidos de DNS realizado, de e para servidores DNS, não são geralmente encriptados. Numa configuração caseira, o utilizador usa os servidores de DNS do ISP, através de DHCP.

Os pedidos de DNS não encriptados podem ser facilmente vigiados e modificados em trânsito. Em algumas partes do mundo, os ISP são obrigados a efetuar uma filtragem de DNS. Quando solicita o endereço IP de um domínio que está bloqueado, o servidor pode não responder ou pode responder com um endereço IP diferente. Como o protocolo DNS não é encriptado, o ISP (ou qualquer operador de rede) pode utilizar o DPI para monitorizar os pedidos. Os ISPs também podem bloquear pedidos com base em características comuns, independentemente do servidor DNS utilizado. O DNS não encriptado utiliza sempre a porta 53 e o protocolo UDP.

Abaixo, discutimos e fornecemos um tutorial que prova o que um observador externo pode ver, quando se utiliza DNS normal não encriptado e DNS encriptado.

DNS não encriptado

Using tshark (part of the Wireshark project) we can monitor and record internet packet flow. Este é um comando que regista os pacotes que cumprem determinadas regras:
```
tshark -w /tmp/dns.pcap udp porto 53 e host 1.1.1.1 ou host 8.8.8.8
```
Podemos depois utilizar o dig (Linux, MacOS, etc.) ou o nslookup (Windows) para enviar a pesquisa de DNS para ambos os servidores. Software como, por exemplo, os browsers fazem estas pesquisas automaticamente, a menos que estejam configurados para utilizar DNS encriptado.

=== "Linux, macOS"
```
 ```
 dig noall answer privacyguides.org @1.1.1.1.1
 dig noall answer privacyguides.org @8.8.8.8
 ```
```
=== "Windows"
```
 ```
 nslookup privacyguides.org 1.1.1.1
 nslookup privacyguides.org 8.8.8.8
 ```
```

Next, we want to analyse the results:

==== "Wireshark"

 ```
 wireshark -r /tmp/dns.pcap
 ```

=== "tshark"

 ```
 tshark -r /tmp/dns.pcap
 ```

Se executar o comando Wireshark indicado acima, o painel superior mostra os "frames", e o painel inferior mostra todos os dados sobre o frame selecionado. As soluções empresariais de filtragem e monitorização (como as adquiridas pelos governos) podem fazer o processo automaticamente, sem interação humana, e podem agregar essas imagens para produzir dados estatísticos úteis para o observador da rede.

No.	Time	Source	Destination	Protocol	Length	Info
1	0.000000	192.0.2.1	1.1.1.1	DNS	104	Standard query 0x58ba A privacyguides.org OPT
2	0.293395	1.1.1.1	192.0.2.1	DNS	108	Standard query response 0x58ba A privacyguides.org A 198.98.54.105 OPT
3	1.682109	192.0.2.1	8.8.8.8	DNS	104	Standard query 0xf1a9 A privacyguides.org OPT
4	2.154698	8.8.8.8	192.0.2.1	DNS	108	Standard query response 0xf1a9 A privacyguides.org A 198.98.54.105 OPT

Um observador pode modificar qualquer um destes pacotes.

O que é o "DNS encriptado"?

O DNS encriptado pode referir-se a um de vários protocolos, sendo os mais comuns:

DNSCrypt

O DNSCrypt foi um dos primeiros métodos de encriptação de pedidos DNS. O DNSCrypt funciona na porta 443 e utiliza os protocolos de transporte TCP ou UDP. O DNSCrypt nunca foi submetido à Internet Engineering Task Force (IETF), nem passou pelo processo Request for Comments (RFC), pelo que não foi amplamente utilizado, exceto em algumas implementações . Por esse motivo, foi amplamente substituído pelo mais popular DNS sobre HTTPS.

DNS sobre TLS (DoT)

O DNS sobre TLS é outro método para encriptar a comunicação DNS, definido em RFC 7858. Support was first implemented in Android 9, iOS 14, and on Linux in systemd-resolved in version 237. Preference in the industry has been moving away from DoT to DoH in recent years, as DoT is a complex protocol and has varying compliance to the RFC across the implementations that exist. O DoT também funciona numa porta dedicada, a 853, que pode ser facilmente bloqueada por firewalls restritivas.

DNS sobre HTTPS (DoH)

O DNS sobre HTTPS, tal como definido em RFC 8484, agrupa as consultas através do protocolo HTTP/2 e proporciona segurança com HTTPS. O suporte foi adicionado pela primeira vez em browsers como o Firefox 60 e o Chrome 83.

A implementação nativa do DoH apareceu no iOS 14, macOS 11, Microsoft Windows e Android 13 (no entanto, não será ativado por predefinição). O suporte geral do ambiente de trabalho Linux está à espera da implementação do systemd, pelo que ainda é necessário instalar software de terceiros.

Native Operating System Support

Android

As últimas versões do iOS, iPadOS, tvOS e macOS, suportam tanto DoT como DoH. Ambos os protocolos são suportados nativamente através de perfis de configuração ou através de DNS Settings API.

Apple Devices

Após a instalação de um perfil de configuração ou de um aplicativo que utiliza a API de configurações DNS, a configuração DNS pode ser selecionada. Se uma VPN estiver activa, a resolução dentro do túnel VPN utilizará as definições DNS da VPN e não as definições de todo o seu sistema.

A Apple não fornece uma interface nativa para a criação de perfis DNS criptografados. Criador de perfil DNS seguro é uma ferramenta não oficial para criar os seus próprios perfis DNS encriptados, no entanto eles não serão assinados.

Apple does not provide a native interface for creating encrypted DNS profiles. Informações Signed profiles are preferred; signing validates a profile's origin and helps to ensure the integrity of the profiles. A green "Verified" label is given to signed configuration profiles. For more information on code signing, see About Code Signing.

Linux

systemd-resolved, which many Linux distributions use to do their DNS lookups, doesn't yet support DoH. If you want to use DoH, you'll need to install a proxy like dnscrypt-proxy and configure it to take all the DNS queries from your system resolver and forward them over HTTPS.

O que é que uma pessoa de fora pode ver?

Neste exemplo, vamos registar o que acontece quando fazemos um pedido ao DoH:

Primeiro, inicie o tshark:

tshark -w /tmp/dns_doh.pcap -f "tcp port https e host 1.1.1.1"

Em segundo lugar, faça um pedido com curl:

curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org

Depois de fazer o pedido, podemos parar a captura de pacotes com CTRL + C.
Analise os resultados no Wireshark:
```
wireshark -r /tmp/dns_doh.pcap
```

We can see the connection establishment and TLS handshake that occurs with any encrypted connection. Ao olhar para os pacotes de "dados da aplicação" que se seguem, verificamos que nenhum deles contém o domínio que pedimos ou o endereço IP devolvido.

Por que razão não devo utilizar DNS encriptado?

Em locais onde existe filtragem (ou censura) da Internet, visitar recursos proibidos pode ter as suas próprias consequências, que devem ser consideradas no modelo de ameaças. Não sugerimos a utilização de DNS encriptado para este fim. Em vez disso, utilize o Tor ou uma VPN. Se estiver a utilizar uma VPN, deve utilizar os servidores DNS da sua VPN. Ao utilizar uma VPN, está a confiar-lhes toda a sua atividade de rede.

Quando fazemos uma pesquisa DNS, geralmente é porque queremos aceder a um recurso. Abaixo, falaremos de alguns dos métodos que podem revelar as suas atividades de navegação, mesmo quando utiliza DNS encriptado:

Endereço IP

A forma mais simples de determinar a sua atividade de navegação é verificar os endereços IP a que os seus dispositivos acedem. Por exemplo, se o observador sabe que privacyguides.org está em 198.98.54.105, e o seu dispositivo está a pedir dados a 198.98.54.105, há uma boa hipótese de estar a visitar o Privacy Guides.

Este método só é útil quando o endereço IP pertence a um servidor que aloja um número reduzido de sites. Também não é muito útil se o site estiver alojado numa plataforma partilhada (por exemplo, Github Pages, Cloudflare Pages, Netlify, WordPress, Blogger, etc.). Também não é muito útil se o servidor estiver hospedado atrás de um proxy reverso, o que é muito comum na Internet moderna.

Indicação do nome do servidor (SNI)

A indicação do nome do servidor é normalmente utilizada quando um endereço IP aloja uma grande quantidade de sites. Pode ser um serviço como o Cloudflare ou alguma outra proteção contra ataques de negação de serviço (DoS).

Comece a capturar novamente com o tshark. Adicionámos um filtro com o nosso endereço IP para que não capture muitos pacotes:
```
tshark -w /tmp/pg.pcap porto 443 e host 198.98.54.105
```
Em seguida, visitamos https://privacyguides.org.
Depois de visitar o site, paramos a captura de pacotes com CTRL + C.
Em seguida, analisamos os resultados:
```
wireshark -r /tmp/pg.pcap
```
Veremos o estabelecimento da ligação, seguida do TLS handshake para o site Privacy Guides. Algures na proximidade da frame 5. verá um "Client Hello".

Expanda o triângulo ▸ junto a cada campo:

▸ Transport Layer Security
  ▸ TLSv1.3 Record Layer: Protocolo de Aperto de Mãos: Cliente Olá
    ▸ Protocolo de Aperto de Mãos: Cliente Olá
      ▸ Extensão: Server_name (len=22)
        ▸ Server Name Indication extension

Podemos ver o valor SNI que revela o site que estamos a visitar. O comando tshark pode fornecer-lhe o valor diretamente para todos os pacotes que contêm um valor SNI:
```
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
```

Isto significa que mesmo que estejamos a utilizar servidores "DNS Encriptados", o domínio será provavelmente divulgado através do SNI. The TLS v1.3 protocol brings with it Encrypted Client Hello, which prevents this kind of leak.

Governments, in particular China and Russia, have either already started blocking it or expressed a desire to do so. Recentemente, a Rússia começou a bloquear sites estrangeiros que utilizam a norma HTTP/3. Isto deve-se ao facto do protocolo QUIC, que faz parte do HTTP/3, exigir que o ClientHello também seja encriptado.

Protocolo de estado dos certificados em linha (OCSP)

Outra forma de o seu browser revelar as suas atividades de navegação é através do protocolo de estado dos certificados online. Ao visitar um site HTTPS, o browser pode verificar se o certificado do site foi revogado. Isto é geralmente feito através do protocolo HTTP, o que significa que não é encriptado.

O pedido OCSP contém o "número de série" do certificado, que é único. É enviado para o "OCSP responder" para verificar o seu estado.

Podemos simular o que um browser faz ao usar o comando openssl.

Obtenha o certificado do servidor e utilize sed para ficar apenas com a parte importante e escrevê-la num ficheiro:

openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
    sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert

Obtenha o certificado intermédio. As Autoridades de Certificação (CA) normalmente não assinam um certificado diretamente; utilizam o que se conhece por certificado "intermédio".
```
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
    sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
O primeiro certificado em pg_and_intermediate.cert é, de facto, o certificado do servidor do passo 1. Podemos usarsed novamente para eliminar até à primeira instância de END:
```
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
    /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
Obtenha o OCSP responder para o certificado do servidor:
```
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
```
O nosso certificado mostra o Lets Encrypt certificate responder. Se quisermos ver todos os pormenores do certificado, podemos usar:
```
openssl x509 -text -noout -in /tmp/pg_server.cert
```

Inicie a captura de pacotes:

tshark -w /tmp/pg_ocsp.pcap -f "tcp port http

Faça o pedido OCSP:

openssl ocsp -issuer /tmp/intermediate_chain.cert \
             -cert /tmp/pg_server.cert \
             -text \
             -url http://r3.o.lencr.org

Abra a captura:

wireshark -r /tmp/pg_ocsp.pcap

Haverá dois pacotes com o protocolo "OCSP": um "Pedido" e uma "Resposta". Para o "Pedido", podemos ver o "número de série" expandindo o triângulo ▸ ao lado de cada campo:

▸ Online Certificate Status Protocol
  ▸ tbsRequest
    ▸ requestList: 1 item
      ▸ request
        ▸ reqCert
          serialNumber

Para a "Resposta", também podemos ver o "número de série":

▸ Online Certificate Status Protocol
  ▸ responseBytes
    ▸ BasicOCSPResponse
      ▸ tbsResponseData
        ▸ responses: 1 item
          ▸ Respostas Simples
            ▸ certID
              serialNumber

Ou utilizar o tshark para filtrar os pacotes pelo número de série:

tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber

Se o observador da rede tiver o certificado público, que está disponível publicamente, pode fazer corresponder o número de série a esse certificado e, assim, determinar o site que está a visitar. O processo pode ser automatizado e pode associar endereços IP a números de série. Também é possível consultar os logs de Certificate Transparency para obter o número de série.

Devo utilizar DNS encriptado?

Criámos este fluxograma para descrever quando é que deve utilizar DNS encriptado:

graph TB
    Iniciar[Start] --> anonimato{Pretende <br> anonimato?}
    anonimato--> | Sim | tor(Use o Tor)
    anonimato --> | Não | censura{Evitar<br> censura?}
    censura --> | Sim | vpnOrTor(Use<br> uma VPN ou o Tor)
    censura --> | Não | privacidade{Quer privacidade em relação<br> ao ISP?}
    privacidade --> | Sim | vpnOrTor
    privacidade --> | Não | obnoxious{O ISP faz<br>redirecionamentos<br> desagradáveis?}
    obnoxious --> | Sim | encryptedDNS(Use<br> DNS encriptado<br> com fornecedor terceiro)
    obnoxious --> | Não | ispDNS{O ISP suporta<br> DNS encriptado?}
    ispDNS --> | Sim | useISP(Use<br> DNS encriptado<br> com ISP)
    ispDNS --> | Não | nothing(Não faça nada)

O DNS encriptado com terceiros só deve ser utilizado para contornar redirecionamentos e o bloqueio básico do DNS quando tiver a certeza de que não haverá quaisquer consequências ou quando estiver interessado num fornecedor que efetue uma filtragem rudimentar.

Lista de servidores DNS recomendados{.md-button}

O que é o DNSSEC?

Domain Name System Security Extensions (DNSSEC) é uma funcionalidade do DNS que autentica as respostas às pesquisas de nomes de domínio. Não fornece proteções de privacidade para essas pesquisas, mas impede que os atacantes manipulem ou envenenem as respostas aos pedidos de DNS.

Por outras palavras, o DNSSEC assina digitalmente os dados para ajudar a garantir a sua validade. Para garantir uma pesquisa segura, a assinatura ocorre em todos os níveis do processo de pesquisa do DNS. Como resultado, todas as respostas do DNS são fiáveis.

O processo de assinatura DNSSEC é semelhante ao de alguém que assina um documento legal com uma caneta; essa pessoa assina com uma assinatura única que mais ninguém pode criar, e um perito judicial pode olhar para essa assinatura e verificar que o documento foi assinado por essa pessoa. Estas assinaturas digitais garantem que os dados não foram adulterados.

O DNSSEC implementa uma política de assinatura digital hierárquica em todos os níveis do DNS. Por exemplo, no caso de uma pesquisa em privacyguides.org, um servidor DNS de raiz assinaria uma chave para o DNS de .org, e o DNS de .org assinaria então uma chave para o DNS autoritário privacyguides.org.

Adapted from DNS Security Extensions (DNSSEC) overview by Google and DNSSEC: An Introduction by Cloudflare, both licensed under CC BY 4.0.

O que é a minimização de QNAME?

A QNAME is a "qualified name", for example discuss.privacyguides.net. In the past, when resolving a domain name your DNS resolver would ask every server in the chain to provide any information it has about your full query. In this example below, your request to find the IP address for discuss.privacyguides.net gets asked of every DNS server provider:

Server	Question Asked	Response
Root server	What's the IP of discuss.privacyguides.net?	I don't know, ask .net's server...
.net's server	What's the IP of discuss.privacyguides.net?	I don't know, ask Privacy Guides' server...
Privacy Guides' server	What's the IP of discuss.privacyguides.net?	5.161.195.190!

With "QNAME minimization," your DNS resolver now only asks for just enough information to find the next server in the chain. In this example, the root server is only asked for enough information to find the appropriate nameserver for the .net TLD, and so on, without ever knowing the full domain you're trying to visit:

Server	Question Asked	Response
Root server	What's the nameserver for .net?	Provides .net's server
.net's server	What's the nameserver for privacyguides.net?	Provides Privacy Guides' server
Privacy Guides' server	What's the nameserver for discuss.privacyguides.net?	This server!
Privacy Guides' server	What's the IP of discuss.privacyguides.net?	5.161.195.190

While this process can be slightly more inefficient, in this example neither the central root nameservers nor the TLD's nameservers ever receive information about your full query, thus reducing the amount of information being transmitted about your browsing habits. Uma descrição técnica mais pormenorizada é definida em RFC 7816.

O que é a Sub-rede de Cliente EDNS (ECS)?

A sub-rede de cliente EDNS é um método para um resolver DNS recursivo especificar uma sub-rede para o anfitrião ou cliente que está a efetuar a consulta DNS.

Destina-se a "acelerar" a entrega de dados, dando ao cliente uma resposta que pertence a um servidor que está perto dele, como uma rede de entrega de conteúdos , que são frequentemente utilizados em streaming de vídeo e no fornecimento de aplicações Web JavaScript.

This feature does come at a privacy cost, as it tells the DNS server some information about the client's location, generally your IP network. For example, if your IP address is 198.51.100.32 the DNS provider might share 198.51.100.0/24 with the authoritative server. Some DNS providers anonymize this data by providing another IP address which is approximately near your location.

If you have dig installed you can test whether your DNS provider gives EDNS information out to DNS nameservers with the following command:

dig +nocmd -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats

Note that this command will contact Google for the test, and return your IP as well as EDNS client subnet information. If you want to test another DNS resolver you can specify their IP, to test 9.9.9.11 for example:

dig +nocmd @9.9.9.11 -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats

If the results include a second edns0-client-subnet TXT record (like shown below), then your DNS server is passing along EDNS information. The IP or network shown after is the precise information which was shared with Google by your DNS provider.

o-o.myaddr.l.google.com. 60 IN TXT "198.51.100.32"
o-o.myaddr.l.google.com. 60 IN TXT "edns0-client-subnet 198.51.100.0/24"
;; Query time: 64 msec
;; SERVER: 9.9.9.11#53(9.9.9.11)
;; WHEN: Wed Mar 13 10:23:08 CDT 2024
;; MSG SIZE  rcvd: 130

25 KiB Raw Blame History