Como funciona o DNS quando se trata de endereços após a barra?

Quando se trata de lidar com solicitações http(s), tudo o que o DNS faz é converter o nome de domínio em um endereço IP. O navegador da web se conecta a esse endereço IP e solicita o recurso (por exemplo, parte após a barra) - sem DNS envolvido.

Sua alegação de que twitter.com está em 192.168.1.1, mas twitter.com/mypage está em 192.168.2.1 está errada. No PDV dos clientes da Web, twitter.com e twitter.com/mypage existem no mesmo endereço IP. É possível que o servidor do twitter.com atue como um proxy reverso e busque os dados finais de 192.168.2.1, mas ele encaminhará a solicitação através da conexão segura estabelecida entre o navegador e 192.168.1.1.

DNS e SNI são pouco relacionados. O SNI é negociado pelo servidor web e não se importa com o DNS (ignorando por enquanto os registros CAA e similares, que estão relacionados, mas não SNI e não são onipresentes). Na verdade, pegue um site, mova-o para outro endereço IP em outro servidor - mas certifique-se de portar os certificados também, modifique seu arquivo hosts para apontar para o novo endereço IP e seu site HTTPS funcionará mesmo quando você substituir o DNS.

Para adicionar às outras respostas: aqui está uma rápida dissecção de um URL:

https://www.example.com:99/some/path?a=b&c=d#1223

• https://- o protocolo também conhecido como "idioma" que o navegador usará para falar com o servidor web.
• www.example.com:99- o endereço, que é dividido em duas partes:
  • www.example.com- o nome do host, também conhecido como "nome de domínio". O navegador irá convertê-lo em um endereço IP antes de conectar
  • :99- o número da porta TCP que o navegador usará para estabelecer a conexão de rede. Esta parte é frequentemente omitida e, em seguida, o navegador usa o número da porta padrão para o protocolo selecionado ( 80for http; 443for https)
• /some/pathe ?a=b&c=d- o "caminho para o recurso" e a "sequência de consulta". O navegador envia tudo isso junto ao servidor, depois de estabelecer uma conexão (no caso de HTTPS que inclui todas as negociações TLS, então isso é enviado criptografado). O navegador não modifica este texto além de certificar-se de que não contém caracteres ilegais. Pode realmente ser qualquer coisa e é apenas uma convenção que a primeira parte seja um caminho para um "recurso" e a segunda parte seja algum tipo de parâmetro. Na realidade, você pode enviar quase qualquer coisa e o servidor é livre para fazer o que quiser.
• #1223- isso é chamado de "fragmento" e o navegador NÃO envia isso para o servidor. Isso é 100% para uso do lado do cliente. Por exemplo, se o URL resultar em uma página HTML, o navegador tentará encontrar um elemento HTML com esse ID e rolar até ele. Ele também pode ser acessado via Javascript que roda no navegador (que pode fazer o que quiser com ele). Mas nunca será enviado a lugar algum.

Então, como você pode ver, é de fato apenas a parte do domínio que é pesquisada no sistema DNS. E você não pode usar endereços IP diferentes dependendo do caminho.

e se o endereço após a barra tiver um endereço IP diferente?

Ele literalmente nunca tem um endereço IP diferente. A sintaxe de URL HTTP não torna isso possível; ele define que apenas a parte até a barra é a "autoridade" (o nome de domínio do servidor ou endereço IP ao qual se conectar) – o mesmo servidor é sempre responsável por todos os caminhos HTTP sob seu domínio.

(O servidor real pode lidar com solicitações HTTP para caminhos diferentes da maneira que quiser, por exemplo, pode servir alguns caminhos localmente enquanto faz proxy de outros para um host de back-end diferente, mas isso é toda a lógica do lado do servidor que é invisível para os clientes.)

Há muitas boas respostas aqui, mas são desafios de quadro ou explicações dos componentes de uma URL. Eu recomendo ler aqueles antes do meu, já que o meu se destina a expandi-los.

Vou responder aceitando a premissa da pergunta ("como isso pode acontecer?"), mas esclarecer o que realmente significa quando acontece.

Não é estritamente verdade que "tudo o que o DNS faz é converter o nome de domínio em um endereço IP". É possível que o DNS converta um nome de domínio em vários endereços IP. No entanto, todos esses endereços IP devem ser equivalentes entre si, e a seleção de qual deles usar (em todos os casos práticos) não tem nada a ver com os outros componentes de uma URL.

Aqui está uma seção de resposta de exemplo dig microsoft.comque eu corri agora:

