Falha de consulta de DNS recursiva / iterativa intermitente

Question

Eu tenho um problema ao emitir consultas para um DNS e não tenho certeza de onde procurar a causa subjacente.

Eu tenho um registro "www.alumninews.uottawa.ca", que é um registro CNAME que aponta para um registro A de "uottawa.mailoutinteractive.com", que eu hospedo. Quando eu consultar os servidores DNS do meu provedor, recebo respostas diferentes:

O primeiro não recorre

$ dig +recurse www.alumninews.uottawa.ca @64.59.184.13

; <<>> DiG 9.8.1-P1 <<>> +recurse www.alumninews.uottawa.ca @64.59.184.13
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13260
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.alumninews.uottawa.ca. IN  A

;; ANSWER SECTION:
www.alumninews.uottawa.ca. 3600 IN  CNAME   uottawa.mailoutinteractive.com.

;; Query time: 139 msec
;; SERVER: 64.59.184.13#53(64.59.184.13)
;; WHEN: Wed Apr  3 11:33:55 2013
;; MSG SIZE  rcvd: 87

Observe que o CNAME não foi resolvido (mais sobre isso abaixo).

O segundo resolve o CNAME corretamente (note que o TTL agora é 3532, não o padrão 3600 acima):

$ dig +recurse www.alumninews.uottawa.ca @64.59.184.13

; <<>> DiG 9.8.1-P1 <<>> +recurse www.alumninews.uottawa.ca @64.59.184.13
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16716
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.alumninews.uottawa.ca. IN  A

;; ANSWER SECTION:
www.alumninews.uottawa.ca. 3532 IN  CNAME   uottawa.mailoutinteractive.com.
uottawa.mailoutinteractive.com. 300 IN  A   209.15.195.166

;; Query time: 30 msec
;; SERVER: 64.59.184.13#53(64.59.184.13)
;; WHEN: Wed Apr  3 11:35:03 2013
;; MSG SIZE  rcvd: 103

Além disso, quando eu capturar o tráfego de rede com o wireshark, vejo que o erro ao pesquisar uottawa.mailoutinteractive.com é "Código de resposta: Nenhum nome (3)" na recursão com falha:

Domain Name System (response)
[Request In: 3993]
[Time: 0.057954000 seconds]
Transaction ID: 0xf07c
Flags: 0x8183 Standard query response, No such name
    1... .... .... .... = Response: Message is a response
    .000 0... .... .... = Opcode: Standard query (0)
    .... .0.. .... .... = Authoritative: Server is not an authority for domain
    .... ..0. .... .... = Truncated: Message is not truncated
    .... ...1 .... .... = Recursion desired: Do query recursively
    .... .... 1... .... = Recursion available: Server can do recursive queries
    .... .... .0.. .... = Z: reserved (0)
    .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
    .... .... ...0 .... = Non-authenticated data: Unacceptable
    .... .... .... 0011 = Reply code: No such name (3)
Questions: 1
Answer RRs: 1
Authority RRs: 0
Additional RRs: 0
Queries
    www.alumninews.uottawa.ca: type A, class IN
        Name: www.alumninews.uottawa.ca
        Type: A (Host address)
        Class: IN (0x0001)
Answers
    www.alumninews.uottawa.ca: type CNAME, class IN, cname uottawa.mailoutinteractive.com
        Name: www.alumninews.uottawa.ca
        Type: CNAME (Canonical name for an alias)
        Class: IN (0x0001)
        Time to live: 1 hour
        Data length: 32
        Primaryname: uottawa.mailoutinteractive.com

Uma pesquisa bem-sucedida se parece com isso no Wireshark (este é um domínio diferente com o mesmo problema):

Domain Name System (response)
[Request In: 70]
[Time: 0.051422000 seconds]
Transaction ID: 0x417d
Flags: 0x8180 Standard query response, No error
    1... .... .... .... = Response: Message is a response
    .000 0... .... .... = Opcode: Standard query (0)
    .... .0.. .... .... = Authoritative: Server is not an authority for domain
    .... ..0. .... .... = Truncated: Message is not truncated
    .... ...1 .... .... = Recursion desired: Do query recursively
    .... .... 1... .... = Recursion available: Server can do recursive queries
    .... .... .0.. .... = Z: reserved (0)
    .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
    .... .... ...0 .... = Non-authenticated data: Unacceptable
    .... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 2
