Resolução DNS quando não há registro A

1

Existem domínios, que estão registrados no DNS somente com um registro SOA, mas sem nenhum registro A (ou qualquer outro registro):

> dig wien.eu

; <<>> DiG 9.9.7-P3 <<>> wien.eu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51354
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wien.eu.           IN  A

;; AUTHORITY SECTION:
wien.eu.        1922    IN  SOA dns1.magwien.gv.at. hostmaster.magwien.gv.at. 2013082700 10800 3600 604800 86400

;; Query time: 134 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Sat Dec 02 19:45:19 CET 2017
;; MSG SIZE  rcvd: 101

O que parece ser um registro A é apenas um comentário (começa com um ponto e vírgula). Mesmo se não fosse um comentário, seria malformado (ou seja, não é um registro A) porque não contém nenhum endereço IP.

A maioria dos comandos que normalmente resolvem nomes de domínio (como ping, telnet e outros) usando DNS falhará se não houver nada além de uma entrada SOA (e muitos comentários e linhas vazias). / p>

Além disso, muitos webbrowsers não conseguem abrir um site em um domínio como SOA, como o link , entre eles:

  • Google Chrome
  • Ópera
  • Navegador Tor

Mas há navegadores que abrirão um site se você inserir esse nome de domínio:

  • Safari
  • Firefox

Eu não pude testar o Internet Explorer, porque eu uso o Mac OS, e ele não está disponível lá.
No caso do exemplo dado, eles redirecionam para outra URL (que, a propósito, parece uma maneira significativa de resolver a URL dada, o que me faz acreditar ser o comportamento desejado).

Eu me pergunto, o que o Safari e o Firefox fazem para realizar esse milagre, que outros navegadores e ferramentas não podem fazer.

btw: Eu pensei em saber como funciona o DNS, e pensei, isso significaria que domínios somente SOA como wien.eu não podem ser resolvidos para um endereço IP. Mas o Safari e o Firefox provam o contrário.

Adendo em resposta a uma resposta.

Todos os 5 navegadores usados no meu teste são as versões mais recentes, e todas são executadas no mesmo computador (iMac com Mac OS X 10.13 High Sierra). Então, todos usam exatamente o mesmo sistema operacional e também usam exatamente o mesmo servidor DNS.

E não há Registro AAAA no arquivo de zona (como você pode ver na saída citada de dig acima).

E se você não pode acreditar: Experimente. Use qualquer ferramenta que você deseja verificar as configurações de DNS de wien.eu e tente abri-lo em dois navegadores diferentes que pertencem a cada um dos dois grupos listados acima.

    
por Hubert Schölnast 02.12.2017 / 20:23

2 respostas

1

Não acredito que outros navegadores consigam resolver o domínio (a menos que haja registros CNAME ou AAAA que ajudem o DNS a descobrir aonde ir em seguida e que sejam igualmente reconhecidos por qualquer navegador).

Algumas possíveis explicações do comportamento observado -

  • Os resultados em cache estão sendo usados como fallback, mas não estão disponíveis em todos os navegadores.
  • Diferentes servidores de nomes sendo escolhidos com informações de arquivo de zona diferentes (possivelmente com cache DNS ou DNS dividido)

  • Anexa entradas de arquivos em alguns computadores, mas não em outros, ou em um domínio de pesquisa que pode modificar entradas de fallback de DNS.

  • Use se um proxy de armazenamento em cache - possivelmente um proxy transparente no nível do ISP.

  • Um pouco se houver um palpite, mas se houver um registro AAAA, pode haver limitações no navegador e / ou no sistema operacional lidando com o recurso IPV6.

É relevante que os navegadores da Web não façam a resolução de DNS, em vez de fazer uma chamada IS e deixar o IS lidar com isso. AFAIK isso é verdade se todos os navegadores.

Resposta atualizada específica para este servidor e à luz de informações adicionais

Uma das possíveis explicações na minha resposta anterior "Diferentes servidores de nomes sendo escolhidos com informações de arquivo de zona diferentes (possivelmente com cache DNS ou DNS dividido)" estavam corretos.