microsoft.com.      2838    IN  A   20.84.181.62
microsoft.com.      2838    IN  A   20.81.111.85
microsoft.com.      2838    IN  A   20.53.203.50
microsoft.com.      2838    IN  A   20.112.52.29
microsoft.com.      2838    IN  A   20.103.85.33

As partes do meio não são importantes, mas para completar, elas são o TTL ( 2838), a família de endereços ( IN) e o tipo de registro ( A).

Quando você solicitar ao seu navegador ou outra ferramenta para recuperá https://microsoft.com/example-lo, primeiro fará uma pesquisa de DNS microsoft.come, em seguida, selecionará um dos endereços retornados para uso. Muitas vezes, ele simplesmente selecionará o primeiro da lista. O servidor DNS também pode embaralhar os endereços na resposta, para que o primeiro da lista não seja sempre o mesmo.

Há duas razões principais pelas quais um administrador de servidor pode configurar seu servidor DNS para retornar mais de um endereço IP para um nome de domínio específico:

• Redundância: se o servidor HTTP em execução em um desses endereços ficar inativo, seu navegador poderá lidar com esse caso tentando novamente com um endereço IP diferente; uma vez que todos devem ser equivalentes, você deve obter a mesma resposta de volta.
• Balanceamento de carga: um servidor HTTP pode não ser capaz de atender a todas as solicitações recebidas para o domínio e, portanto, vários servidores são usados; novamente, eles devem ser equivalentes um ao outro, então você deve obter a mesma resposta, independentemente de qual você escolher.

No entanto, existem outras maneiras de fornecer redundância e balanceamento de carga; por exemplo, dig google.comagora está apenas retornando um endereço para mim, mas tenho certeza de que o Google não está executando sua página principal com menos robustez do que a Microsoft. O DNS é apenas uma parte do processo.

Portanto, para se conectar de volta à pergunta original, é totalmente possível https://microsoft.com/e parecehttps://microsoft.com/example resolver para dois endereços IP diferentes, mas isso é apenas porque resolve para vários endereços IP e um diferente foi escolhido pela segunda vez. Se você continuar fazendo esse experimento um grande número de vezes, verá que ambos os URLs podem ser resolvidos para qualquer um dos 5 endereços no pool, já que, conforme declarado por outros, é apenas o nome de domínio que importa.microsoft.com

Então, eu estou querendo saber, como um aplicativo ou navegador sabe qual página acessar após a barra?

O navegador envia esse caminho e informações de consulta para o servidor cujo endereço foi encontrado no nome de domínio. O servidor determina o que deseja retornar para isso.

Quando você solicita que seu navegador (ou outro agente de usuário) recupere http://www.example.com/foo/bar?a=1&b=2#baz, ele divide esse URL em seus componentes especificados pela sintaxe de URL padrão e faz o seguinte:

1. Determine a partir da parte do esquema , http:, que deve usar o protocolo HTTP.

2. Determine a partir do //que o que se segue imediatamente será uma autoridade, que neste caso é apenas um nome de servidor: www.example.com. Em seguida, ele procurará o nome do servidor via DNS para obter um endereço IP para ele. Você deve ver essa solicitação e resposta de DNS em seu rastreamento do Wireshark, se seus filtros permitirem.

3. Como a autoridade não tinha especificação de porta, o navegador assumirá a porta padrão 80, como se você tivesse digitado http://www.example.com:80/foo/bar.

4. Em seguida, ele se conectará ao servidor nesse host e na porta TCP e enviará o caminho e as strings de consulta como parte da solicitação HTTP. Eles estarão na linha de solicitação que inicia a solicitação: GET /foo/bar?a=1&b=2 HTTP/1.0. (Observe que ele não envia o fragmento.) Você verá isso se examinar o conteúdo da solicitação HTTP no Wireshark.

5. O servidor interpretará a solicitação como desejar e retornará algum tipo de resultado.

6. Se o resultado que retornar for um documento HTTP, o navegador procurará um elemento com um id="baz"atributo (ou seja, correspondendo ao fragmento especificado acima) e rolará até ele.

Na verdade, existem mais algumas sutilezas nesse processo; para simplificar, deliberadamente deixei de fora qualquer menção a outros esquemas, outras partes da solicitação HTTP além da linha de solicitação (como cabeçalhos HTTP), quaisquer detalhes sobre o formato de resposta HTTP e o que os navegadores podem fazer com fragmentos quando a resposta é não um documento HTML.