Authority RRs: 0
Additional RRs: 0
Queries
    www.bulletinsanciens.uottawa.ca: type A, class IN
        Name: www.bulletinsanciens.uottawa.ca
        Type: A (Host address)
        Class: IN (0x0001)
Answers
    www.bulletinsanciens.uottawa.ca: type CNAME, class IN, cname uottawa.mailoutinteractive.com
        Name: www.bulletinsanciens.uottawa.ca
        Type: CNAME (Canonical name for an alias)
        Class: IN (0x0001)
        Time to live: 41 minutes, 26 seconds
        Data length: 32
        Primaryname: uottawa.mailoutinteractive.com
    uottawa.mailoutinteractive.com: type A, class IN, addr 209.15.195.166
        Name: uottawa.mailoutinteractive.com
        Type: A (Host address)
        Class: IN (0x0001)
        Time to live: 5 minutes
        Data length: 4
        Addr: 209.15.195.166 (209.15.195.166)

Os servidores DNS do Uottawa estão configurados para não retornar informações de consulta recursivas, portanto, meu entendimento é que meu ISP fará uma segunda consulta para resolver o CNAME. Mas eu não sei porque está falhando uma vez e depois conseguindo uma segunda vez. parece para mim ser um problema entre nosso ISP (Shaw) e Route53, onde meu DNS está hospedado.

Eu também noto que muitas vezes continua a falhar - eu posso continuar a executar o comando de digitação com falha por um bom tempo antes que ele tenha sucesso novamente.

Eu cheguei até aqui, mas não sei como depurar isso ainda mais. Alguma ideia de onde isso está falhando?

    

Answer 1

A captura de pacotes não está revelando nada do que suas pesquisas de escavação não revelaram. Reply code: No such name (3) é uma maneira lenta de dizer NXDOMAIN ( RCODE 3 ), o último dos quais é mais significativo para os administradores de DNS. Eu não removerei a captura de pacotes do seu post, mas será menos uma parede de texto para os outros filtrarem se você concordar comigo neste ponto.

Uma resposta de NXDOMAIN é problemática; é uma indicação de uma consulta bem sucedida pelos servidores de nomes recursivos do seu ISP. É um mau comportamento da sua perspectiva porque o registro está faltando, mas a maneira como ele falhou conta uma história diferente. Os servidores do seu ISP estão dizendo: "Falei com os servidores de nomes oficiais, recebi uma resposta bem-sucedida e eles disseram que o registro não existia". Isso é bem diferente de SERVFAIL , o que indica um problema real de comunicação.

As respostas diferentes entre as consultas provavelmente são devidas ao balanceamento de carga: há vários servidores atrás do endereço IP que você está consultando. Um deles "armazenou em cache negativamente" a falha de pesquisa e não tentará a pesquisa novamente até que o intervalo ncache desse domínio expire. Outro de seus servidores foi bem-sucedido e "armazenou-o em cache" positivamente, fazendo com que ele lembrasse essa resposta pela duração do TTL. (3532 significa que 68 segundos se passaram desde aquele evento, 3532 + 68 = 3600)

Conclusão

Devido à natureza distribuída da AWS, será extremamente difícil para qualquer um de nós aconselhá-lo além disso. Eu questionei os quatro endereços de servidores de nomes que foram servidos para mim e não encontrei nenhum problema.

Se você vir esse problema novamente, tente consultar o registro A diretamente para ver se algo se destaca:

dig www.alumninews.uottawa.ca @64.59.184.1
( +recurse é definido por padrão e não é necessário)

A sua melhor aposta é pedir ao seu ISP para investigar mais na próxima vez que isso acontecer, mas esteja preparado para uma resposta do "nosso servidor está fazendo o que foi dito para fazer e não podemos ajudá-lo".

    

Answer 2

It seems to me to be a problem between our ISP (Shaw) and Route53, where my DNS is hosted.

Eu concordo. Porque 8.8.8.8 e 8.8.4.4 (servidores DNS do google) e meus servidores DNS locais não estão mostrando nenhum problema como você descreve, é hora de escalar com os administradores do servidor de nomes do seu ISP.