Ao fazer a consulta idêntica duas vezes ao mesmo servidor de nomes autoritário, obtivemos resultados diferentes da seguinte forma:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @dns1.wien.at wien.at
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47939
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wien.at.           IN  A

;; ANSWER SECTION:
wien.at.        300 IN  A   217.149.229.10

;; AUTHORITY SECTION:
wien.at.        86400   IN  NS  ns11.govix.at.
wien.at.        86400   IN  NS  ns5.univie.ac.at.
wien.at.        86400   IN  NS  dns1.magwien.gv.at.
wien.at.        86400   IN  NS  dns1.wien.at.

;; ADDITIONAL SECTION:
dns1.magwien.gv.at. 86400   IN  A   217.149.228.128
dns1.wien.at.       86400   IN  A   217.149.229.128

;; Query time: 278 msec
;; SERVER: 217.149.229.128#53(217.149.229.128)
;; WHEN: Sun Dec 03 11:27:55 NZDT 2017
;; MSG SIZE  rcvd: 186

davidgo@davidgo-Precision-T1500:~$ dig @dns1.wien.at wien.eu -t any 

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @dns1.wien.at wien.eu -t any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56418
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wien.eu.           IN  ANY

;; ANSWER SECTION:
wien.eu.        86400   IN  SOA dns1.magwien.gv.at. hostmaster.magwien.gv.at. 2013082700 10800 3600 604800 86400
wien.eu.        86400   IN  NS  dns1.magwien.gv.at.
wien.eu.        86400   IN  NS  dns1.wien.at.

;; ADDITIONAL SECTION:
dns1.magwien.gv.at. 86400   IN  A   217.149.228.128
dns1.wien.at.       86400   IN  A   217.149.229.128

;; Query time: 277 msec
;; SERVER: 217.149.229.128#53(217.149.229.128)
;; WHEN: Sun Dec 03 11:28:15 NZDT 2017
;; MSG SIZE  rcvd: 171

Isso definitivamente significa que há um problema com a configuração dos servidores de nomes, mas pode ser qualquer coisa, incluindo problemas com um servidor de nomes principal oculto, problemas com o servidor de nomes real, problemas com alguns membros de um cluster DNS ou uma combinação do acima. Vale a pena notar que os registros do servidor de nomes retornados também são diferentes.

Eu também acredito que algum cache de nameserver está acontecendo no sistema operacional, já que a consulta que retornou um resultado realmente retorna ao navegador muito raramente.