Por último, mas o mais importante, se as solicitações/respostas DNS e os campos TLS SNI contiverem apenas subdomínios e domínio principal de um site, isso significa, por exemplo, que meu ISP não saberá exatamente quais páginas do Twitter ou Instagram eu visito e só pode ver isso Eu acesso Twitter.com e Instagram.com, desde que a conexão seja HTTPS?

Isso está correto, desde que você não tenha instalado nenhum certificado não padrão em seu navegador que permita um proxy ou proxy transparente para fazer proxy de conexões HTTPS por meio de descriptografia e nova criptografia.

Na verdade, para qualquer solicitação HTTPS (ou o que eles supõem ser uma solicitação HTTPS, já que vai para a porta 443 e usa TLS), tudo o que eles podem ver é o endereço IP ao qual você se conecta, que em alguns casos pode ser um sistema de hospedagem muitos sites diferentes (especialmente se for o endereço de um endpoint CDN ). Dito isso, eles geralmente também verão suas solicitações de DNS, que estão em texto não criptografado, então eles certamente podem adivinhar que, se você procurar example.com para obter 192.168.1.1 e logo depois se conectar à porta 443 em 192.168.1.1, você estão se conectando a example.com e não a um site diferente que também possa ser servido a partir desse endereço.

O DNS só resolverá o nome de domínio twitter.compara um endereço IP, por exemplo 192.168.1.1(observe que este não é realmente o endereço IP do Twitter, mas um endereço de um bloco de endereços reservado para redes privadas).

O endereço IP retornado pode diferir entre várias solicitações de DNS devido, por exemplo, ao gerenciamento de tráfego DNS ou simplesmente a uma alteração nos registros DNS associados ao domínio.

Uma vez que seu navegador tenha resolvido , twitter.compor exemplo 192.168.1.1, ele enviará uma solicitação HTTP GET para o servidor por trás 192.168.1.1solicitando o recurso mypageno domínio twitter.com:

GET /mypage HTTP/1.1
Host: twitter.com

Observe que seria possível para o servidor por trás 192.168.1.1hospedar vários domínios. Se, por exemplo, example.comtambém estivesse hospedado em 192.168.1.1, uma solicitação HTTP GET para example.com/mypageficaria assim:

GET /mypage HTTP/1.1
Host: example.com

Em resumo, seu navegador descobre para onde enviar a solicitação HTTP usando DNS e especifica dentro da solicitação, qual recurso exatamente ele gostaria de obter. O servidor, por sua vez, saberá exatamente qual recurso para qual domínio servir, de acordo com as informações da solicitação HTTP.

Para sua última pergunta, sim, usando HTTPS a URL será criptografada. No entanto, a parte do nome de domínio da URL pode ser enviada em texto não criptografado, dependendo do processo de handshake TLS em uso. Veja esta pergunta para detalhes.

Portanto, um invasor pode ver que você visitou o Twitter ou o Instagram, mas não poderá dizer exatamente quais páginas/perfis.

Você já recebeu uma boa explicação de como funciona o dns em relação à sua pergunta. Vou responder a parte do SNI.

Resposta curta: Seu ISP só poderá ver o nome do host. O SNI contém apenas o nome do host que seu navegador está tentando acessar. Isso é enviado em texto simples e é necessário para o seu navegador informar ao servidor web qual certificado SSL está solicitando. O handshake é então feito e a conexão é protegida antes que o URL completo seja enviado.

Não é uma resposta tão curta (muito mais do que você pediu, mas ...)