Também é digno de nota que sua consulta não foi feita contra um servidor de nomes autoritário - e muitos / a maioria dos provedores usam pools de servidores de nomes com um único endereço IP - cada um com informações diferentes devido ao cache de zona. Isso é óbvio se você fizer uma consulta (por exemplo) 8.8.8.8 - Googles "primary" nameserver, várias vezes, e observar o salto TTL em alta velocidade dependendo de qual servidor de nomes de backend você obter. (o TTL é o número entre o nome do domínio e o "IN" no registro SOA, mas existe em todos os registros. Se houvesse apenas um único servidor, esse número diminuiria à medida que os segundos passassem até que ele saltasse quando chegasse 0 e faz uma nova pesquisa.

    
por 02.12.2017 / 22:36
1

Eu encontrei a resposta para minha própria pergunta capturando o tráfego IP.

Em poucas palavras

Quando o firefox não obteve um endereço IP para wien.eu , ele solicitou (sem pedidos do usuário ou de qualquer outra pessoa) www.wien.eu (ele uniu o prefixo www. ao nome de domínio original) . Como há um registro A válido para esse outro domínio, ele recebeu uma resposta (ou seja, um endereço IP), enviou um HTTP GET para esse site, obteve 301 redirect e, em seguida, carregou o recurso redirecionado.

Obviamente, outros navegadores não fazem esse truque.

Em detalhes

Eu usei Kali Linux como sistema operacional, e lá iniciei o Firefox. Eu usei o Wireshark para capturar o tráfego. Aqui estão minhas descobertas em detalhes:

O Firefox solicita A e AAAA registros DNS para wien.eu e wien.eu.localdomain e sempre obtém a resposta No such name . Ele pede seu gateway padrão, que obviamente também é um servidor DNS.

Firefox sends (time = 0.000):
1: Standard DNS-Query: wien.eu: type A, class IN
2: Standard DNS-Query: wien.eu: type AAAA, class IN

Firefox receives (time = 0.030):
3: (Response to 1): Standard DNS-Response: No such name A wien.eu
4: (Response to 2): Standard DNS-Response: No such name AAAA wien.eu

Firefox sends (time = 0.030):
5: Standard DNS-Query: wien.eu.localdomain: type A, class IN
6: Standard DNS-Query: wien.eu.localdomain: type AAAA, class IN

Firefox receives (time = 0.031):
7: (Response to 5): Standard DNS-Response: No such name A wien.eu.localdomain
8: (Response to 6): Standard DNS-Response: No such name AAAA wien.eu.localdomain

O Firefox repete exatamente as mesmas quatro consultas e recebe exatamente as mesmas respostas (mensagens # 9 a # 16, tempo = 0,047, 0,053, 0,054, 0,054)

E novamente (mensagens # 17 a # 24, tempo = 0,057 a. 0,083)

E novamente (mensagens # 25 a # 32, tempo = 0,083 a 0,095)

Na ronda 5, o Firefox adiciona o prefixo www. ao nome do domínio e agora obtém respostas úteis:

Firefox sends (time = 0.113):
33: Standard DNS-Query: www.wien.eu: type A, class IN
34: Standard DNS-Query: www.wien.eu: type AAAA, class IN

Firefox receives (time = 0.140):
35: (Response to 33): Standard DNS-Response: 
Answers:
www.wien.eu: type CNAME, class IN, cname redirector.magwien.gv.at
redirector.magwien.gv.at: type A class IN, addr 217.149.229.45
Authorative nameservers
magwien.gv.at: type NS, class IN, ns ns11.govix.at.
magwien.gv.at: type NS, class IN, ns dns1.magwien.gv.at.
magwien.gv.at: type NS, class IN, ns ns5.univie.ac.at.
magwien.gv.at: type NS, class IN, ns dns1.wien.at.
Additional records
ns11.govix.at: type A, class IN, addr 192.76.243.11
ns11.govix.at: type AAAA, class IN, addr 2001:67c:133c::11
dns1.wien.at: type A, class IN, addr 217.149.229.128
dns1.magwien.gv.at: type A, class IN, addr 217.149.228.128
ns5.univie.ac.at: type A, class IN, addr 193.171.255.77
ns5.univie.ac.at: type AAAA, class IN, addr 2001:628:453:4305::53

36: (Response to 34): Standard DNS-Response:
Answers:
www.wien.eu: type CNAME, class IN, cname redirector.magwien.gv.at
Authorative nameservers
magwien.gv.at: type SOA, class IN, mname dns1.magwien.gv.at.

Desde que o Firefox tem um endereço IP, ele cria uma conexão TCP para esse endereço (handshake TCP, mensagens # 37-39). Então, na mensagem # 40, envia uma solicitação HTTP GET para este destino:

GET / HTTP1.1
Host: www.wien.eu
(and some additional HTTP headers)

O servidor confirma este pedido (mensagem # 41) e envia esta resposta na mensagem # 42:

301 Moved Permanently
Location: https://www.wien.gv.at/

O resto é claro:

  • O Firefox envia um reconhecimento de TCP (mensagem 43)
  • O Firefox solicita a resolução de DNS para www.wien.gv.at (A e AAAA, mensagens # 44 e # 45)
  • O Firefox recebe as respostas (mensagens # 46 e # 47)
  • Em seguida, o Firefox inicia a complicada caixa de diálogo HTTPS para carregar a página html que é exibida.
por 03.12.2017 / 07:55