SNI=Indicação do Nome do Servidor. Faz parte do processo de handshake HTTPS TLS. Quando você deseja se conectar ao twitter.com, primeiro o dns é resolvido para isso. Em seguida, seu navegador envia uma solicitação para esse endereço IP na porta 443 (ao usar https://). Parte dessa solicitação inclui o SNI, se o seu navegador suportar, o que a maioria faz. O SNI contém apenas o nome de domínio. Se você digitou https//www.twitter.com/bejrjoftj, a pesquisa de DNS resolveria www.twitter.com e incluiria www.twitter.comcomo o pedido do SNI. Observe que "www." é na verdade um subdomínio do nome de domínio de nível superior. Um único IP pode hospedar muitos domínios. Somente HTTP e HTTPS acessam recursos diferentes com base no nome de host solicitado. Isso é importante porque, embora twitter.com e geocities.com possam resolver para o mesmo endereço IP, um navegador da Web receberá recursos diferentes (a página da Web que o servidor oferece a você) com base no nome do host solicitado, mas esse endereço IP só pode host, por exemplo, um servidor SSH na porta 22. Então, quando você está acessando sites diferentes com o mesmo IP, esse IP está executando apenas um servidor web, que decide qual página enviar a você com base no nome do host SNI. Mas isso é tudo que o SNI é, é o nome do host.

O Apache HTTP Server e o nginx suportam hosts virtuais. O servidor tem um "host padrão" que servirá se você, por exemplo, tiver usado o endereço IP diretamente em seu navegador. Isso geralmente redireciona para chamar uma configuração de host virtual. Os hosts virtuais não são apenas o nome do host.

Um host virtual também pode ser dado à direita do nome do host. Por exemplo, twitter.com e twitter.com/something/ podem ser dois hosts virtuais diferentes. Como o dns resolve apenas o nome do domínio/nome do host, o twitter.com resolveria para o mesmo IP, independentemente do restante do URL. Mas o servidor web recebe o URL completo solicitado após o handshake tls ser feito e a conexão ser criptografada. Para reinterar, o objetivo do SNI é garantir que o servidor web envie o certificado SSL correto para criptografar sua conexão, pois se você estiver tentando acessar o goatse.cx e seu endereço IP for o mesmo do twitter.com, o servidor precisa makr certifique-se de que ele envia o certificado correto ao seu navegador para que seu navegador possa verificar se o certificado recebido corresponde ao nome do host ao qual está tentando se conectar.

Sem o SNI, o servidor não teria como saber que você deseja o host virtual do goatse.cx do servidor, não o host virtual do twitter.com. E seu navegador precisa receber o certificado goatse.cx para completar o handshake sem problemas. O servidor web nesse IP precisa ter uma entrada de host virtual para o nome do host antes de poder definir hosts virtuais de URL. goatse.cx/ e goatse.cx/gaping/ não são necessariamente o mesmo host virtual, mesmo que compartilhem o mesmo certificado, se o arquivo de configuração tiver um host virtual definido para goatse.cx/gaping/*. Quanto ao motivo pelo qual você pode terminar em 192.168.2.1 para goatse.cx/gaping enquanto goatse.cx/ está em 192.168.1.1, é porque o host virtual pode ter um redirecionamento definido. Se isso acontecer, ele redirecionará seu navegador para o outro ip. Este é um redirecionamento definido por software e é definido por um código de resultado, 300. Um código de resultado mais conhecido é 404, o que significa que o arquivo solicitado não existe. se a configuração do host virtual incluir uma página de resposta personalizada para enviar de volta ao seu navegador sempre que o servidor receber uma resposta 404 do url que você solicitou, ele enviará essa página toda vez que você solicitar um arquivo que não existe. A resposta de redirecionamento de 300 também inclui uma nova url, que informa ao seu navegador "hey, você ligou para o servidor virtual goatse.cx/gaping/ mas desculpe mario, sua princesa está em outro castelo. Você precisa enviar essa solicitação para twitter.com /gaping/ em vez disso." E então seu navegador diz "oh droga, ok, foi mal". E, em seguida, envia uma solicitação para qualquer URL que o servidor disse para ir. É assim que você acaba sendo redirecionado para um URL malicioso quando tenta acessar um URL aparentemente inocente. Mas esse redirecionamento vem diretamente do servidor web e não do dns. Um redirecionamento de dns é somente quando a configuração de dns tem um registro CNAME (entradas normais de endereço IP para IPV4 são registros A). Um registro CNAME é um registro de alias. E um registro A ou CNAME é atribuído a um nome de host. Portanto, se gaping.goatse.cx tiver um registro CNAME no arquivo de registro mestre goatse.cx com um valor de "twitter.com", o cliente dns será instruído a procurar twitter.com para concluir a solicitação de gaping.goatse .cx. um registro CNAME é sempre um nome de domínio e nunca um endereço IP. Ele diz ao seu cliente dns que gaping.goatse.cx é apenas outro nome para usar no twitter.com. isso pode ser útil se você quiser usar gaping.goatse.cx como outro nome para gapinghole.com e quiser que o cliente dns siga a trilha até gapinghole.com. isso não requer que você execute um servidor web com um host virtual configurado para gaping.goatse.cx. seu cliente dns procurará o gapinghole.com e você receberá de volta o IP atribuído ao gapinghole.com.

DNS envolve apenas o nome de domínio. O que você está vendo é uma url. O nome de domínio é a palavra imediatamente antes do .come não pode ter um ponto final. Tão something.domain.com/something…simples domainé o nome de domínio, que se relaciona com o DNS de várias maneiras. Veja URLs para mais.